【发布时间】：2019-04-08 14:06:57
【问题描述】：
我在 Cassandra 文档中注意到关于提交日志存档配置的以下声明： https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configLogArchive.html
"当客户端提供的第一个时间戳大于恢复点时间戳时恢复停止。因为数据库接收突变的顺序并不严格遵循时间戳顺序，这可能会导致一些突变无法恢复。 em>"
这个声明让我们担心使用基于 Cassandra 提交日志的时间点恢复，因为这表明如果我们有超出时间戳顺序的突变，时间点恢复将不会恢复时间戳低于指示的还原点时间戳的所有突变（我们将拥有）。
我尝试通过一些实验来验证此行为，但未能重现此行为。
我做了两个实验：
简单的行插入
将 restore_point_in_time 设置为提前 1 小时。 插入 10 行（使用默认的当前时间戳） 使用时间戳插入一行 插入 10 行（使用默认的当前时间戳）
现在我杀死了我的 cassandra 实例，确保它在没有机会刷新到 SS 表的情况下被终止。
在启动期间，我可以从 cassandra 日志中看到它正在执行 CommitLog 重播。
重播后，我按表查询，可以看到已经恢复了 20 行，但没有插入带有提前时间戳的行。虽然这里基于文档，但我预计只插入了前 10 行。我在 casssandra 日志中验证了 CommitLog 重播已经完成。
更大的 CommitLog 拆分实验
我想看看记录的功能是否正在处理提交日志拆分/翻转。
所以我将 commitlog_segment_size_in_mb 设置为 1 MB，以使 commitlog 更频繁地翻转，而不是默认的 32MB。 然后我运行了一个脚本来批量插入行以强制拆分提交日志。
所以这里的结果是我插入了 12000 条记录，然后插入了一条时间戳在我的 restore_point_in_time 之前的记录，然后我插入了 8000 条记录。
在大约 13200 行时，我的提交日志滚动到一个新文件。 然后我再次杀死了我的 cassandra 实例并重新启动。我再次可以在日志中看到 CommitLog 重播正在完成，重播后我可以看到除了时间戳早于 restore_point_in_time 的单行之外的所有行都已恢复。
注意事项
我使用 commitlog_sync 批处理选项进行了类似的实验，并且为了确保我的行没有被刷新到 SSTables，我尝试在启动 cassandra 之前使用空表恢复快照以使其执行 commitlog 重播。在所有情况下，我得到了相同的结果。
我想我的问题是文档中的声明是否仍然有效？或者我的实验中遗漏了什么？
任何帮助将不胜感激？我需要一个答案才能得出我们希望在更大规模的 cassandra 集群设置中实施的备份/恢复机制的结论。
在 Docker 容器（官方 cassandra docker 映像）中使用 Cassandra 3.11（单节点设置）完成的所有实验。我在“从头开始”的图像上进行了实验，因此除了我在此处的描述中包含的内容之外，没有对配置进行任何更改。
【问题讨论】：
标签： database cassandra cassandra-3.0