我注意到在cassandra文档中关于提交日志归档配置的以下语句：https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configlogarchive.html
“当第一个客户端提供的时间戳大于还原点时间戳时，还原停止。因为数据库接收突变的顺序并不严格遵循时间戳顺序，这可能会导致某些突变无法恢复。”
这句话让我们担心如何使用基于cassandra提交日志的时间点恢复，因为这表明，如果我们有时间戳顺序不符的突变（我们将有），时间点恢复将不会恢复时间戳低于指定恢复点时间戳的所有突变。
我试图通过一些实验来验证这种行为，但一直未能重现这种行为。
我做了两个实验：

简单行插入

将恢复时间点设置为提前1小时。插入10行（使用默认的当前时间戳）插入一行（使用时间戳）<提前2小时>插入10行（使用默认的当前时间戳）
现在我杀死了我的cassandra示例，确保它在没有机会刷新到ss表的情况下被终止。
在启动过程中，我可以从cassandra日志中看到它正在进行commitlog重放。
重放之后，我按表查询，可以看到20行已经恢复，但是没有插入时间戳提前的那一行。尽管这里基于文档，我本以为只插入了前10行。我在casssandra日志中验证了commitlog重播已经完成。

大委员会分裂实验

我想看看文档化的特性是否在commitlog拆分/滚动上工作。
因此，我将commitlog\u segment\u size\u in\u mb设置为1 mb，以使commitlog更频繁地滚动，而不是32mb的默认值。然后我运行了一个脚本来批量插入行，以强制拆分提交日志。
所以这里的结果是我插入了12000条记录，然后在我的恢复点之前插入了一条带有时间戳的记录，然后在之后插入了8000条记录。
在大约13200行时，我的commitlog转到了一个新文件。然后我再次杀死我的cassandra示例并重新启动。在日志中，我可以再次看到commitlog重放正在进行，重放之后，我可以看到除时间戳在restore\u point\u in\u time之前的单行之外的所有行都已恢复。

注意事项

我使用commitlog\u sync batch选项做了类似的实验，并且为了确保我的行没有被刷新到sstables，我尝试用空表还原快照，然后启动cassandra使其执行commitlog replay。在所有情况下，我都得到了相同的结果。
我想我的问题是文件中的陈述是否仍然有效？或者我在实验中遗漏了什么？
如有任何帮助，我们将不胜感激？我需要一个答案，以便能够总结出我们希望在更大规模的cassandra集群设置中实现的备份/恢复机制。
在docker容器（cassandra docker官方图片）中使用cassandra 3.11（单节点设置）完成的所有实验。我在“从头开始”的图像上运行了这些实验，因此除了我在这里的描述中包含的内容外，在配置中没有其他更改。