ScyllaDB 复制策略迁移指南从 SimpleStrategy 切换到 NetworkTopologyStrategy 的无停机与停机两种方案【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb导读本文基于 ScyllaDB 官方操作手册中的集群管理流程完整讲解如何将一个使用SimpleStrategy复制策略的 keyspace 安全迁移到NetworkTopologyStrategy。你将掌握何时可以选择无停机迁移、何时必须停机操作、如何通过 CQL 修改复制策略、如何配套完成 snitch 切换与cassandra-rackdc.properties配置以及迁移背后 ScyllaDB 两种复制策略在源码层面的实现差异。迁移完成后你的集群将具备跨数据中心DC、跨机架rack的拓扑感知复制能力这是生产环境部署的基本要求。为什么需要从 SimpleStrategy 切换到 NetworkTopologyStrategySimpleStrategy是 Cassandra 兼容模型中最早的复制策略它在 token 环上顺序选取下一个拥有 token 的节点作为副本完全不感知数据中心与机架的物理拓扑。在 locator/simple_strategy.cc 的calculate_natural_endpoints()实现中可以看到它只是沿tm.ring_range(t)遍历排序后的 token 环取前replication_factor个节点即作为副本集合既不看 DC 也不看 rackfor (auto token : tm.ring_range(t)) { if (endpoints.size() replicas || endpoints.size() tm.count_normal_token_owners()) { break; } auto ep tm.get_endpoint(token); endpoints.push_back(*ep); co_await coroutine::maybe_yield(); }这带来的直接问题是一旦集群跨多个机架甚至跨数据中心部署SimpleStrategy可能把所有副本都落在同一个机架或同一个 DC 上机架/DC 级故障就会造成全部副本同时不可用。此外从源码还可以确认SimpleStrategy的另外两个限制不支持 tablet 复制validate_options()中显式抛出SimpleStrategy doesnt support tablet replication见 locator/simple_strategy.cc只有replication_factor一个合法选项且必须是数值否则抛出configuration_exception。因此官方文档明确建议不要在生产环境使用SimpleStrategy新建集群时应直接采用NetworkTopologyStrategy见 update-topology-strategy-from-simple-to-network.rst。NetworkTopologyStrategy则完全不同。在 locator/network_topology_strategy.cc 中其构造函数把配置中的每个DC:RF键值对解析进_dc_rep_factor映射并累加得到总复制因子而在calculate_natural_endpoints()中natural_endpoints_tracker会按 DC 分别统计 token owner 与 rack 分布优先把副本分散到不同机架Replicas are put into separate racks while possible从而真正实现拓扑感知复制。同时 locator/tablets.cc 中的注释也表明tablets 只能与NetworkTopologyStrategy配合使用。这意味着迁移到NetworkTopologyStrategy也是后续启用 tablet 能力的前提。第一步判断你的场景属于哪条迁移路径在动手之前先根据集群拓扑和复制因子RF的变化情况判断应该采用哪条迁移流程。官方给出了两条互斥的路径无停机迁移Procedure with no downtime满足以下任一条件即可使用无停机方案所有节点都在同一个 rack 上或者无论 rack 数量多少SimpleStrategykeyspace 的 RF 不发生变化且 RF 恰好等于集群节点总数。例如某 keyspace 的 RF 为 3、集群恰好 3 个节点且 RF 保持不变那么 rack 数量多少都无所谓。为什么 RF 等于节点数时无需停机因为此时每个 token 的副本集覆盖了环上所有节点切换到NetworkTopologyStrategy后新的副本集合与旧集合一致数据不会发生“搬移”。停机迁移Procedure with downtime满足以下任一条件就必须走停机方案集群节点分布在多个 rack 上且 RF 保持不变但 RF 不等于集群节点总数集群节点分布在多个 rack 上且 RF 发生变化。原因是新策略在跨 rack 时会选择与SimpleStrategy不同的节点作为副本旧副本上的一部分数据将不再被新副本集合覆盖需要停机后通过两轮 full repair 与 cleanup 来纠正否则可能丢失数据。如何确认节点的 rack 分布使用nodetool status查看每个节点所属的 DC 与 rack如果部署了 Scylla Manager也可以从 Manager 节点上执行sctool status获得相同信息nodetool status输出中的RACK列会显示每个节点的机架归属。这一步直接决定你走哪条迁移路径务必先执行。第二步找出所有仍在用 SimpleStrategy 的 keyspaceSimpleStrategy不仅可能出现在用户自建的 keyspace 中也可能出现在部分系统 keyspace 中必须逐一排查。检查用户自建 keyspace查看某个具体 keyspace 的复制策略DESCRIBE KEYSPACE mykeyspace;一次性查看全部 keyspaceDESCRIBE SCHEMA;检查系统 keyspace以下系统 keyspace 默认可能使用SimpleStrategy需要单独确认DESCRIBE KEYSPACE system_distributed; DESCRIBE KEYSPACE system_traces; DESCRIBE KEYSPACE system_audit;以system_distributed为例在 db/system_distributed_keyspace.cc 的源码中可以看到该 keyspace 的复制配置确实使用了org.apache.cassandra.locator.SimpleStrategy这一注册名。ScyllaDB 通过utils/class_registrator.hh机制将字符串类名注册到策略工厂SimpleStrategy同时注册了全限定名org.apache.cassandra.locator.SimpleStrategy和短名SimpleStrategy见 locator/simple_strategy.cc因此 CQL 中两种写法均合法。只要上述任一 keyspace 显示使用SimpleStrategy就按本文对应的流程切换到NetworkTopologyStrategy。注意官方文档原文中 NetworkTopologyStategy 为笔误正确拼写为NetworkTopologyStrategy。方案一无停机迁移推荐条件满足时使用无停机流程非常简洁核心就一步逐个修改 keyspace 的复制策略。修改 keyspace 复制策略以一个名为mykeyspace的 keyspace 为例迁移前Before的状态为DESCRIBE KEYSPACE mykeyspace; CREATE KEYSPACE mykeyspace WITH replication { class : SimpleStrategy, replication_factor: 3};执行 ALTER 命令将其改为NetworkTopologyStrategy其中existing_dc替换为集群中实际存在的数据中心名称3为该 DC 的目标 RFALTER KEYSPACE mykeyspace WITH replication { class : NetworkTopologyStrategy, existing_dc : 3};迁移后After再次确认DESCRIBE KEYSPACE mykeyspace; CREATE KEYSPACE mykeyspace WITH replication { class : NetworkTopologyStrategy, existing_dc : 3};从 locator/network_topology_strategy.cc 的validate_options()可以知道ALTER 时传入的每个 DC 名称都必须存在于集群当前拓扑topology.get_datacenter_racks()中否则会抛出Unrecognized strategy option {...}的configuration_exception同时check_enough_endpoints()会校验每个 DC 的 RF 不能超过该 DC 实际的 token owner 节点数否则抛出Datacenter {} doesnt have enough token-owning nodes for replication_factor{}。所以请确保existing_dc与 RF 取值与集群实际一致。另外注意NetworkTopologyStrategy不接受replication_factor这种扁平写法必须展开为DC:RF列表源码中直接对replication_factor键触发on_internal_error。如果集群有多个 DC应写成类似{class:NetworkTopologyStrategy, dc1:3, dc2:3}的形式。配套完成 snitch 切换与 rackdc 配置修改复制策略只是第一步要让NetworkTopologyStrategy真正按 DC/rack 工作还需要确保 snitch 与节点拓扑信息一致操作步骤详见 switch-snitch.rst在/etc/scylla/scylla.yaml中把endpoint_snitch改为支持拓扑感知的 snitch例如endpoint_snitch: GossipingPropertyFileSnitch编辑/etc/scylla/cassandra-rackdc.properties填写每个节点所属的 DC 与 rack并设置首选 DC 名称。仓库中的 conf/cassandra-rackdc.properties 给出了该文件的完整注释模板dcmy_data_center rackmy_rack prefer_localfalse | true dc_suffixData Center name suffix, used by EC2SnitchXXX snitches注意该文件允许 DC 与 rack 名称包含空格首尾空格会被自动裁剪prefer_local用于控制是否优先选择本地 DC 的副本进行读取。云环境场景如Ec2MultiRegionSnitch中DC 名通常就是 region 名、rack 名就是可用区AZ。注意switch-snitch 文档同时指出切换 snitch 通常需要集群完全停机因此强烈建议在集群搭建阶段就选对 snitch无停机迁移只保证复制策略切换这一环节无需停机snitch 切换环节需按其文档要求另行安排。同时切换后的 snitch 必须指定与之前相同的 DC 与 rack。方案二停机迁移多 rack 且 RF 不等于节点数时必须使用当集群跨多个 rack 且 RF 不等于节点总数、或 RF 本身需要调整时新策略选出的副本节点会与旧策略不同直接 ALTER 会导致部分数据失去副本覆盖因此官方流程要求先停止全部流量、进行集群完全停机按以下顺序操作停止集群的全部流量。这一步是硬性要求文档明确警告A failure to stop the traffic can cause data loss.未停止流量可能导致数据丢失。对集群执行一次 full repair。repair 的作用是让所有副本数据达成一致具体命令与原理参见 repair.rstScyllaDB 采用 row-level repair逐行计算校验和并通过集合对账算法只交换不一致的行最小化网络传输与磁盘读取。可手动执行nodetool repair或使用 Scylla Manager 调度。按上文“方案一”中的 ALTER 命令修改复制策略ALTER KEYSPACE ... WITH replication {class:NetworkTopologyStrategy, existing_dc:3}。再执行一次 full repair。策略切换后新副本集合需要与旧副本对齐第二次 full repair 负责把数据同步到新选出的副本节点。在每个节点上执行nodetool cleanup。cleanup 用于清理那些不再属于本节点 token 范围的陈旧数据该命令的完整说明见 cleanup.rst避免切换后旧副本残留垃圾数据占用磁盘。恢复流量。完成上述步骤后同样需要按“方案一”中的说明完成 snitch 切换、编辑cassandra-rackdc.properties并设置首选 DC 名称整个迁移才算闭环。为什么需要两轮 repair cleanup从副本集合的角度解释第一轮 repair 保证“切换前”所有副本数据一致ALTER 之后NetworkTopologyStrategy重新计算自然端点natural endpoints部分 token 的副本节点发生变化第二轮 repair 保证新副本集合从旧副本补齐数据最后nodetool cleanup清除原副本节点上不再属于它的数据。三步缺一不可这是停机方案“更复杂”的本质原因——拓扑变化改变了数据的物理分布。迁移后的验证与日常维护建议迁移完成后建议做以下验证再次执行DESCRIBE SCHEMA或DESCRIBE KEYSPACE name确认所有用户 keyspace 与system_distributed、system_traces、system_audit均已切换为NetworkTopologyStrategy执行nodetool status确认每个节点上报的 DC/rack 与cassandra-rackdc.properties一致结合 repair.rst 的建议将 repair 纳入日常运维定期执行nodetool repair -pr逐节点顺序执行删除频繁的场景下间隔应小于gc_grace_seconds默认 10 天例如每周一次。总结从SimpleStrategy迁移到NetworkTopologyStrategy是 ScyllaDB 生产化的关键一步前者在源码层面完全不感知 DC/rack无法支撑跨机架容灾也不支持 tablet后者按 DC 独立计算 RF 并在 rack 间分散副本是生产环境与 tablet 功能的基石。迁移路径的选择完全取决于拓扑与 RF 的关系——同 rack、或 RF 等于节点数时走无停机方案仅需逐个ALTER KEYSPACE多 rack 且 RF 不等于节点数、或 RF 调整时必须停机并按“full repair → ALTER → full repair → cleanup”的顺序操作。最后不要忘记配套切换 snitch 并配置cassandra-rackdc.properties并在日常运维中坚持定期 repair。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考