Jeff, Shouldn't Snapshot get consistent state of sstables? -tmp file shouldn't impact backup operation right?
Regards, Nitan K. Cassandra and Oracle Architect/SME Datastax Certified Cassandra expert Oracle 10g Certified On Wed, May 23, 2018 at 6:26 PM, Jeff Jirsa <jji...@gmail.com> wrote: > In versions before 3.0, sstables were written with a -tmp filename and > copied/moved to the final filename when complete. This changes in 3.0 - we > write into the file with the final name, and have a journal/log to let uss > know when it's done/final/live. > > Therefore, you can no longer just watch for a -Data.db file to be created > and uploaded - you have to watch the log to make sure it's not being > written. > > > On Wed, May 23, 2018 at 2:18 PM, Max C. <mc_cassan...@core43.com> wrote: > >> Hi Everyone, >> >> We’ve noticed a few times in the last few weeks that when we’re doing >> backups, tar has complained with messages like this: >> >> tar: /var/lib/cassandra/data/mars/test_instances_by_test_id-6a944 >> 0a04cc111e8878675f1041d7e1c/snapshots/backup_20180523_024502/mb-63-big-Data.db: >> file changed as we read it >> >> Any idea what might be causing this? >> >> We’re running Cassandra 3.0.8 on RHEL 7. Here’s rough pseudocode of our >> backup process: >> >> <cronjob set to fire same script at same time on all nodes> >> SNAPSHOT_NAME=backup_YYYMMDD_HHMMSS >> nodetool snapshot -t $SNAPSHOT_NAME >> >> for each keyspace >> - dump schema to “schema.cql" >> - tar -czf /file_server/backup_$HOSTNAME_$KEYSPACE_YYYYMMDD_HHMMSS.tgz >> schema.cql /var/lib/cassandra/data/$KEYSPACE/*/snapshots/$SNAPSHOT_NAME >> >> nodetool clearsnapshot -t $SNAPSHOT_NAME >> >> Thanks. >> >> - Max >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: user-h...@cassandra.apache.org >> >> >
