1

我正在为现有集群配置一个新的数据中心。一个相当不稳定的 VPN 连接阻碍了我nodetool rebuild对新 DC 的引导。有趣的是，我在与新 DC 相同的位置（转移到 VPN 之外）有一个全新的数据库快照/备份。我现在正在考虑以下方法：

  1. 确保我的客户使用的是旧的 DC。
  2. 在新 DC 中供应新节点。
  3. ALTER在新 DC 上启用副本的密钥空间。这将开始将所有写入从旧 DC 复制到新 DC。
  4. 在gc_grace_seconds上述操作 3) 之后，用于sstableloader将我的备份流式传输到新节点。
  5. 为安全起见，请进行全面维修。

这行得通吗？

4

2 回答 2

1

是的，该方法应该有效。我已经与 Cassandra 社区中的两个知识渊博的人进行了验证。然而，有两件重要的事情需要注意：

  • 在突变开始写入新数据中心之后拍摄快照。
  • 在进行备份之后，必须在 gc_grace_seconds 之前完全导入备份。否则，您可能会冒出僵尸数据的风险。
于 2016-04-21T14:06:56.853 回答
1

我们的团队也面临着类似的情况。我们在 Amazon EC2 上运行 C*。

因此，首先我们准备了现有节点的快照，并使用它们为其他数据中心创建它们（以避免大量数据传输）。

我们遵循的程序：

  1. 将所有 DC1 服务器的复制策略从 simple-strategy 更改为 networkTopologyStrategy {DC1:x, DC2:y}
    1. 更改 cassandra.yaml
      • endpoint_snitch：GossipingPropertyFileSnitch
      • 将 DC2 节点 IP 添加到种子列表
      • 其他不需要改变
    2. 更改 cassandra-rackdc.properties
      • 直流=直流1
      • 机架=RAC1
    3. 一次重启一个节点。
      • 先重启种子节点
    4. 更改键空间。 ALTER KEYSPACE keyspace_name WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'DC1' : x, 'DC2':y };
      • 对 DC1 中的所有键空间执行此操作
    5. 无需维修。
    6. 通过查询验证系统是否稳定
  2. 将 DC2 服务器作为新数据中心添加到 DC1 数据中心
    • https://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_add_dc_to_cluster_t.html
      1. 在 DC2 数据库中，cassandra.yaml > auto_bootstrap: false
      2. 修复种子、endpoint_snitch、集群名称
        • Node1 DC1 IP、Node2 DC2 IP 作为种子。
        • 推荐的 endpoint_snitch ：GossipingPropertyFileSnitch
        • 集群名称，同 DC1：test-cluster
      3. 修复 gossiping-property-file-snith : cassandra-rackdc.properties
        • 直流=直流2
        • 机架=RAC1
      4. 一次启动一个 DC2 节点
        • 种子节点优先
      5. 将键空间更改为 networkTopologyStrategy {DC1:x, DC2:y}
      6. 由于 DC2 数据库是从 DC1 复制的，我们应该修复而不是重建
于 2016-04-20T07:51:57.763 回答