Ariel Weisberg created CASSANDRA-21010:
------------------------------------------
Summary: Witness enable/disable implementation, testing,
documentation
Key: CASSANDRA-21010
URL: https://issues.apache.org/jira/browse/CASSANDRA-21010
Project: Apache Cassandra
Issue Type: Sub-task
Reporter: Ariel Weisberg
The original process for enabling/disabling witnesses was that enabling them
entailed changing the schema and then running nodetool cleanup. I believe this
is still the case.
The original process for disabling witnesses is reduce the number of witnesses
to 0 and then increase the number of full replicas. With say 6 replicas total
and only 4 full replicas this means f will be 1 in terms of availability. In
terms of write durability since quorum will be 3/4 you can still lose 2 nodes
without losing any writes. This may be undesirable, but fine. If you ran RF=5
(or had only 3 full replicas) write durability would only allow for 1 lost
replica which is more problematic. You would also immediately lose availability
with only 3 full replicas and 3 witnesses when you attempted to disable the
witnesses.
The code that documents this is in `AlterKeyspaceStatement`:
```
//This is true right now because the transition from transient -> full
lacks the pending state
//necessary for correctness. What would happen if we allowed this is
that we would attempt
//to read from a transient replica as if it were a full replica.
if (oldFull > newFull && oldTrans > 0)
throw new ConfigurationException("Can't add full replicas if there
are any transient replicas. You must first remove all transient replicas, then
change the # of full replicas, then add back the transient replicas");
```
It would be more optimal to have a pending state for witnesses and then add
them back to the read data placement when repair completes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]