2020 00:24
To: cassandra<mailto:user@cassandra.apache.org>
Subject: Re: Cassandra in a container - what to do (sequence of events) to
snapshot the storage volume?
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.
`
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 D
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
re