Cassandra 3.10快照恢复疑问：是否需恢复系统类Keyspace？

Hey there! Let's break down whether you need to restore each of those system keyspaces when recovering your Cassandra 3.10 snapshot:

• system keyspace: 绝对不要恢复。它存储节点专属的元数据，比如local表（节点ID、集群名称等）和peers表（集群内其他节点信息）。从快照恢复这个keyspace会覆盖节点唯一标识和集群拓扑信息，直接导致节点冲突、脑裂这类灾难性问题。Cassandra启动时会自动重建system里的必要表，除非有极特殊的边缘场景（几乎不会遇到），否则别碰它。

• system_schema keyspace: 如果是搭建新集群，必须恢复。这个keyspace保存着集群所有的元数据：keyspace定义、表结构、索引、数据类型等。要是你要把快照恢复到一个没有业务schema的全新集群，不恢复system_schema的话，Cassandra根本识别不了业务keyspace的结构，恢复操作肯定失败。但如果是在已有集群上恢复（schema还完好，只是数据丢失），就可以跳过。

• system_auth keyspace: 如果启用了认证/授权，必须恢复。要是你的集群配置了PasswordAuthenticator这类认证器，或者CassandraAuthorizer这类授权器，这个keyspace里存着用户账号、角色和权限信息。跳过恢复的话，所有访问控制都会丢失，你得从零重建用户和权限。如果没启用认证授权，这个keyspace没什么关键数据，恢复不恢复都行。

• system_distributed keyspace: 除非要恢复特定分布式任务，否则别恢复。它记录着修复状态、批量日志条目、CDC数据（如果启用的话）这类信息。大部分数据都是临时的，Cassandra需要时会自动重新生成。恢复旧的条目可能导致过期或无效的分布式任务意外运行，让Cassandra自己重建这些表更安全。

恢复小提醒 #

• 确保目标集群和快照来源的Cassandra版本完全一致（都是3.10）。
• 恢复某个keyspace前，先停掉Cassandra节点，清空该keyspace的现有数据目录（data/<keyspace_name>路径下），把快照文件复制进去后再启动节点。
• 恢复完成后，对受影响的keyspace执行nodetool repair，保证集群数据一致性。

内容的提问来源于stack exchange，提问作者Ajay Gupta