Re: 4.0 upgrade

You should not make DDL (e.g. TRUNCATE, ALTER TABLE) or DCL (e.g. GRANT, ALTER ROLE) operations or run repair on a mixed version cluster. Source: https://www.datastax.com/learn/whats-new-for-cassandra-4/migrating-cassandra-4x You should also ensure the gc_grace_seconds value is large enough to

Re: 4.0 upgrade

Yes repairs are prohibited in mixed version cluster. If you want to monitor please disable repairs till complete upgrade is finished On Sat, Jul 8, 2023, 01:21 Runtian Liu wrote: > Hi, > > We are upgrading our Cassandra clusters from 3.0.27 to 4.0.6 and we > observed some error related to

4.0 upgrade

Hi, We are upgrading our Cassandra clusters from 3.0.27 to 4.0.6 and we observed some error related to repair: j.l.IllegalArgumentException: Unknown verb id 32 We have two datacenters for each Cassandra cluster and when we are doing an upgrade, we want to upgrade 1 datacenter first and monitor

Re: Cassandra 4.0 upgrade - Upgradesstables

Though it is not required to run upgradesstables, but upgradesstables -a will re-write the file to kick out tombstones, in sizeTieredcompaction, the largest files may stay a long time to wait for the next compaction to kick out tombstones. So it really depends, to run it or not, usually upgrades

Re: Cassandra 4.0 upgrade - Upgradesstables

Thank you On Tue, Aug 16, 2022 at 11:48 AM C. Scott Andreas wrote: > No downside at all for 3.x -> 4.x (however, Cassandra 3.x reading 2.1 > SSTables incurred a performance hit). > > Many users of Cassandra don't run upgradesstables after 3.x -> 4.x > upgrades at all. It's not necessary to run

Re: Cassandra 4.0 upgrade - Upgradesstables

No downside at all for 3.x -> 4.x (however, Cassandra 3.x reading 2.1 SSTables incurred a performance hit).Many users of Cassandra don't run upgradesstables after 3.x -> 4.x upgrades at all. It's not necessary to run until a hypothetical future time if/when support for reading Cassandra 3.x

Re: Cassandra 4.0 upgrade - Upgradesstables

Thank you Erick, > it is going to be single-threaded by default so it will take a while to get through all the sstables on dense nodes Is there any downside if the upgradesstables take longer (example 1-2 days), other than I/O? Also when is the upgradesstable get triggered? after every node is

Re: Cassandra 4.0 upgrade - Upgradesstables

As convenient as it is, there are a few caveats and it isn't a silver bullet. The automatic feature will only kick in if there are no other compactions scheduled. Also, it is going to be single-threaded by default so it will take a while to get through all the sstables on dense nodes. In

Cassandra 4.0 upgrade - Upgradesstables

Hello, I am evaluating the upgrade from 3.11.x to 4.0.x and as per CASSANDRA-14197 we don't need to run upgradesstables any more. We have tested this in a test environment and see that setting "-Dcassandra.automatic_sstable_upgrade=true"

Re: Cassandra 4.0 upgrade from Cassandra 3x

You can see upgrading instructions here https://github.com/apache/cassandra/blob/cassandra-4.0.2/NEWS.txt. On Fri, Feb 11, 2022 at 2:52 AM Abdul Patel wrote: > Hi > apart from standard upgrade process any thing specific needs ti be > handled separately for this upgrade process? > > Any changes

Re: Cassandra 4.0 upgrade from Cassandra 3x

Make sure you go through all the instructions in https://github.com/apache/cassandra/blob/trunk/NEWS.txt. It's also highly recommended that you upgrade to the latest 3.0.x or 3.11.x version before upgrading to 4.0. Generally there are no changes required on the client side apart from setting the

Cassandra 4.0 upgrade from Cassandra 3x

Hi apart from standard upgrade process any thing specific needs ti be handled separately for this upgrade process? Any changes needed at client side w.r.t drivers?