零停机的ScyllaDB数据迁移实战时间轴、踩坑实录与30天清单【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb迁移窗口只有一周线上不能停这是ScyllaDB数据迁移项目的常见处境。本文按时间轴串事件T-7天对齐schemaT-1天开双写T0导入存量随后24小时做一致性校验T3切流量收尾是切换后30天清单。T-7dschema怎么改Cassandra兼容差异逐项过判断依据schema对齐的标准不是能执行而是每个表选项在目标端都能被识别。做法不复杂用cqlsh对源端跑一遍DESC SCHEMA导出全部建表语句然后对照下面的表逐项过。这四处是翻车率最高的源端常见写法目标端处理不改的后果compression参数名改名sstable_compression建表直接报错99PERCENTILE写成99.0PERCENTILE建表参数校验失败crc_check_chance删除目标端不认建表失败旧格式counter表仅支持新版计数器导入阶段才暴露错误推荐动作改完的schema在目标集群执行后立刻把两边的DESC TABLE输出拉出来逐表比对。只看没报错不可靠选项静默丢失的情况真实存在。反例有团队直接执行原始dump文件前29张表全过第30张挂在压缩参数上前面清理重建花掉半天。counter这类特殊表型值得提前在测试集群单独干跑一次错得越早越便宜。Cassandra兼容迁移流程、Cassandra兼容性说明、系统需求⚡ T-1d双写并行怎么落地时间戳与重试设计判断依据双写是零停机迁移的前提。应用同时写两端、读仍走源端两边数据并行收敛切换那天就只剩一次配置翻转。三个设计点缺一个都会在验证期还债。一时间戳由客户端生成两边writetime来自同一时钟后续校验才可直接比较。二失败重试两次写入是互相独立的future一端失败就有限次指数退避重试仍失败的进不一致日志。三日志必须落盘双写窗口越长漏写越多这份日志就是校验期的原始材料。async def dual_write(src, dst, stmt, values): f_src src.execute_async(stmt, values) # 源库 f_dst dst.execute_async(stmt, values) # ScyllaDB ok_src, ok_dst await collect(f_src, f_dst) if not ok_src or not ok_dst: log_mismatch(values, ok_src, ok_dst) # 不一致先落日志 await backoff_retry(src, dst, stmt, values) # 有限次指数退避注意时间戳没用客户端生成同一条记录两边writetime就不同校验全判成不一致你会花几天排查一场假故障。反例先写源端、写成功再写目标端串行且无重试。一端抖一下双写窗口就丢一半数据验证期直接炸。双写下的一次写请求要扇出到两个存储引擎和上图的副本复制同构区别在于这次复制跨了引擎边界任何一端的延迟都会暴露给业务。 T0存量导入SSTableLoader提速参数与并行姿势判断依据历史数据别走应用层直接灌SSTable。工具用ScyllaDB版的sstableloader来自scylla-tools-core包装中间节点别用Cassandra同名工具。动作就三步。源端每个节点用nodetool snapshot打快照快照目录经NFS挂到中间节点——loader别直接跑在目标集群上白吃资源挂载路径必须以keyspace/table格式结尾工具靠它解析起多个loader并行一实例一张表目标地址轮流指向集群全部节点。sstableloader /mnt/snap/myks/mytable -d scylla-1,scylla-2,scylla-3 -t 20提速参数看三个。-t限速值按业务高峰前实测的网络水位定宁低勿堵并行度按表切多实例各管各的表导入期重复数据量大把compaction的min_threshold临时压到2能更快清掉副本重叠compaction吞吐也调高一档。注意sstableloader不支持从加密文件加载源端若开了表级加密先拷成明文再导入。注意只灌基表SSTable索引和物化视图的SSTable一律不导让目标端自己重建索引。反例把loader直接跑在目标节点上导入成功了线上写延迟翻三倍业务方先于DBA发现问题。T024h数据一致性校验计数、抽样与通过线判断依据通过线必须在开跑前写下来——不一致率低于业务阈值常见取0.1%且关键链路零不一致。没有提前定的线校验会变成无限期工程。三层校验由粗到细。第一层全表计数对比两端各跑一遍逐表比数第二层抽样对比脚本按keyspace的token区间走随机取分区键两边逐字段比第三层双读日志校验窗口内应用同时读两端并记录差异它产出的才是真实流量下的结论。-- 源端与目标端各执行一次逐表对比 SELECT COUNT(*) FROM myks.mytable;计数单独不能算通过一张重复5%、缺5%的表总数完全相等业务却已经错了。双读窗口本质上是让读路径替你跑一遍diff采样率越高通过线越可信。T3流量切换与回滚演练判断依据校验通过线达成且双读期不一致率收敛到稳定低位才动流量。切法分三级小步走。先切读流量从个位数百分比起步盯目标端的读延迟和错误率观察窗干净后放到全部读最后写流量收单端停双写。每一级都留一个观察窗出问题只回退一级。⚠️ 回滚预案必须在切换前演练过。切换出问题而回滚路径没验证观察期会被无限拉长回滚动作就是切换的逆序——应用配置指回源端必要时TRUNCATE目标端表再重导。没演练过的回滚路径等于没写。注意源端集群保留到72小时观察期结束再下线提前拆掉等于自废回滚。反例读写一把全切两小时后出问题分不清是哪边数据错了回滚成本翻倍。 踩坑实录三个真实故障故障一导入卡死在一张表现象loader报错退出其余表全部成功。 定位NFS挂载点路径没按keyspace/table格式收尾工具解析失败另一版根因是旧格式SSTable不被识别。 处理挂载点改名重启任务旧格式SSTable先在源端跑nodetool upgradesstables升级格式再拷。故障二校验报出上万不一致现象抽样不一致率3%业务方坚称数据没问题。 定位源端写入没带客户端时间戳同一条记录两边writetime不同全属误报。 处理应用切到客户端时间戳比对逻辑忽略writetime字段只比值。故障三导入成功磁盘打满现象导入期间节点磁盘占用陡增compaction积压写延迟飙升。 定位导入制造大量临时重复数据compaction追不上。 处理-t降速、抬高compaction吞吐、压低阈值加速去重导入窗口挪到业务低峰。✅ 切换后的30天清单切换不是终点目标端有自己的调优节奏物化视图或本地二级索引替换部分非主键查询把读放大降下来监控栈就位重点盯compaction backlog与读延迟两条曲线第一周跑一轮全量repair清掉残留不一致观察环与tablet负载做扩容规划双读再保留一周不一致率为零后下线源端性能预期上公开基准里相同硬件下ScyllaDB吞吐可达源集群的10倍p99延迟降约90%——生产环境以自己的监控数据为准。下一步动作按上面的差异表过一遍源端schema在测试集群干跑一轮建表双写分支接上客户端时间戳与不一致日志T-1前在测试环境验证可回滚排一次回滚演练和值班同学一起走完全流程官方迁移流程文档、二级索引、物化视图【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 零停机的ScyllaDB数据迁移实战：时间轴、踩坑实录与30天清单
零停机的ScyllaDB数据迁移实战时间轴、踩坑实录与30天清单【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb迁移窗口只有一周线上不能停这是ScyllaDB数据迁移项目的常见处境。本文按时间轴串事件T-7天对齐schemaT-1天开双写T0导入存量随后24小时做一致性校验T3切流量收尾是切换后30天清单。T-7dschema怎么改Cassandra兼容差异逐项过判断依据schema对齐的标准不是能执行而是每个表选项在目标端都能被识别。做法不复杂用cqlsh对源端跑一遍DESC SCHEMA导出全部建表语句然后对照下面的表逐项过。这四处是翻车率最高的源端常见写法目标端处理不改的后果compression参数名改名sstable_compression建表直接报错99PERCENTILE写成99.0PERCENTILE建表参数校验失败crc_check_chance删除目标端不认建表失败旧格式counter表仅支持新版计数器导入阶段才暴露错误推荐动作改完的schema在目标集群执行后立刻把两边的DESC TABLE输出拉出来逐表比对。只看没报错不可靠选项静默丢失的情况真实存在。反例有团队直接执行原始dump文件前29张表全过第30张挂在压缩参数上前面清理重建花掉半天。counter这类特殊表型值得提前在测试集群单独干跑一次错得越早越便宜。Cassandra兼容迁移流程、Cassandra兼容性说明、系统需求⚡ T-1d双写并行怎么落地时间戳与重试设计判断依据双写是零停机迁移的前提。应用同时写两端、读仍走源端两边数据并行收敛切换那天就只剩一次配置翻转。三个设计点缺一个都会在验证期还债。一时间戳由客户端生成两边writetime来自同一时钟后续校验才可直接比较。二失败重试两次写入是互相独立的future一端失败就有限次指数退避重试仍失败的进不一致日志。三日志必须落盘双写窗口越长漏写越多这份日志就是校验期的原始材料。async def dual_write(src, dst, stmt, values): f_src src.execute_async(stmt, values) # 源库 f_dst dst.execute_async(stmt, values) # ScyllaDB ok_src, ok_dst await collect(f_src, f_dst) if not ok_src or not ok_dst: log_mismatch(values, ok_src, ok_dst) # 不一致先落日志 await backoff_retry(src, dst, stmt, values) # 有限次指数退避注意时间戳没用客户端生成同一条记录两边writetime就不同校验全判成不一致你会花几天排查一场假故障。反例先写源端、写成功再写目标端串行且无重试。一端抖一下双写窗口就丢一半数据验证期直接炸。双写下的一次写请求要扇出到两个存储引擎和上图的副本复制同构区别在于这次复制跨了引擎边界任何一端的延迟都会暴露给业务。 T0存量导入SSTableLoader提速参数与并行姿势判断依据历史数据别走应用层直接灌SSTable。工具用ScyllaDB版的sstableloader来自scylla-tools-core包装中间节点别用Cassandra同名工具。动作就三步。源端每个节点用nodetool snapshot打快照快照目录经NFS挂到中间节点——loader别直接跑在目标集群上白吃资源挂载路径必须以keyspace/table格式结尾工具靠它解析起多个loader并行一实例一张表目标地址轮流指向集群全部节点。sstableloader /mnt/snap/myks/mytable -d scylla-1,scylla-2,scylla-3 -t 20提速参数看三个。-t限速值按业务高峰前实测的网络水位定宁低勿堵并行度按表切多实例各管各的表导入期重复数据量大把compaction的min_threshold临时压到2能更快清掉副本重叠compaction吞吐也调高一档。注意sstableloader不支持从加密文件加载源端若开了表级加密先拷成明文再导入。注意只灌基表SSTable索引和物化视图的SSTable一律不导让目标端自己重建索引。反例把loader直接跑在目标节点上导入成功了线上写延迟翻三倍业务方先于DBA发现问题。T024h数据一致性校验计数、抽样与通过线判断依据通过线必须在开跑前写下来——不一致率低于业务阈值常见取0.1%且关键链路零不一致。没有提前定的线校验会变成无限期工程。三层校验由粗到细。第一层全表计数对比两端各跑一遍逐表比数第二层抽样对比脚本按keyspace的token区间走随机取分区键两边逐字段比第三层双读日志校验窗口内应用同时读两端并记录差异它产出的才是真实流量下的结论。-- 源端与目标端各执行一次逐表对比 SELECT COUNT(*) FROM myks.mytable;计数单独不能算通过一张重复5%、缺5%的表总数完全相等业务却已经错了。双读窗口本质上是让读路径替你跑一遍diff采样率越高通过线越可信。T3流量切换与回滚演练判断依据校验通过线达成且双读期不一致率收敛到稳定低位才动流量。切法分三级小步走。先切读流量从个位数百分比起步盯目标端的读延迟和错误率观察窗干净后放到全部读最后写流量收单端停双写。每一级都留一个观察窗出问题只回退一级。⚠️ 回滚预案必须在切换前演练过。切换出问题而回滚路径没验证观察期会被无限拉长回滚动作就是切换的逆序——应用配置指回源端必要时TRUNCATE目标端表再重导。没演练过的回滚路径等于没写。注意源端集群保留到72小时观察期结束再下线提前拆掉等于自废回滚。反例读写一把全切两小时后出问题分不清是哪边数据错了回滚成本翻倍。 踩坑实录三个真实故障故障一导入卡死在一张表现象loader报错退出其余表全部成功。 定位NFS挂载点路径没按keyspace/table格式收尾工具解析失败另一版根因是旧格式SSTable不被识别。 处理挂载点改名重启任务旧格式SSTable先在源端跑nodetool upgradesstables升级格式再拷。故障二校验报出上万不一致现象抽样不一致率3%业务方坚称数据没问题。 定位源端写入没带客户端时间戳同一条记录两边writetime不同全属误报。 处理应用切到客户端时间戳比对逻辑忽略writetime字段只比值。故障三导入成功磁盘打满现象导入期间节点磁盘占用陡增compaction积压写延迟飙升。 定位导入制造大量临时重复数据compaction追不上。 处理-t降速、抬高compaction吞吐、压低阈值加速去重导入窗口挪到业务低峰。✅ 切换后的30天清单切换不是终点目标端有自己的调优节奏物化视图或本地二级索引替换部分非主键查询把读放大降下来监控栈就位重点盯compaction backlog与读延迟两条曲线第一周跑一轮全量repair清掉残留不一致观察环与tablet负载做扩容规划双读再保留一周不一致率为零后下线源端性能预期上公开基准里相同硬件下ScyllaDB吞吐可达源集群的10倍p99延迟降约90%——生产环境以自己的监控数据为准。下一步动作按上面的差异表过一遍源端schema在测试集群干跑一轮建表双写分支接上客户端时间戳与不一致日志T-1前在测试环境验证可回滚排一次回滚演练和值班同学一起走完全流程官方迁移流程文档、二级索引、物化视图【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考