在 66 节点集群上删除具有 55TB 数据的密钥空间的建议过程是什么？

What is the suggested procedure for dropping a keyspace with 55TB of data on 66-node cluster?

有一个keyspace占用了55tb的space，cluster里面有66个节点(dse 5.1.6, cassandra 3.11) keyspace 有 3 个表，自上个月以来表上没有 reads/writes。

想要删除 keyspace/tables 以回收 space 而不会在集群中造成任何问题？

  1. 在此集群上删除表和键space时 - 什么可能导致问题？未使用密钥的大小space (55tb) 或集群中模式更改（删除 tables/keyspace）的节点数 (66) 是否需要传播？
  2. 除了先删除表再删除键space，还有其他安全删除键space的方法吗？例如，从节点中删除 sstables 会使删除更快更平滑吗？删除 sstables 会触发 repairs/compactions 并导致任何问题吗？
  3. 有什么方法可以在会话级别或从特定表或键的驱动程序级别禁用 auto_snapshotspace？
  4. 有什么考虑 before/after 放弃 tables/keyspace 吗？这是我要遵循的步骤 - 一种。节点工具描述集群 b.使用 cqlsh 删除表（request-timeout=600） C。使用 cqlsh 删除密钥space（请求超时=600） d. nodetool describecluster，检查是否有任何不一致 e.从每个节点删除键的数据目录space（数据已经备份在某处，不需要自动快照）

我能预见到您 运行 遇到的唯一真正问题是模式分歧。由于 (a) 数据大小和 (b) 节点数量，我的方法是：

  1. 尝试一次 TRUNCATE 1 table
  2. 如果 TRUNCATE 超时，请重试
  3. 当 table 被 t运行 时，DROP 它
  4. 至少等待 1 分钟以传播架构
  5. 检查模式不一致并适当修复
  6. 重复上述步骤，直到所有 table 都被丢弃
  7. DROP键空间
  8. 根据需要从文件系统中手动删除快照

直接回答您的问题：

  1. 您可以 运行 进入超时和模式分歧。是的，它是 (a) 数据大小和 (b) 节点数的组合。
  2. 我建议 t运行 像上面那样先安装 table。这不会导致架构不一致，因为它不会更改架构。通过 t运行cating 首先，它将允许 DROP 正常工作。
  3. 不，您只能在 cassandra.yaml 中禁用 auto_snapshot，这需要滚动重启。您不想这样做，因为没有必要重新启动所有 66 个节点。
  4. 上面的过程我已经贴出来了