Cassandra is configured to lose 10 seconds of data by default?

一曲冷凌霜 提交于 2019-12-05 08:59:48

If a node crashed right before updating the commit log on disk, then yes, you could lose up to ten seconds of data.

If you keep multiple replicas, by using a replication factor higher than 1 or have multiple data centers, then much of the lost data would be on other nodes, and would be recovered on the crashed node when it was repaired.

Also the commit log may be written in less than ten seconds it the write volume is high enough to hit size limits before the ten seconds.

If you want more durability than this (at the cost of higher latency), then you can change the commitlog_sync setting from periodic to batch. In batch mode it uses the commitlog_sync_batch_window_in_ms setting to control how often batches of writes are written to disk. In batch mode the writes are not acked until written to disk.

The ten second default for periodic mode is designed for spinning disks, since they are so slow there is a performance hit if you block acks waiting for commit log writes. For this reason if you use batch mode, they recommend a dedicated disk for the commit log so that the write head doesn't need to do any seeks to keep the added latency as low as possible.

If you are using SSD's, then you can use more aggressive timing since the latency is greatly reduced compared to a spinning disk.

http://wiki.apache.org/cassandra/Durability

"Cassandra's default configuration sets the commitlog_sync mode to periodic, causing the commitlog to be synced every commitlog_sync_period_in_ms milliseconds, so you can potentially lose up to that much data if all replicas crash within that window of time."

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!