我们可以添加一个新的 Cassandra 3.11 DC，将其升级到 4.0，然后最终摆脱旧的 DC 吗？
Can we add a new Cassandra 3.11 DC, upgrade it to 4.0, then eventually get rid of the old DC?
我们想使用多 DC 复制从 cassandra 3.11.12 升级到 cassandra 4.0.2。
我们希望这样做是为了轻松快速地回滚（避免 backup\snap 和恢复的情况）。
Steps we think to do:
1. lock app to use (read & writes) only with old\current dc (using driver options).
3. create new dc with same version (3.11.12) - new dc will created with 16 num_tokens (today we are with 3.11 default 256 and want to move to 16).
3. sync all data\keyspaces to new dc - and keep the sync active to the 2 DC's.
4. upgrade the new dc from 3.11.12 to 4.0.2
5. after step 4 done, move app to use only new DC (version 4 after upgrade)
6. wait few days to see all going well
7. stop replication to old dc
8. remove old dc nodes until and stay only with the new DC (cassandra 4.0.2)
一个。主要问题是这个过程应该有效吗？
B、这样移动到16num_tokens有问题吗？
C. 当两个 DC 处于不同版本的 Cassandra（dc1 在 3.11.12 中，dc2 在 4.0.2 中）时，是否可以在 2 个 DC 之间保持同步 data\keyspaces 几天？
注意 我发现不建议使用混合了 cassandra 版本的集群，但这仅适用于具有快速简单回滚的升级过程。几天后，当新版本似乎一切正常时，带有旧 cassandra 版本的旧 DC 将被删除。
这是一个有效的升级路径，但请记住，您提出的方法可能存在一些缺点。例如，如果一个节点出现故障（比如硬件故障），那么您将无法将其停用。
任何需要流式处理的操作都无法在 mixed-version 集群中运行。这些操作包括 bootstrap、退役、维修。
直接回答您的问题：
- 一个。是的，它会起作用，但有一些问题。
- 乙。不，添加新 DC 是您更改令牌数量的唯一方法。
- C。是的，复制旨在在 mixed-version 秒内完成。
回答你没有问的问题：根据我的经验，回滚升级实际上是非常罕见的。您通常会一次升级一个节点。如果您 运行 遇到节点上的问题，您将修复该节点，然后继续滚动升级，直到集群中的所有节点都已升级。
在滚动升级期间，您的应用程序应该继续工作，因此没有理由执行回滚。干杯！
我们想使用多 DC 复制从 cassandra 3.11.12 升级到 cassandra 4.0.2。 我们希望这样做是为了轻松快速地回滚（避免 backup\snap 和恢复的情况）。
Steps we think to do:
1. lock app to use (read & writes) only with old\current dc (using driver options).
3. create new dc with same version (3.11.12) - new dc will created with 16 num_tokens (today we are with 3.11 default 256 and want to move to 16).
3. sync all data\keyspaces to new dc - and keep the sync active to the 2 DC's.
4. upgrade the new dc from 3.11.12 to 4.0.2
5. after step 4 done, move app to use only new DC (version 4 after upgrade)
6. wait few days to see all going well
7. stop replication to old dc
8. remove old dc nodes until and stay only with the new DC (cassandra 4.0.2)
一个。主要问题是这个过程应该有效吗？
B、这样移动到16num_tokens有问题吗？
C. 当两个 DC 处于不同版本的 Cassandra（dc1 在 3.11.12 中，dc2 在 4.0.2 中）时，是否可以在 2 个 DC 之间保持同步 data\keyspaces 几天？
注意 我发现不建议使用混合了 cassandra 版本的集群，但这仅适用于具有快速简单回滚的升级过程。几天后，当新版本似乎一切正常时，带有旧 cassandra 版本的旧 DC 将被删除。
这是一个有效的升级路径，但请记住，您提出的方法可能存在一些缺点。例如，如果一个节点出现故障（比如硬件故障），那么您将无法将其停用。
任何需要流式处理的操作都无法在 mixed-version 集群中运行。这些操作包括 bootstrap、退役、维修。
直接回答您的问题：
- 一个。是的，它会起作用，但有一些问题。
- 乙。不，添加新 DC 是您更改令牌数量的唯一方法。
- C。是的，复制旨在在 mixed-version 秒内完成。
回答你没有问的问题：根据我的经验，回滚升级实际上是非常罕见的。您通常会一次升级一个节点。如果您 运行 遇到节点上的问题，您将修复该节点，然后继续滚动升级，直到集群中的所有节点都已升级。
在滚动升级期间，您的应用程序应该继续工作，因此没有理由执行回滚。干杯！