Azure虚拟机Cassandra集群迁移至GCP Compute Engine零停机步骤咨询

针对多Keyspace场景下的架构同步复杂问题，以下是可落地的零停机迁移流程：

1. 批量同步全量集群架构 #

解决手动创建多Keyspace/Table的繁琐问题，直接从源集群导出完整架构：

• 在Azure集群任意节点执行，导出包含所有Keyspace、Table、索引、UDF/UDT的完整架构：

  cqlsh <azure-cassandra-node-ip> -e "DESCRIBE ALL" > full_schema.cql
  

• 将full_schema.cql通过VPN传输至GCP集群任意节点，执行架构导入：

  cqlsh <gcp-cassandra-node-ip> -f full_schema.cql
  

• 验证架构一致性：在GCP集群执行DESCRIBE KEYSPACES、DESCRIBE TABLE <keyspace>.<table>确认所有结构与源集群一致。

2. 全量数据在线迁移 #

使用Cassandra原生快照工具实现无停机全量数据同步：

• 在Azure集群每个节点上，针对业务Keyspace创建在线快照（避开系统Keyspace如system、system_schema）：

  nodetool snapshot -t migration_snapshot keyspace1 keyspace2 keyspace3
  

  （注：migration_snapshot为自定义快照名称，可按需修改）
• 每个节点的快照文件默认存储路径为/var/lib/cassandra/data/<keyspace>/<table>-<uuid>/snapshots/migration_snapshot/，将这些文件通过VPN同步至GCP对应节点的同路径下（需确保GCP节点Cassandra服务用户对路径有读写权限）
• 在GCP每个节点上，批量刷新快照数据至集群：

  # 可编写Shell脚本遍历所有Keyspace和Table自动执行
  nodetool refresh <keyspace> <table>
  

• 验证全量数据：随机抽取业务表执行SELECT COUNT(*) FROM <keyspace>.<table>，对比新旧集群数据量一致。

3. 增量数据双写同步（零停机核心） #

确保迁移期间新写入的数据同步至新集群：

• 修改应用的Cassandra客户端配置，添加GCP集群的连接地址，实现双写逻辑：所有INSERT/UPDATE/DELETE操作同时发送至Azure和GCP集群
• 保持双写状态至少1个业务数据TTL周期（或根据业务数据保留时长调整），确保所有增量数据已同步至新集群
• 抽样验证增量数据：选取迁移期间产生的新数据，在新旧集群查询对比一致性。

4. 流量切换与源集群下线 #

• 切换读流量：修改应用配置，将所有读请求指向GCP集群，监控集群负载、读写延迟、业务报错情况，稳定运行1-2小时后进入下一步
• 切换写流量：停止双写逻辑，将所有写请求指向GCP集群，继续监控业务运行状态
• 下线源集群：确认GCP集群稳定运行24小时以上后，逐步停止Azure集群节点，清理相关资源

关键注意事项 #

• 快照操作需选择业务低峰期执行，避免IO波动影响业务
• 确保VPN带宽满足快照文件传输需求，避免同步耗时过长
• 双写期间需处理写入失败重试逻辑，避免数据不一致
• 新旧集群的Cassandra版本、一致性级别、压缩策略需保持一致，避免兼容性问题

内容的提问来源于stack exchange，提问作者admin-user