【问题标题】:Cassandra repair after datacenter went down数据中心宕机后的 Cassandra 修复
【发布时间】:2019-04-10 08:34:18
【问题描述】:

我有一个在 AWS 中运行的 Cassandra db(版本 3.11.2),有 2 个数据中心 - 每个位于另一个 AWS 区域,每个区域有 3 个节点。

所有键空间的复制因子为 3,因此每个节点上的数据都完全复制。每个节点的数据大小约为 10GB。 我们所有的写入都在针对一个 DC(我们称之为 DC1)的 LOCAL_QUORUM 中。基本上另一个 DC 只是为了一种备份和灾难恢复,如果 DC1 的 AWS 区域不可用,我们会将流量重定向到 DC2。

我的问题是两个 DC 之间的网络断开连接了几个小时,几天后我们注意到 DC2 中的数据丢失。这一切都是有道理的,因为 DC 分开的时间大于提示切换窗口(3 小时)。所以我们需要进行修复以使 DC2 恢复与 DC1 的同步。

我浏览了 cassandra 文档,阅读了无数的 SO 答案,我一生都无法理解什么是正确的修复方法...... 我是否需要仅从一个节点发出“nodetool repair --full --sequential”?我需要在集群中的每个节点上运行它吗?也许最好运行“nodetool rebuild”?

【问题讨论】:

  • 只要不将修复隔离到 local_dc 就可以了。它将比较来自所有 DC 的副本以得出“正确”的答案。所以你可以简单地运行“nodetool repair”,它应该会给你你想要的

标签: cassandra


【解决方案1】:

在 datacenter2 上的节点上执行 nodetool cleanup 应该能够使数据同步,但根据受影响的数据大小,这可能是一项需要时间和资源的任务。如果 datacenter2 仅作为灾难恢复的备份,备份当前 dc1 集群并在第二个 datacenter 中恢复可能会更容易、更快捷(更多信息可在here 获取。

【讨论】:

  • 当您说“在节点上执行 nodetool 修复”时,实际上是指登录每个节点并运行修复命令(究竟是哪个?),还是只运行一次就足够了从一个节点,假设复制因子是 3?
  • 嗨@a_netanel,我错了,我的意思是输入nodetool cleanup
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-01-01
  • 1970-01-01
  • 2023-04-06
  • 1970-01-01
  • 1970-01-01
  • 2020-10-08
  • 1970-01-01
相关资源
最近更新 更多