环境详细信息：
- GKE（谷歌 Kubernetes 集群）
- 告密者谷歌云告密者。 https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/architecture/archSnitchGoogle.html
- 140 个节点，具有 4 个 RACK（一个区域的 4 个可用区中的 4 个状态集）
- 每个节点大小为 5TB，集群大小为 700TB。
恢复数据库的过程如下： 我通过复制 sstables 使用 Nodetool 刷新将 K8s cassandra 中大小为 450TB 的数据库从源恢复到目标。每个节点大约有 5 到 6 TB 数据。我采取的方法：
- 构建一个具有与源 140 个节点相同数量的节点的新集群。
- 从源磁盘快照（云）创建新磁盘并将这些磁盘附加到新节点。
- 清除系统表。
- 启动 C* 作为目标集群。
- 手动创建与源集群匹配的表
- 将旧表复制到新创建的（UUID）表。7 Ran节点工具刷新
观察： Nodetool 状态显示每个节点的大小与源相同，cfstats 也与目标和源上的表大小匹配。
迁移后问题：
为了减少集群大小，我开始停用其中一个节点，并在 10 分钟内完成。根据之前的源集群维护情况，预计至少需要 8 小时。
由于预计退役不会仅运行 10 分钟，因此我尝试向集群添加一个新节点，该节点假设复制大约 5-6 TB 的数据，但它只复制了 2 TB。
作为另一项检查，我刚刚在目标集群的另一个节点上尝试了“Nodetool cleanup”，它将数据从 6 TB 减少到 2 TB。相同的清理不会减少源节点上的任何数据。
恢复后，使用收割器工具在目标上修复整个集群，修复没有问题，但退役、清理和引导才是问题。
我怀疑根本问题是你的程序不正确。为了使“刷新方法”起作用，源节点和相应的目标节点必须具有相同的配置，直至分配给它们的令牌，正如我在如何将 Cassandra 快照恢复到另一个节点中所解释的那样具有相同配置的集群？。
当您将 SSTable 复制到与源节点具有不同令牌所有权的节点时，这些 SSTable 中不属于目标节点的分区将在您运行时被丢弃
nodetool cleanup。由于节点部署在 Kubernetes 集群中，我假设您无法控制令牌分配，这意味着 Pod 将被分配随机令牌。
当源集群和目标集群配置不一致的情况下，无法使用刷新方法。正确的过程是使用 加载数据
sstableloader。如果您感兴趣，我已在如何将表中的数据迁移到新的 Cassandra 集群？中记录了详细步骤。。干杯!