Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "Durability" page has been changed by JonathanEllis. http://wiki.apache.org/cassandra/Durability?action=diff&rev1=2&rev2=3 -------------------------------------------------- Like most modern systems, Cassandra provides durability by appending writes to a commitlog first. This means that only the commitlog needs to be fsync'd, which, if the commitlog is on its own volume, obviates the need for seeking since the commitlog is append-only. Implementation details are in ArchitectureCommitLog. - Commitlog behavior is configurable with the CommitLogSync, CommitLogSyncPeriodInMS, and CommitLogSyncBatchWindowInMS. See the sample storage configuration for details on using these. (CommitLogSyncPeriodInMS and CommitLogSyncBatchWindowInMS correspond to the [[http://www.postgresql.org/docs/8.4/static/runtime-config-wal.html|PostgreSQL settings]] of wal_writer_delay and commit_delay, respectively; however, unlike PostgreSQL, Cassandra does not allow turning fsync off completely.) + Cassandra's example configuration shows !CommitLogSync set to periodic, meaning that we sync the commitlog every CommitLogSyncPeriodInMS ms, so you can potentially lose up to that much data in a crash. This is decently performant even with the commitlog shared with data directories. You can also select "batch" mode, where Cassandra will guarantee that it syncs before acknowledging writes, i.e., fully durable mode, in batches of CommitLogSyncBatchWindowInMS. To use this mode we strongly recommend splitting your commitlog onto a separate device, as described above. + Users familiar with PostgreSQL may wish to note that CommitLogSyncPeriodInMS and CommitLogSyncBatchWindowInMS correspond to the [[http://www.postgresql.org/docs/8.4/static/runtime-config-wal.html|PostgreSQL settings]] of wal_writer_delay and commit_delay, respectively. +
