向现有 ScyllaDB 集群添加新数据中心DC完整操作指南与源码级原理解析【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb本指南系统讲解如何在单数据中心、多可用区Multi-AZ或多数据中心部署中为正在运行的 ScyllaDB 集群平滑新增一个数据中心DC涵盖前置条件、snitch 与cassandra-rackdc.properties配置、keyspace 复制策略Replication Strategy更新、nodetool rebuild数据重建、全集群 repair 以及客户端流量隔离等完整流程。读完本文你将掌握一套可复制、可验证的多数据中心扩容方案并能理解NetworkTopologyStrategy、tablets 键空间与 rack list 复制因子在扩容中的底层行为。为什么需要往现有集群添加 DC为正在运行的 ScyllaDB 集群新增一个数据中心DC是一种典型的**横向扩展out-scaling**操作它把数据副本分布到更多、通常是地理上更远的节点集合中。这样做带来的收益包括更高可用性HA多副本跨数据中心分布后单个 DC 的整体故障如区域断电、网络分区不会导致数据不可用更低的跨区延迟把数据副本放在靠近用户的 DC配合LOCAL_*一致性级别客户端可以就近读取为多可用区multi-AZ或多地域multi-region容灾架构打基础。该过程在官方文档中与以下操作并列属于集群管理cluster management系列创建集群create-cluster.rst、创建多 DC 集群create-cluster-multidc.rst、移除数据中心decommissioning-data-center.rst以及向集群添加节点add-node-to-cluster.rst。本文聚焦在已有集群上新增一个 DC这一增量场景。整体流程包含以下阶段在新 DC 安装节点将新节点加入集群更新所选 keyspace 的复制策略使其覆盖新 DC对新节点执行 rebuild执行全集群 repair更新监控栈Monitoring stack。重要提示必须在全部流程完成之前、开始从新数据中心读取数据之前读完本指南。默认情况下新 DC 加入后会被用于读操作这一点需要特别留意。前置条件Prerequisites在开始动手之前需要逐项确认以下条件1. 收集现有集群信息登录集群中的任意一个节点收集以下信息来源见 _common/prereq.rst信息项获取命令cluster_namegrep cluster_name /etc/scylla/scylla.yamlseedsgrep seeds: /etc/scylla/scylla.yamlendpoint_snitchgrep endpoint_snitch /etc/scylla/scylla.yamlScyllaDB 版本scylla --versionAuthenticatorgrep authenticator /etc/scylla/scylla.yaml其中cluster_name、seeds、endpoint_snitch三项在配置新 DC 节点时必须与现有集群完全一致详见下文。2. 客户端一致性级别切换为 LOCAL_*在所有客户端应用上将一致性级别Consistency Level切换到LOCAL_*系列LOCAL_ONE、LOCAL_QUORUM等以防止协调节点coordinator访问正在添加的数据中心。3. 安装干净的新 ScyllaDB 节点在新数据中心安装全新的、无任何数据的 ScyllaDB 节点关于干净的要求见下文 清理节点数据节点数量按需创建。安装步骤参见入门指南但只执行到scylla.yaml配置阶段为止不要提前启动节点。如果节点在安装过程中自动启动了请参照节点自动启动的处理先停止服务、清空数据、再启动以确保系统表反映正确的状态。4. 集群拓扑变更需要 quorum更新集群拓扑要求集群中至少有一半以上quorum节点可用。如果 quorum 已丢失必须先恢复它再变更拓扑参见处理节点故障。可以使用nodetool status检查集群中节点的状态命令文档见 nodetool status。这一要求源自 _common/quorum-requirement.rst是保证拓扑变更期间集群元数据一致性的前提。清理节点数据Clean Data from Nodes警告新加入的节点必须是干净的无任何数据否则有数据丢失风险。官方提供的清理命令如下来源clean-data-code.rstsudo rm -rf /var/lib/scylla/data sudo find /var/lib/scylla/commitlog -type f -delete sudo find /var/lib/scylla/hints -type f -delete sudo find /var/lib/scylla/view_hints -type f -delete说明该命令依次清空数据目录data、提交日志commitlog、hint 文件hints与物化视图 hint 文件view_hints。执行前请确认该节点不是现有集群中的任何节点——它必须是一台全新安装、从未承载过数据的机器。若只是启动过早导致的脏状态可参照 clear-data.rst 中停止服务 → 清理数据 → 启动服务 →nodetool status验证的流程处理。添加新 DC 的完整步骤Add New DC步骤一确认所有 keyspace 使用 NetworkTopologyStrategy警告请确保所有** keyspace 都使用NetworkTopologyStrategy。** 如果不是请先执行从 Simple 拓扑策略升级到 Network 策略检查用户 keyspace 与系统 keyspacesystem_distributed、system_traces、system_audit是否使用了SimpleStrategy满足所有节点在同一 rack或RF 等于节点总数等条件时可选择无停机流程否则需按文档执行停机流程停止流量 → 全量 repair → 改策略 → 再次 repair →nodetool cleanup→ 恢复流量。原因在于SimpleStrategy不感知数据中心与 rack 布局无法把副本定向放置到新 DC跨 DC 复制必须依赖NetworkTopologyStrategy。步骤二为现有数据中心配置正确的 Snitch对现有数据中心的每个节点编辑scylla.yaml中的endpoint_snitch二选一Ec2MultiRegionSnitch—— 用于AWS 云上、跨多数据中心的部署GossipingPropertyFileSnitch—— 用于裸金属bare metal以及 AWS 之外的云部署。从源码看这两种 snitch 的实现分别位于 locator/ec2_multi_region_snitch.cc 与 locator/gossiping_property_file_snitch.cc。其中Ec2MultiRegionSnitch需要公网 IP 作为broadcast_address以支持跨 region 通信并通过 AWS metadata 服务/latest/meta-data/public-ipv4、/latest/meta-data/local-ipv4获取地址信息见 ec2_multi_region_snitch.cc#L16-L20它还会在 gossip 阶段向集群广播DC与RACK应用状态见 ec2_multi_region_snitch.cc#L83-L89这是跨 DC 节点能够识别彼此拓扑的关键机制。步骤三设置 DC 与 Rack 名称编辑cassandra-rackdc.properties文件位于/etc/scylla/下仓库中的模板见 conf/cassandra-rackdc.properties按所选 snitch 配置Ec2MultiRegionSnitch该 snitch 会给每个 DC 和 rack 提供默认名称region 名作为数据中心名可用区Availability Zone作为 DC 内的 rack。例如位于us-east-1region 的节点us-east是数据中心名1是 rack 位置。可以通过dc_suffix为数据中心名追加后缀。例如regionus-east配置dc_suffix_1_scylla→ 数据中心名为us-east_1_scyllaregionus-west配置dc_suffix_1_scylla→ 数据中心名为us-west_1_scylla这一后缀机制在源码中有直接体现ec2_snitch会调用 AWS metadata 服务获取可用区如us-east-1a将其解析为us-eastDC1arack然后从属性文件读取dc_suffix追加到 DC 名后见 locator/ec2_snitch.cc#L27-L51 与 locator/ec2_snitch.cc#L142-L152。GossipingPropertyFileSnitchdc—— 设置数据中心名rack—— 设置 rack 名。示例文件模板来自 conf/cassandra-rackdc.properties# cassandra-rackdc.properties # # The lines may include white spaces at the beginning and the end. # The rack and data center names may also include white spaces. # All trailing and leading white spaces will be trimmed. # dcthedatacentername racktherackname # prefer_localfalse | true # dc_suffixData Center name suffix, used by EC2SnitchXXX snitches源码中production_snitch_base定义了这些属性键dc、rack、prefer_local、dc_suffix见 locator/production_snitch_base.hh#L34-L37并允许从属性文件中加载 DC/rack 名称见 locator/production_snitch_base.cc#L48-L60。GossipingPropertyFileSnitch通过 gossip 把本地 DC/rack 信息传播给其他节点使整个集群获得一致的拓扑视图默认prefer_local为false见 locator/gossiping_property_file_snitch.cc#L130-L131配置为true可让节点优先使用同 DC 内的节点进行通信。注意属性文件中 DC/rack 名称允许包含首尾空白ScyllaDB 读取时会自动 trim。步骤四逐个重启现有数据中心节点在现有数据中心中逐个重启 ScyllaDB 节点不要同时重启全部节点使新的 snitch / DC / rack 配置生效支持的操作系统OSsudo systemctl restart scylla-serverDocker 部署不重启容器仅重启容器内的 scylla 服务docker exec -it some-scylla supervisorctl restart scylla步骤五配置新数据中心的节点对新数据中心的每个节点编辑/etc/scylla/scylla.yaml中的以下参数参数含义要求cluster_name集群名称必须与现有集群一致seeds现有集群中一个或多个节点的 IP必须指向现有集群节点listen_addressScyllaDB 用于连接集群内其他节点的 IP按节点实际网络配置endpoint_snitch选择的 snitch必须与现有集群一致rpc_addressCQL 客户端连接地址按节点实际网络配置其中seeds、cluster_name和endpoint_snitch必须与现有集群匹配。这些参数在源码 db/config.cc 中有明确定义cluster_name用于防止不同逻辑集群中的机器互相加入同一集群的所有节点必须使用相同值db/config.cc#L764-L765listen_address节点绑定用于与其他 ScyllaDB 节点通信的 IP/主机名多节点部署必须修改默认值db/config.cc#L766-L767endpoint_snitch决定节点定位与请求路由GossipingPropertyFileSnitch被官方推荐用于生产环境db/config.cc#L824-L834rpc_address原生传输CQL的监听地址db/config.cc#L835-L842。此外若使用Ec2MultiRegionSnitch还需把broadcast_address设为公网 IP、listen_address设为私网 IP并确保种子地址使用公网 IP、存储端口storage_port或ssl_storage_port在公网防火墙放行见 db/config.cc#L1071-L1073 与 endpoint_snitch 说明。步骤六设置新 DC 的 DC 与 Rack 名称在新数据中心的每个节点上按步骤三的方法设置 DC 与 Rack 名称编辑/etc/scylla/cassandra-rackdc.properties。建议新 DC 使用与现有 DC 不同的 DC 名例如ASIA-DC以便NetworkTopologyStrategy按 DC 区分副本放置。步骤七逐个启动新数据中心节点在新数据中心中逐个启动 ScyllaDB 节点支持的操作系统OSsudo systemctl start scylla-serverDocker 部署容器已运行仅启动容器内的 scylla 服务docker exec -it some-scylla supervisorctl start scylla步骤八验证节点已加入集群使用nodetool status验证新节点是否已成功加入集群。示例输出$ nodetool status Datacenter: US-DC StatusUp/Down |/ StateNormal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 54.191.2.121 120.97 KB 256 ? c84b80ea-cb60-422b-bc72-fa86ede4ac2e RACK1 UN 54.191.72.56 109.54 KB 256 ? 129087eb-9aea-4af6-92c6-99fdadb39c33 RACK1 UN 54.187.25.99 104.94 KB 256 ? 0540c7d7-2622-4f1f-a3f0-acb39282e0fc RACK1 Datacenter: ASIA-DC StatusUp/Down |/ StateNormal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 54.160.174.243 109.54 KB 256 ? c7686ffd-7a5b-4124-858e-df2e61130aaa RACK1 UN 54.235.9.159 109.75 KB 256 ? 39798227-9f6f-4868-8193-08570856c09a RACK1 UN 54.146.228.25 128.33 KB 256 ? 7a4957a1-9590-4434-9746-9c8a6f796a0c RACK1解读UN表示节点处于Up在线且状态为Normal正常每行按Datacenter分组展示地址、负载、token 数、所有权Owns、Host ID 与 Rack。所有节点都应显示为UN才算加入成功。步骤九ALTER keyspace 复制策略核心步骤当所有节点都已上线后需要在新节点上执行ALTER KEYSPACE把以下 keyspace 的复制策略扩展到新 DC用户创建的 keyspace需要复制到新 DC 的那些系统 keyspacesystem_distributed、system_traces例如在新 DC 复制 3 份audit若已启用——在新 DC 复制 3 份。vnode keyspace 示例使用数字 RFBeforeDESCRIBE KEYSPACE mykeyspace; CREATE KEYSPACE mykeyspace WITH replication { class : NetworkTopologyStrategy, existing_dc : 3};ALTER 命令ALTER KEYSPACE mykeyspace WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3}; ALTER KEYSPACE system_distributed WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3}; ALTER KEYSPACE system_traces WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3};AfterDESCRIBE KEYSPACE mykeyspace; CREATE KEYSPACE mykeyspace WITH REPLICATION {class: NetworkTopologyStrategy, existing_dc : 3, new_dc : 3}; CREATE KEYSPACE system_distributed WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3}; CREATE KEYSPACE system_traces WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3};tablets keyspace数字 RF复制因子要一步一步地加。BeforeDESCRIBE KEYSPACE mykeyspace2; CREATE KEYSPACE mykeyspace2 WITH replication { class : NetworkTopologyStrategy, existing_dc : 3} AND tablets { enabled: true };逐步 ALTER每次只加 1ALTER KEYSPACE mykeyspace2 WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 1} AND tablets { enabled: true }; ALTER KEYSPACE mykeyspace2 WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 2} AND tablets { enabled: true }; ALTER KEYSPACE mykeyspace2 WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3} AND tablets { enabled: true };说明tablets 是 ScyllaDB 的新一代数据分布机制把每个表的数据按 range 切分为 tablet并在节点间自动均衡见 docs/architecture/tablets.rst。tablets keyspace 在ALTER KEYSPACE后会触发后台的 tablet 迁移/复制因此官方文档强调逐次递增 RF避免一次性大幅变更带来的复制压力。启用rf_rack_valid_keyspaces时的 rack list 场景如果设置了rf_rack_valid_keyspaces选项tablet keyspace 必须使用rack list 复制因子这样新的 DCrack才能被加入。具体转换流程参见 CQL DDL 文档中的 conversion-to-rack-list-rf 小节迁移时 rack 列表中的 rack 数量必须等于当前数字 RF且同一语句中不允许同时做 RF 增减。此时添加数据中心的操作为Before现有 DC 使用 rack listDESCRIBE KEYSPACE mykeyspace3; CREATE KEYSPACE mykeyspace3 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3]} AND tablets { enabled: true };先把所有节点加入新数据中心然后逐步 ALTERALTER KEYSPACE mykeyspace3 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1]} AND tablets { enabled: true }; ALTER KEYSPACE mykeyspace3 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2]} AND tablets { enabled: true }; ALTER KEYSPACE mykeyspace3 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };AfterDESCRIBE KEYSPACE mykeyspace3; CREATE KEYSPACE mykeyspace3 WITH REPLICATION {class: NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };可以考虑把rf_rack_valid_keyspaces升级为enforce_rack_list选项以确保所有 tablet keyspace 都使用 rack list转换流程与启用条件见 docs/architecture/tablets.rst#L208-L223enforce_rack_list只有在所有 tablet keyspace 都已使用 rack list 时才能开启开启后需重启所有节点且重启期间不要执行任何 CREATE/ALTER KEYSPACE。rack list 场景下的 ALTER 规则一次ALTER KEYSPACE语句内必须遵守现有数据中心必须保持当前复制因子不变新数据中心可以被赋予复制因子0 到 N现有数据中心可以被移除N 到 0。错误示例——同一语句既修改了existing_dc的 rack 列表加入了existing_rack4又添加了新 DC这是不允许的ALTER KEYSPACE mykeyspace4 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3, existing_rack4], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };正确做法先把所有节点加入新数据中心然后单独执行一条只新增new_dcrack list 的语句ALTER KEYSPACE mykeyspace4 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };AfterDESCRIBE KEYSPACE mykeyspace4; CREATE KEYSPACE mykeyspace4 WITH REPLICATION {class: NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };补充背景当配置中启用了enforce_rack_list或已弃用的rf_rack_valid_keyspaces且 keyspace 基于 tablet 时数字复制因子会在语句执行时被自动展开为 rack list这一展开结果可以在随后的DESCRIBE输出中观察到如果数字 RF 小于 DC 内的 rack 数量系统会任意选择一部分 rack见 docs/cql/ddl.rst#L193-L201。一致性级别警告添加新数据中心并 ALTER keyspace 期间不要执行任何涉及新数据中心的读写操作。尤其要避免使用会把新 DC 纳入操作范围的全局一致性级别如ALL、EACH_QUORUM在新 DC 完全就绪之前请一直使用LOCAL_*一致性级别如LOCAL_QUORUM、LOCAL_ONE。任务管理keyspace 变更可能耗时较长你可以使用 Task manager 中止正在进行的 keyspace 变更。Task manager 会跟踪压缩compaction等长时间运行的后台操作任务以树形结构组织其中集群级任务cluster task对所有节点可见。步骤十对新 DC 节点执行 nodetool rebuild如果任何vnode keyspace被变更过请在新数据中心的每个节点上运行nodetool rebuild并指定现有数据中心的名字nodetool rebuild existing_data_center_namenodetool rebuild会以类似 bootstrap 的方式从集群中其他节点流式拉取stream数据先计算本地节点负责的 range再确定集群中哪些节点持有相同 range若指定了source-dc-name则优先只从该数据中心的节点拉取见 docs/operating-scylla/nodetool-commands/rebuild.rst#L4-L14。rebuild 过程会持续在后台运行即使 nodetool 命令被 kill 或中断也不会停止见 rebuild.rst#L19。rebuild 能确保新加入集群的节点识别出集群中已有的数据中心从而正确完成数据同步。注意nodetool rebuild仅适用于 vnode keyspace。对于 tablet keyspace请改用nodetool cluster repair见 rebuild.rst#L28。步骤十一执行全集群 repair如果任何 vnode keyspace 被变更过请执行全集群 repair在每个节点上运行nodetool repair -pr或使用 ScyllaDB Manager 的 ad-hoc repair 功能。nodetool repair -pr中的-prprimary range只修复本节点作为 primary replica 的 range这样可以在全集群每个节点依次执行从而以最小冗余完成全量数据同步参见 docs/operating-scylla/nodetool-commands/repair.rst。repair 应定期执行如果删除数据频繁执行间隔应短于gc_grace_seconds默认 10 天。步骤十二更新监控与运维栈如果使用ScyllaDB Monitoring请更新监控栈以覆盖新 DC通过从文件配置 Scylla 节点的方式添加新节点如果使用ScyllaDB Manager请在新 DC 的节点上安装Manager Agent并确保 Manager 能够访问新 DC。配置客户端不连接新 DC本节提供一种方法让客户端暂时不要连接刚添加的 DC。以下示例针对 Java driver请按需调整。在客户端将操作一致性级别设为CLLOCAL_*例如LOCAL_QUORUM并使用DCAwareRoundRobinPolicy——通过withLocalDc(dcLocalToTheClient)指定客户端本地的 DC通过withUsedHostsPerRemoteDc(0)禁止使用任何远程 DC 节点variable DCAwareRoundRobinPolicy.builder() .withLocalDc(name of DC local to the client being configured) .withUsedHostsPerRemoteDc(0) .build();一旦新 DC 完全就绪数据重建、repair 全部完成就可以从配置中移除withUsedHostsPerRemoteDc(0)并把一致性级别恢复为之前的取值。这一客户端策略与前置条件中把所有客户端切换到LOCAL_*相呼应两者共同保证在扩容窗口期内任何读写流量都不会触达尚未就绪的新 DC。相关资源集群管理操作索引docs/operating-scylla/procedures/cluster-management/index.rst从 Simple 策略升级到 Network 策略update-topology-strategy-from-simple-to-network.rst节点自动启动后的清理clear-data.rst创建多 DC 集群create-cluster-multidc.rst移除数据中心反向操作decommissioning-data-center.rstnodetool statusdocs/operating-scylla/nodetool-commands/status.rstnodetool rebuilddocs/operating-scylla/nodetool-commands/rebuild.rstnodetool repairdocs/operating-scylla/nodetool-commands/repair.rsttablets 架构docs/architecture/tablets.rstCQL DDL 与复制策略细节docs/cql/ddl.rst【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
向现有 ScyllaDB 集群添加新数据中心（DC）：完整操作指南与源码级原理解析
向现有 ScyllaDB 集群添加新数据中心DC完整操作指南与源码级原理解析【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb本指南系统讲解如何在单数据中心、多可用区Multi-AZ或多数据中心部署中为正在运行的 ScyllaDB 集群平滑新增一个数据中心DC涵盖前置条件、snitch 与cassandra-rackdc.properties配置、keyspace 复制策略Replication Strategy更新、nodetool rebuild数据重建、全集群 repair 以及客户端流量隔离等完整流程。读完本文你将掌握一套可复制、可验证的多数据中心扩容方案并能理解NetworkTopologyStrategy、tablets 键空间与 rack list 复制因子在扩容中的底层行为。为什么需要往现有集群添加 DC为正在运行的 ScyllaDB 集群新增一个数据中心DC是一种典型的**横向扩展out-scaling**操作它把数据副本分布到更多、通常是地理上更远的节点集合中。这样做带来的收益包括更高可用性HA多副本跨数据中心分布后单个 DC 的整体故障如区域断电、网络分区不会导致数据不可用更低的跨区延迟把数据副本放在靠近用户的 DC配合LOCAL_*一致性级别客户端可以就近读取为多可用区multi-AZ或多地域multi-region容灾架构打基础。该过程在官方文档中与以下操作并列属于集群管理cluster management系列创建集群create-cluster.rst、创建多 DC 集群create-cluster-multidc.rst、移除数据中心decommissioning-data-center.rst以及向集群添加节点add-node-to-cluster.rst。本文聚焦在已有集群上新增一个 DC这一增量场景。整体流程包含以下阶段在新 DC 安装节点将新节点加入集群更新所选 keyspace 的复制策略使其覆盖新 DC对新节点执行 rebuild执行全集群 repair更新监控栈Monitoring stack。重要提示必须在全部流程完成之前、开始从新数据中心读取数据之前读完本指南。默认情况下新 DC 加入后会被用于读操作这一点需要特别留意。前置条件Prerequisites在开始动手之前需要逐项确认以下条件1. 收集现有集群信息登录集群中的任意一个节点收集以下信息来源见 _common/prereq.rst信息项获取命令cluster_namegrep cluster_name /etc/scylla/scylla.yamlseedsgrep seeds: /etc/scylla/scylla.yamlendpoint_snitchgrep endpoint_snitch /etc/scylla/scylla.yamlScyllaDB 版本scylla --versionAuthenticatorgrep authenticator /etc/scylla/scylla.yaml其中cluster_name、seeds、endpoint_snitch三项在配置新 DC 节点时必须与现有集群完全一致详见下文。2. 客户端一致性级别切换为 LOCAL_*在所有客户端应用上将一致性级别Consistency Level切换到LOCAL_*系列LOCAL_ONE、LOCAL_QUORUM等以防止协调节点coordinator访问正在添加的数据中心。3. 安装干净的新 ScyllaDB 节点在新数据中心安装全新的、无任何数据的 ScyllaDB 节点关于干净的要求见下文 清理节点数据节点数量按需创建。安装步骤参见入门指南但只执行到scylla.yaml配置阶段为止不要提前启动节点。如果节点在安装过程中自动启动了请参照节点自动启动的处理先停止服务、清空数据、再启动以确保系统表反映正确的状态。4. 集群拓扑变更需要 quorum更新集群拓扑要求集群中至少有一半以上quorum节点可用。如果 quorum 已丢失必须先恢复它再变更拓扑参见处理节点故障。可以使用nodetool status检查集群中节点的状态命令文档见 nodetool status。这一要求源自 _common/quorum-requirement.rst是保证拓扑变更期间集群元数据一致性的前提。清理节点数据Clean Data from Nodes警告新加入的节点必须是干净的无任何数据否则有数据丢失风险。官方提供的清理命令如下来源clean-data-code.rstsudo rm -rf /var/lib/scylla/data sudo find /var/lib/scylla/commitlog -type f -delete sudo find /var/lib/scylla/hints -type f -delete sudo find /var/lib/scylla/view_hints -type f -delete说明该命令依次清空数据目录data、提交日志commitlog、hint 文件hints与物化视图 hint 文件view_hints。执行前请确认该节点不是现有集群中的任何节点——它必须是一台全新安装、从未承载过数据的机器。若只是启动过早导致的脏状态可参照 clear-data.rst 中停止服务 → 清理数据 → 启动服务 →nodetool status验证的流程处理。添加新 DC 的完整步骤Add New DC步骤一确认所有 keyspace 使用 NetworkTopologyStrategy警告请确保所有** keyspace 都使用NetworkTopologyStrategy。** 如果不是请先执行从 Simple 拓扑策略升级到 Network 策略检查用户 keyspace 与系统 keyspacesystem_distributed、system_traces、system_audit是否使用了SimpleStrategy满足所有节点在同一 rack或RF 等于节点总数等条件时可选择无停机流程否则需按文档执行停机流程停止流量 → 全量 repair → 改策略 → 再次 repair →nodetool cleanup→ 恢复流量。原因在于SimpleStrategy不感知数据中心与 rack 布局无法把副本定向放置到新 DC跨 DC 复制必须依赖NetworkTopologyStrategy。步骤二为现有数据中心配置正确的 Snitch对现有数据中心的每个节点编辑scylla.yaml中的endpoint_snitch二选一Ec2MultiRegionSnitch—— 用于AWS 云上、跨多数据中心的部署GossipingPropertyFileSnitch—— 用于裸金属bare metal以及 AWS 之外的云部署。从源码看这两种 snitch 的实现分别位于 locator/ec2_multi_region_snitch.cc 与 locator/gossiping_property_file_snitch.cc。其中Ec2MultiRegionSnitch需要公网 IP 作为broadcast_address以支持跨 region 通信并通过 AWS metadata 服务/latest/meta-data/public-ipv4、/latest/meta-data/local-ipv4获取地址信息见 ec2_multi_region_snitch.cc#L16-L20它还会在 gossip 阶段向集群广播DC与RACK应用状态见 ec2_multi_region_snitch.cc#L83-L89这是跨 DC 节点能够识别彼此拓扑的关键机制。步骤三设置 DC 与 Rack 名称编辑cassandra-rackdc.properties文件位于/etc/scylla/下仓库中的模板见 conf/cassandra-rackdc.properties按所选 snitch 配置Ec2MultiRegionSnitch该 snitch 会给每个 DC 和 rack 提供默认名称region 名作为数据中心名可用区Availability Zone作为 DC 内的 rack。例如位于us-east-1region 的节点us-east是数据中心名1是 rack 位置。可以通过dc_suffix为数据中心名追加后缀。例如regionus-east配置dc_suffix_1_scylla→ 数据中心名为us-east_1_scyllaregionus-west配置dc_suffix_1_scylla→ 数据中心名为us-west_1_scylla这一后缀机制在源码中有直接体现ec2_snitch会调用 AWS metadata 服务获取可用区如us-east-1a将其解析为us-eastDC1arack然后从属性文件读取dc_suffix追加到 DC 名后见 locator/ec2_snitch.cc#L27-L51 与 locator/ec2_snitch.cc#L142-L152。GossipingPropertyFileSnitchdc—— 设置数据中心名rack—— 设置 rack 名。示例文件模板来自 conf/cassandra-rackdc.properties# cassandra-rackdc.properties # # The lines may include white spaces at the beginning and the end. # The rack and data center names may also include white spaces. # All trailing and leading white spaces will be trimmed. # dcthedatacentername racktherackname # prefer_localfalse | true # dc_suffixData Center name suffix, used by EC2SnitchXXX snitches源码中production_snitch_base定义了这些属性键dc、rack、prefer_local、dc_suffix见 locator/production_snitch_base.hh#L34-L37并允许从属性文件中加载 DC/rack 名称见 locator/production_snitch_base.cc#L48-L60。GossipingPropertyFileSnitch通过 gossip 把本地 DC/rack 信息传播给其他节点使整个集群获得一致的拓扑视图默认prefer_local为false见 locator/gossiping_property_file_snitch.cc#L130-L131配置为true可让节点优先使用同 DC 内的节点进行通信。注意属性文件中 DC/rack 名称允许包含首尾空白ScyllaDB 读取时会自动 trim。步骤四逐个重启现有数据中心节点在现有数据中心中逐个重启 ScyllaDB 节点不要同时重启全部节点使新的 snitch / DC / rack 配置生效支持的操作系统OSsudo systemctl restart scylla-serverDocker 部署不重启容器仅重启容器内的 scylla 服务docker exec -it some-scylla supervisorctl restart scylla步骤五配置新数据中心的节点对新数据中心的每个节点编辑/etc/scylla/scylla.yaml中的以下参数参数含义要求cluster_name集群名称必须与现有集群一致seeds现有集群中一个或多个节点的 IP必须指向现有集群节点listen_addressScyllaDB 用于连接集群内其他节点的 IP按节点实际网络配置endpoint_snitch选择的 snitch必须与现有集群一致rpc_addressCQL 客户端连接地址按节点实际网络配置其中seeds、cluster_name和endpoint_snitch必须与现有集群匹配。这些参数在源码 db/config.cc 中有明确定义cluster_name用于防止不同逻辑集群中的机器互相加入同一集群的所有节点必须使用相同值db/config.cc#L764-L765listen_address节点绑定用于与其他 ScyllaDB 节点通信的 IP/主机名多节点部署必须修改默认值db/config.cc#L766-L767endpoint_snitch决定节点定位与请求路由GossipingPropertyFileSnitch被官方推荐用于生产环境db/config.cc#L824-L834rpc_address原生传输CQL的监听地址db/config.cc#L835-L842。此外若使用Ec2MultiRegionSnitch还需把broadcast_address设为公网 IP、listen_address设为私网 IP并确保种子地址使用公网 IP、存储端口storage_port或ssl_storage_port在公网防火墙放行见 db/config.cc#L1071-L1073 与 endpoint_snitch 说明。步骤六设置新 DC 的 DC 与 Rack 名称在新数据中心的每个节点上按步骤三的方法设置 DC 与 Rack 名称编辑/etc/scylla/cassandra-rackdc.properties。建议新 DC 使用与现有 DC 不同的 DC 名例如ASIA-DC以便NetworkTopologyStrategy按 DC 区分副本放置。步骤七逐个启动新数据中心节点在新数据中心中逐个启动 ScyllaDB 节点支持的操作系统OSsudo systemctl start scylla-serverDocker 部署容器已运行仅启动容器内的 scylla 服务docker exec -it some-scylla supervisorctl start scylla步骤八验证节点已加入集群使用nodetool status验证新节点是否已成功加入集群。示例输出$ nodetool status Datacenter: US-DC StatusUp/Down |/ StateNormal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 54.191.2.121 120.97 KB 256 ? c84b80ea-cb60-422b-bc72-fa86ede4ac2e RACK1 UN 54.191.72.56 109.54 KB 256 ? 129087eb-9aea-4af6-92c6-99fdadb39c33 RACK1 UN 54.187.25.99 104.94 KB 256 ? 0540c7d7-2622-4f1f-a3f0-acb39282e0fc RACK1 Datacenter: ASIA-DC StatusUp/Down |/ StateNormal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 54.160.174.243 109.54 KB 256 ? c7686ffd-7a5b-4124-858e-df2e61130aaa RACK1 UN 54.235.9.159 109.75 KB 256 ? 39798227-9f6f-4868-8193-08570856c09a RACK1 UN 54.146.228.25 128.33 KB 256 ? 7a4957a1-9590-4434-9746-9c8a6f796a0c RACK1解读UN表示节点处于Up在线且状态为Normal正常每行按Datacenter分组展示地址、负载、token 数、所有权Owns、Host ID 与 Rack。所有节点都应显示为UN才算加入成功。步骤九ALTER keyspace 复制策略核心步骤当所有节点都已上线后需要在新节点上执行ALTER KEYSPACE把以下 keyspace 的复制策略扩展到新 DC用户创建的 keyspace需要复制到新 DC 的那些系统 keyspacesystem_distributed、system_traces例如在新 DC 复制 3 份audit若已启用——在新 DC 复制 3 份。vnode keyspace 示例使用数字 RFBeforeDESCRIBE KEYSPACE mykeyspace; CREATE KEYSPACE mykeyspace WITH replication { class : NetworkTopologyStrategy, existing_dc : 3};ALTER 命令ALTER KEYSPACE mykeyspace WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3}; ALTER KEYSPACE system_distributed WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3}; ALTER KEYSPACE system_traces WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3};AfterDESCRIBE KEYSPACE mykeyspace; CREATE KEYSPACE mykeyspace WITH REPLICATION {class: NetworkTopologyStrategy, existing_dc : 3, new_dc : 3}; CREATE KEYSPACE system_distributed WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3}; CREATE KEYSPACE system_traces WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3};tablets keyspace数字 RF复制因子要一步一步地加。BeforeDESCRIBE KEYSPACE mykeyspace2; CREATE KEYSPACE mykeyspace2 WITH replication { class : NetworkTopologyStrategy, existing_dc : 3} AND tablets { enabled: true };逐步 ALTER每次只加 1ALTER KEYSPACE mykeyspace2 WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 1} AND tablets { enabled: true }; ALTER KEYSPACE mykeyspace2 WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 2} AND tablets { enabled: true }; ALTER KEYSPACE mykeyspace2 WITH replication { class : NetworkTopologyStrategy, existing_dc : 3, new_dc : 3} AND tablets { enabled: true };说明tablets 是 ScyllaDB 的新一代数据分布机制把每个表的数据按 range 切分为 tablet并在节点间自动均衡见 docs/architecture/tablets.rst。tablets keyspace 在ALTER KEYSPACE后会触发后台的 tablet 迁移/复制因此官方文档强调逐次递增 RF避免一次性大幅变更带来的复制压力。启用rf_rack_valid_keyspaces时的 rack list 场景如果设置了rf_rack_valid_keyspaces选项tablet keyspace 必须使用rack list 复制因子这样新的 DCrack才能被加入。具体转换流程参见 CQL DDL 文档中的 conversion-to-rack-list-rf 小节迁移时 rack 列表中的 rack 数量必须等于当前数字 RF且同一语句中不允许同时做 RF 增减。此时添加数据中心的操作为Before现有 DC 使用 rack listDESCRIBE KEYSPACE mykeyspace3; CREATE KEYSPACE mykeyspace3 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3]} AND tablets { enabled: true };先把所有节点加入新数据中心然后逐步 ALTERALTER KEYSPACE mykeyspace3 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1]} AND tablets { enabled: true }; ALTER KEYSPACE mykeyspace3 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2]} AND tablets { enabled: true }; ALTER KEYSPACE mykeyspace3 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };AfterDESCRIBE KEYSPACE mykeyspace3; CREATE KEYSPACE mykeyspace3 WITH REPLICATION {class: NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };可以考虑把rf_rack_valid_keyspaces升级为enforce_rack_list选项以确保所有 tablet keyspace 都使用 rack list转换流程与启用条件见 docs/architecture/tablets.rst#L208-L223enforce_rack_list只有在所有 tablet keyspace 都已使用 rack list 时才能开启开启后需重启所有节点且重启期间不要执行任何 CREATE/ALTER KEYSPACE。rack list 场景下的 ALTER 规则一次ALTER KEYSPACE语句内必须遵守现有数据中心必须保持当前复制因子不变新数据中心可以被赋予复制因子0 到 N现有数据中心可以被移除N 到 0。错误示例——同一语句既修改了existing_dc的 rack 列表加入了existing_rack4又添加了新 DC这是不允许的ALTER KEYSPACE mykeyspace4 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3, existing_rack4], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };正确做法先把所有节点加入新数据中心然后单独执行一条只新增new_dcrack list 的语句ALTER KEYSPACE mykeyspace4 WITH replication { class : NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };AfterDESCRIBE KEYSPACE mykeyspace4; CREATE KEYSPACE mykeyspace4 WITH REPLICATION {class: NetworkTopologyStrategy, existing_dc : [existing_rack1, existing_rack2, existing_rack3], new_dc : [new_rack1, new_rack2, new_rack3]} AND tablets { enabled: true };补充背景当配置中启用了enforce_rack_list或已弃用的rf_rack_valid_keyspaces且 keyspace 基于 tablet 时数字复制因子会在语句执行时被自动展开为 rack list这一展开结果可以在随后的DESCRIBE输出中观察到如果数字 RF 小于 DC 内的 rack 数量系统会任意选择一部分 rack见 docs/cql/ddl.rst#L193-L201。一致性级别警告添加新数据中心并 ALTER keyspace 期间不要执行任何涉及新数据中心的读写操作。尤其要避免使用会把新 DC 纳入操作范围的全局一致性级别如ALL、EACH_QUORUM在新 DC 完全就绪之前请一直使用LOCAL_*一致性级别如LOCAL_QUORUM、LOCAL_ONE。任务管理keyspace 变更可能耗时较长你可以使用 Task manager 中止正在进行的 keyspace 变更。Task manager 会跟踪压缩compaction等长时间运行的后台操作任务以树形结构组织其中集群级任务cluster task对所有节点可见。步骤十对新 DC 节点执行 nodetool rebuild如果任何vnode keyspace被变更过请在新数据中心的每个节点上运行nodetool rebuild并指定现有数据中心的名字nodetool rebuild existing_data_center_namenodetool rebuild会以类似 bootstrap 的方式从集群中其他节点流式拉取stream数据先计算本地节点负责的 range再确定集群中哪些节点持有相同 range若指定了source-dc-name则优先只从该数据中心的节点拉取见 docs/operating-scylla/nodetool-commands/rebuild.rst#L4-L14。rebuild 过程会持续在后台运行即使 nodetool 命令被 kill 或中断也不会停止见 rebuild.rst#L19。rebuild 能确保新加入集群的节点识别出集群中已有的数据中心从而正确完成数据同步。注意nodetool rebuild仅适用于 vnode keyspace。对于 tablet keyspace请改用nodetool cluster repair见 rebuild.rst#L28。步骤十一执行全集群 repair如果任何 vnode keyspace 被变更过请执行全集群 repair在每个节点上运行nodetool repair -pr或使用 ScyllaDB Manager 的 ad-hoc repair 功能。nodetool repair -pr中的-prprimary range只修复本节点作为 primary replica 的 range这样可以在全集群每个节点依次执行从而以最小冗余完成全量数据同步参见 docs/operating-scylla/nodetool-commands/repair.rst。repair 应定期执行如果删除数据频繁执行间隔应短于gc_grace_seconds默认 10 天。步骤十二更新监控与运维栈如果使用ScyllaDB Monitoring请更新监控栈以覆盖新 DC通过从文件配置 Scylla 节点的方式添加新节点如果使用ScyllaDB Manager请在新 DC 的节点上安装Manager Agent并确保 Manager 能够访问新 DC。配置客户端不连接新 DC本节提供一种方法让客户端暂时不要连接刚添加的 DC。以下示例针对 Java driver请按需调整。在客户端将操作一致性级别设为CLLOCAL_*例如LOCAL_QUORUM并使用DCAwareRoundRobinPolicy——通过withLocalDc(dcLocalToTheClient)指定客户端本地的 DC通过withUsedHostsPerRemoteDc(0)禁止使用任何远程 DC 节点variable DCAwareRoundRobinPolicy.builder() .withLocalDc(name of DC local to the client being configured) .withUsedHostsPerRemoteDc(0) .build();一旦新 DC 完全就绪数据重建、repair 全部完成就可以从配置中移除withUsedHostsPerRemoteDc(0)并把一致性级别恢复为之前的取值。这一客户端策略与前置条件中把所有客户端切换到LOCAL_*相呼应两者共同保证在扩容窗口期内任何读写流量都不会触达尚未就绪的新 DC。相关资源集群管理操作索引docs/operating-scylla/procedures/cluster-management/index.rst从 Simple 策略升级到 Network 策略update-topology-strategy-from-simple-to-network.rst节点自动启动后的清理clear-data.rst创建多 DC 集群create-cluster-multidc.rst移除数据中心反向操作decommissioning-data-center.rstnodetool statusdocs/operating-scylla/nodetool-commands/status.rstnodetool rebuilddocs/operating-scylla/nodetool-commands/rebuild.rstnodetool repairdocs/operating-scylla/nodetool-commands/repair.rsttablets 架构docs/architecture/tablets.rstCQL DDL 与复制策略细节docs/cql/ddl.rst【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考