this could be improved since there might be requirements
from other users that cannot be covered with the proposed procedure.
BR
MK
From: Alain Rodriguez
Sent: April 22, 2024 18:27
To: user@cassandra.apache.org
Cc: Michalis Kotsiouros (EXT)
Subject: Re: Datacenter decommissioning on Cassandra 4.1.4
default consistency level for
authentication/authorization to LOCAL_ONE as it used in previous C*
versions.
BR
MK
-Original Message-
From: Sebastian Marsching
Sent: April 22, 2024 21:58
To: Michalis Kotsiouros (EXT) via user
Subject: Re: Datacenter decommissioning on Cassandra 4.1.4
Recently, I successfully used the following procedure when decommissioning a
datacenter:
1. Reduced the replication factor for this DC to zero for all keyspaces except
the system_auth keyspace. For that keyspace, I reduced the RF to one.
2. Decommissioned all nodes except one in the DC using th
very node in
>the datacenter being removed.
>5. Change system_auth keyspace so they no longer reference the
>datacenter being removed.
>
> BR
>
> MK
>
>
>
>
>
>
>
> *From:* Jeff Jirsa
> *Sent:* April 08, 2024 17:19
> *To:* cassandra
>
system_auth keyspace so they no longer reference the datacenter
being removed.
BR
MK
From: Jeff Jirsa
Sent: April 08, 2024 17:19
To: cassandra
Cc: Michalis Kotsiouros (EXT)
Subject: Re: Datacenter decommissioning on Cassandra 4.1.4
To Jon’s point, if you remove from replication after step 1 or
To Jon’s point, if you remove from replication after step 1 or step 2 (probably
step 2 if your goal is to be strictly correct), the nodetool decommission phase
becomes almost a no-op.
If you use the order below, the last nodes to decommission will cause those
surviving machines to run out of s
You shouldn’t decom an entire DC before removing it from replication.
—
Jon Haddad
Rustyrazorblade Consulting
rustyrazorblade.com
On Mon, Apr 8, 2024 at 6:26 AM Michalis Kotsiouros (EXT) via user <
user@cassandra.apache.org> wrote:
> Hello community,
>
> In our deployments, we usually rebuild
