寻求用于Cassandra集群无停机数据迁移的双写代理

主流双写代理工具推荐 #

• Cassandra Sidecar Proxy：轻量级中间代理，部署在应用集群和Cassandra集群之间。只需修改应用的Cassandra连接地址指向代理，即可自动将写请求转发至新旧两个集群；读请求可配置优先路由到新集群或旧集群，适配不同迁移阶段需求，适合中小规模集群快速落地。
• 自定义双写逻辑+DSBulk：如果不想引入额外代理层，可基于DataStax Bulk Loader（DSBulk）扩展应用代码实现双写。这种方式需要开发介入修改业务代码，对代码侵入性较高，适合有自研能力的团队。
• Kafka Connect + Cassandra Sink：借助Kafka做异步中转，先通过Kafka Connect捕获旧集群的写操作，再通过Cassandra Sink同步至新集群；同时应用可直接双写至旧集群和Kafka，最终统一同步到新集群。该方案解耦了迁移流程，适合已有Kafka生态的场景，能有效降低应用侧的延迟影响。

实施关键注意事项 #

• 数据一致性校验：双写启动后，定期用nodetool repair命令或自定义校验脚本对比新旧集群的数据，排查因网络抖动、代理故障导致的不一致问题，确保数据完整性。
• 渐进式流量切换：双写运行一段时间（覆盖全量同步周期）后，先逐步将读流量切到新集群，验证业务稳定性；确认无问题后，停止旧集群的写请求，最终下线旧集群。
• 性能监控：实时监控代理的请求转发延迟、成功率，以及两个Cassandra集群的CPU、磁盘IO、读写吞吐量等指标，避免迁移过程中影响业务正常运行。

无停机迁移完整流程 #

1. 部署双写代理，配置同时指向新旧Cassandra集群的连接参数。
2. 修改应用的Cassandra连接地址为代理地址，开启双写模式。
3. 使用DSBulk执行全量数据同步：先从旧集群导出数据，再导入到新集群。
4. 全量同步完成后，执行数据一致性校验，确认新旧集群数据无差异。
5. 分批次将读流量切换至新集群，持续监控业务运行状态。
6. 业务稳定运行一段时间后，关闭代理的双写功能，仅向新集群写入数据。
7. 下线旧集群及双写代理，完成迁移。

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