Cassandra数据恢复：意外删除与压缩物理删除后的访问及日志解析

嘿，针对你问到的Cassandra数据恢复相关的几个问题，我来给你逐一梳理清楚：

一、意外删除后的数据恢复 #

如果数据刚被删除，还没触发compaction的话，其实还有机会找回，步骤大概是这样：

• 首先立刻暂停自动compaction：赶紧跑nodetool disableautocompaction，不然Cassandra一执行compaction，标记为删除的数据就会被物理清理，到时候就难办了；
• 有快照的话直接用：如果你之前定期做过快照（比如用nodetool snapshot命令），把对应快照目录里的sstable文件复制到目标表的数据目录，然后执行nodetool refresh让节点重新加载这些文件就行；
• 没快照但没compaction的情况：可以用Cassandra自带的sstable2json工具，把未被清理的sstable文件转换成JSON格式，手动从中提取还没被删除的数据；
• 另外，commit log里可能还存着没刷写到sstable的操作，这个后面讲解析的时候会提到。

二、Compaction物理删除后的数据访问&类似Oracle Flashback的功能 #

先明确：一旦compaction完成，那些被标记删除的数据会被物理清除，旧的sstable文件也会被删掉，这时候正常渠道是没法再访问这些数据的。

至于类似Oracle Flashback的AS OF TIMESTAMP功能，Cassandra本身没有原生支持。不过可以通过一些方案来模拟：

• 定期拍快照：用定时任务自动执行nodetool snapshot，保留不同时间点的快照，需要回溯到某个时间点就用对应快照恢复；
• 开增量备份：在cassandra.yaml里把incremental_backups设为true，每次flush或compaction后会生成增量备份文件，结合快照能实现更细粒度的时间点恢复；
• 用时间窗口压缩策略（TWCS）：配合快照保留不同时间窗口的sstable，一定程度上能实现按时间范围找回数据，但操作起来比Oracle Flashback麻烦不少。

三、解析commit log为可读格式 #

commit log是二进制文件，直接打开当然看不懂，不过Cassandra自带了commitlog_reader工具，专门干这个事：

• 直接执行命令：commitlog_reader <你的commitlog文件路径>，比如commitlog_reader /var/lib/cassandra/commitlog/CommitLog-20240520-1200.log；
• 执行后会把日志里的所有操作（插入、更新、删除）都以人类能看懂的格式输出，你能从中找到已删除数据的相关记录；
• 要是想过滤特定操作，比如只看删除的，可以加管道：commitlog_reader <文件路径> | grep "DELETE"，也可以把结果导出到文本文件慢慢分析。

注意哦，commit log会被Cassandra自动清理，刷写到sstable之后就会删掉，所以要解析的话得抓紧，别等文件没了。

内容的提问来源于stack exchange，提问作者asliwinski