我已经在Cassandra文档中注意到有关提交日志归档文件配置的以下声明： https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configLogArchive.html
“ 当第一个客户端提供的时间戳大于还原点时间戳时，还原将停止。由于数据库接收突变的顺序并不严格遵循时间戳顺序，因此这可能会使某些变异无法恢复。
” em>“此语句使我们担心基于Cassandra提交日志使用时间点恢复，因为这表明如果我们的时间戳顺序不正确，则时间点恢复将无法恢复所有时间戳低于指示的恢复点时间戳的突变。 （我们将拥有）。
我试图通过一些实验来验证这种行为，但是无法重现这种行为。
我做了2个实验：
将restore_point_in_time设置为提前1小时。 插入10行（使用默认的当前时间戳记） 使用时间戳<提前2小时>插入一行 插入10行（使用默认的当前时间戳记）
现在，我杀死了我的cassandra实例，以确保它已终止而没有机会刷新到SS表。
在启动期间，我可以从cassandra日志中看到它正在执行CommitLog重播。
重播后，我按表查询，可以看到已恢复20行，但未插入带有时间戳的行。尽管这里基于文档，但我希望只插入前10行。我在卡桑德拉日志中验证了CommitLog重播已完成。
我想看看该文档功能是否正在通过提交日志拆分/翻转工作。
因此，我将commitlog_segment_size_in_mb设置为1 MB，以使提交日志更频繁地翻转，而不是默认的32MB。 然后，我运行一个脚本来批量插入行，以强制拆分提交日志。
因此，结果是我插入了12000条记录，然后在restore_point_in_time之前插入了带有时间戳的记录，然后又插入了8000条记录。
在大约13200行中，我的提交日志已滚动到一个新文件。 然后，我再次杀死了我的cassandra实例并重新启动。再次，我在日志中看到CommitLog重播已完成，重播后，我看到除了时间戳在restore_point_in_time之前的单行以外的所有行都已恢复。
我使用commitlog_sync批处理选项进行了类似的实验，并且还确保没有将行刷新到SSTables，因此我尝试在启动cassandra之前使用空表恢复快照，以使其执行commitlog重播。在所有情况下，我都得到相同的结果。
我想我的问题是文档中的声明是否仍然有效？还是我的实验中缺少什么？
任何帮助将不胜感激？我需要一个答案，以便能够总结出我们希望在更大规模的cassandra群集设置中实现的备份/恢复机制。
所有实验都是在Docker容器中使用Cassandra 3.11（单节点设置）完成的（官方cassandra docker映像）。我在“从头开始”图像上进行了实验，因此除了我在此处的描述中所包含的内容之外，没有对配置进行任何更改。
答案 0 :(得分：0)
我认为复制起来会比较困难，因为您需要确保某些突变比其他突变来得晚，而这可能主要发生在某些客户端未同步时钟或节点过载的情况下，然后一段时间后重播提示，等等。
但是根本不需要此参数-如果您查看CommitLogArchiver.java，则可以看到，如果未指定此参数，则将其设置为Long.MAX，这意味着存在没有上限，所有提交日志都将被重播，然后Cassandra将以标准方式进行处理：“最新时间戳获胜”。