Hi Jeff
By “dropping” the periodic time, do you mean making it 0 or commenting commit
log or changing commit log to batch? Referring to the comments in
Cassandra.yaml, if I use commitlog_sync as batch with 2ms window, does it mean
that when a write is done on the db, then it is immediately
The commitlog defaults to periodic mode, which writes a sync marker to the
file and fsync's the data to disk every 10s by default.
`nodetool flush` will force a sync marker / fsync
Data written since the last fsync will not be replayed on startup and will
be lost.
If you drop the periodic time,
>
> I do "nodetool flush", then snapshot the storage. Meanwhile, the DB is
> under heavy read/write traffic, with lots of writes per second. What's
> the worst that could happen, lose a few writes?
>
Nope, you won't lose anything. Snapshots in C* are the equivalent of a cold
backup in relational
That sounds great! Now here's my question:
I do "nodetool flush", then snapshot the storage. Meanwhile, the DB is
under heavy read/write traffic, with lots of writes per second. What's
the worst that could happen, lose a few writes?
On 2020-11-10 15:59, Jeff Jirsa wrote:
If you want all of
If you want all of the instances to be consistent with each other, this is
much harder, but if you only want a container that can stop and resume, you
don't have to do anything more than flush + snapshot the storage. The data
files on cassandra should ALWAYS be in a state where the database will
