如果一个节点在更新磁盘上的提交日志之前崩溃，那么是的，您可能会丢失多达10秒钟的数据。
如果您通过使用大于1的复制因子或拥有多个数据中心来保留多个副本，那么大部分丢失的数据将位于其他节点上，并且在修复时将在崩溃的节点上恢复。
此外，如果写入卷足够高，可以在10秒内达到大小限制，则提交日志可能会在10秒内写入。
如果您想要更高的耐久性（以更高的延迟为代价），那么可以将commitlog_sync设置从e1d1e更改为batch。在batch模式下，它使用commitlog_sync_batch_window_in_ms设置来控制将批写入写入磁盘的频率。在批处理模式下，写入操作在写入磁盘之前不会被确认。
周期模式的10秒默认值是为旋转磁盘而设计的，因为它们太慢了，如果阻塞ack等待提交日志写入，就会影响性能。出于这个原因，如果您使用batch模式，他们建议为提交日志使用一个专用磁盘，这样写头就不需要进行任何查找，以尽可能降低增加的延迟。
如果您使用的是SSD，那么您可以使用更积极的计时，因为与旋转磁盘相比，延迟大大减少。

Cassandra的默认配置将commitlog_sync模式设置为周期性，导致提交日志每commitlog_sync_period_in_ms毫秒同步一次，因此如果所有副本在该时间窗口内崩溃，则可能会丢失多达那么多的数据。