Cassandra v3.11多AZ集群拓扑与Snitch迁移：先移节点还是先改策略？

核心结论：必须先修改Snitch策略，再逐步迁移节点到目标可用区。原因是SimpleSnitch无法识别可用区（AZ）拓扑，先切换到GossipingPropertyFileSnitch后，集群才能感知节点的AZ归属，后续迁移节点时才能保证数据按新拓扑正确分布，避免数据丢失或集群不稳定。

操作步骤 #

一、滚动切换Snitch策略（所有节点仍保留在原AZ） #

Cassandra集群不支持一次性全量修改Snitch，必须逐个节点滚动操作，避免集群中断：

• 对每个节点依次执行以下操作：

  1. 停止Cassandra服务：

     sudo systemctl stop cassandra
     

  2. 编辑cassandra.yaml配置文件，找到endpoint_snitch配置项，修改为：

     endpoint_snitch: GossipingPropertyFileSnitch
     

  3. 创建或编辑cassandra-rackdc.properties文件（通常在/etc/cassandra/目录下），暂时将所有节点配置为同一AZ（后续迁移时再调整）：

     dc=DC1
     rack=AZ-A
     

  4. 启动Cassandra服务：

     sudo systemctl start cassandra
     

  5. 执行nodetool status命令，确认该节点状态变为UN（Up/Normal）后，再处理下一个节点。

• 所有节点修改完成后，执行nodetool describecluster，确认输出中的Snitch字段已变为GossipingPropertyFileSnitch。

二、逐步迁移节点到目标AZ（每个AZ分配3个节点） #

完成Snitch切换后，开始逐个迁移节点到AZ-B和AZ-C，同样采用滚动操作：

• 对每个需要迁移的节点执行以下步骤：

  1. 停止Cassandra服务：

     sudo systemctl stop cassandra
     

  2. 编辑该节点的cassandra-rackdc.properties文件，更新rack字段为目标AZ：
     • 迁移到AZ-B的节点：rack=AZ-B
     • 迁移到AZ-C的节点：rack=AZ-C
  3. 将节点物理迁移到目标可用区（云环境调整实例所在AZ，物理机搬迁至对应机房区域）。
  4. 启动Cassandra服务：

     sudo systemctl start cassandra
     

  5. 执行nodetool status，确认节点状态恢复为UN，且RACK列显示目标AZ。
  6. 执行nodetool repair修复该节点数据，确保数据在新拓扑下同步完整：

     nodetool repair
     

• 每次仅操作一个节点，完成后再处理下一个，避免集群负载过高。全部迁移完成后，nodetool status应显示AZ-A、AZ-B、AZ-C各3个UN状态的节点。

三、后续验证与优化 #

1. 执行nodetool ring，检查数据分片在三个AZ间的分布是否均匀。
2. 如果集群原副本策略为SimpleStrategy，建议修改为NetworkTopologyStrategy，配置每个DC的副本数（例如DC1:3），确保每个AZ都有数据副本，提升多AZ架构的高可用性：
   • 修改keyspace的副本策略命令示例：

     ALTER KEYSPACE your_keyspace WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'DC1': 3};
     

3. 持续监控集群状态，确保所有节点稳定运行，无异常告警。

内容的提问来源于stack exchange，提问作者Mircea-Andrei Albu