Do you have a repro that you can share with us? If so, please file a jira and
we'll take a look.
> On Mar 18, 2022, at 12:15 PM, James Brown wrote:
>
> This in 4.0.3 after running nodetool snapshot that we're seeing sstables
> change, yes.
>
> James Brown
> Infrastructure Architect @
If that's the case, it sounds like a bug to me. A SSTable file in the
snapshot should never be modified by Cassandra, as that may interfere
with some tools backing up data from the snapshots.
On 18/03/2022 19:15, James Brown wrote:
This in 4.0.3 after running |nodetool snapshot| that we're
This in 4.0.3 after running nodetool snapshot that we're seeing sstables
change, yes.
James Brown
Infrastructure Architect @ easypost.com
On 2022-03-18 at 12:06:00, Jeff Jirsa wrote:
> This is nodetool snapshot yes? 3.11 or 4.0?
>
> In versions prior to 3.0, sstables would be written with
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
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
On 3/18/22 02:31, Stijn Vanden Brande (External) wrote:
The solution should be simply running `createrepo` after the new package
is added in archive repository to have the correct repo data.
You stated the issue in your initial observation. The contents of
archive.a.o are an automated
Yes, I can see. Looks like cluster got overcharged and full repair was
running, we got to restart all nodes and it seems to fix the problem. We
will upgrade version soon
Saludos
Jean Carlo
"The best way to predict the future is to invent it" Alan Kay
On Thu, Mar 17, 2022 at 5:12 PM Jeff Jirsa
Hi Bowen,
indeed, this is a work-around.
However, this disables the GPG check or other yum specific configuration
options.
While you do offer the yum repo data to have it function as a proper repository.
The solution should be simply running `createrepo` after the new package is
added in
