【问题标题】:Migration process to incremental repairs necessary?迁移过程是否需要增量修复?
【发布时间】:2016-12-21 17:19:58
【问题描述】:

我们计划在我们的 Cassandra 集群中激活增量修复,在阅读了 documentation 之后,似乎我们必须遵循 migration procedure 添加时间戳标记,让 Cassandra 知道最后一次修复完成的时间.

阅读过程后我有一些问题:

  1. 在过程中完全修复后创建的新 SSTable 会发生什么情况?根据上一个链接中的步骤,我们永远不会为它们设置标记。

  2. 在测试集群中进行一些测试时,我们尝试在迁移之前从 SSTable 检索修复时间戳(使用 sstablemetadata 命令),它返回“Repaired at 0”,正如预期的那样,然后我们尝试运行直接增量修复(不进行迁移),我们能够验证“修复时间”值是否设置正确,并且一切似乎都工作正常。这是否意味着迁移过程是多余的?忽略它是否安全?

【问题讨论】:

    标签: cassandra datastax nosql


    【解决方案1】:

    在完全修复后创建的新 SSTable 会发生什么情况 程序?根据上一个链接中的步骤,我们永远不会 为他们设置标记。

    一旦您开始运行增量修复,它就会由那些正在运行的人设置。

    在测试集群中进行一些测试,我们尝试检索修复 迁移前来自 SSTable 的时间戳(使用 sstablemetadata 命令),它返回“在 0 处修复”,如预期的那样, 然后我们尝试直接运行增量修复(不执行 迁移)并且我们能够验证“修复时间”值是否具有 设置正确,一切似乎都运行良好。做这个 意味着迁移过程是多余的?忽略它是否安全?

    如果您没有大量数据,则可以跳过第一部分并开始运行增量修复。做第一步的原因是子范围修复和增量修复不是真正兼容的,当你有一个大数据集时,你通常需要进行子范围修复才能在正常的时间内完成而不消耗太多许多资源。由于增量修复不适用于子范围修复,如果您没有执行第一步来设置修复时间,那么第一次增量修复可能会使您的节点不堪重负。

    【讨论】:

      猜你喜欢
      • 2018-02-28
      • 2020-04-27
      • 1970-01-01
      • 2016-07-24
      • 2016-04-28
      • 2017-04-18
      • 1970-01-01
      • 1970-01-01
      • 2023-03-06
      相关资源
      最近更新 更多