[
https://issues.apache.org/jira/browse/CASSANDRA-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15749318#comment-15749318
]
Nachiket Patil commented on CASSANDRA-13041:
--------------------------------------------
On trunk, I see "system" and "system_schema" are immutable. But I don't see
anywhere that "system_auth" being disallowed from dropping. I ran simple test
which passes:
{code}
@Test
public void testTryDroppingSystemAuthKeyspace() throws Throwable
{
// create the system_auth keyspace locally.
MigrationManager.announceNewKeyspace(AuthKeyspace.metadata(), 0, true);
execute("DROP KEYSPACE " + SchemaConstants.AUTH_KEYSPACE_NAME);
}
{code}
This aside, do you agree with not allowing to drop a DC from system_auth
replication configuration when the DC has active instances?
Best practice is remove all instances from the DC before dropping the DC from
replication configuration. This change will force it.
> Do not allow removal of a DC from system_auth replication settings if the DC
> has active Cassandra instances
> -----------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-13041
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13041
> Project: Cassandra
> Issue Type: Improvement
> Components: Distributed Metadata
> Reporter: Nachiket Patil
> Assignee: Nachiket Patil
> Priority: Minor
> Fix For: 4.x
>
>
> I don’t believe it is ever correct to remove a DC from the system_auth
> replication settings while there are nodes up in that DC. Cassandra should
> not allow this change if there are hosts which are currently members of the
> cluster in that DC, as any request which is routed to these hosts will meet
> an unavailable. Also dropping the keyspace system_auth should not be allowed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
