This is nodetool snapshot yes? 3.11 or 4.0? In versions prior to 3.0, sstables would be written with -tmp- in the name, then renamed when complete, so an sstable definitely never changed once it had the final file name. With the new transaction log mechanism, we use one name and a transaction log to note what's in flight and what's not, so if the snapshot system is including sstables being written (from flush, from compaction, or from streaming), those aren't final and should be skipped.
On Fri, Mar 18, 2022 at 11:46 AM James Brown <jbr...@easypost.com> wrote: > We use the boring combo of cassandra snapshots + tar to backup our > cassandra nodes; every once in a while, we'll notice tar failing with the > following: > > tar: > data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db: > file changed as we read it > > I find this a bit perplexing; what would cause an sstable inside a > snapshot to change? The only thing I can think of is an incremental repair > changing the "repaired_at" flag on the sstable, but it seems like that > should "un-share" the hardlinked sstable rather than running the risk of > mutating a snapshot. > > > James Brown > Cassandra admin @ easypost.com >
