[
https://issues.apache.org/jira/browse/CASSANDRA-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16118:
----------------------------------------
Labels: ec2 k8 kubernetes startup (was: )
> Verify Correct Ownership of Attached Locations on Disk at Startup
> -----------------------------------------------------------------
>
> Key: CASSANDRA-16118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16118
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
> Reporter: Caleb Rackliffe
> Priority: Normal
> Labels: ec2, k8, kubernetes, startup
>
> There are two problematic scenarios around disk ownership we'll try to
> address here:
> 1.) A node comes up with an incorrectly mounted volume attached as its
> configured data directory. This causes the wrong system tables to be read.
> 2.) In a JBOD setup, the non-system keyspaces may reside on a volume separate
> from the system tables. In this scenario, we want to ensure that all
> directories belong to the same node, and that as the node starts up it can
> access all the directories it expects to be able to (including data, commit
> log, hints, and saved caches).
> One solution to this is to touch an empty file in each relevant directory
> with a token that maps to the node to which it belongs. This would be done as
> part of the provisioning process during cluster creation or host replacement.
> A {{StartupCheck}} could then be added to verify that the correct identifying
> file is present in each directory, halting startup if not. It should, of
> course, be possible to disable this check (and it being disabled should
> likely be the initial default).
> It's likely this will be most useful on EC2 or in k8s environments where
> these particular misconfigurations are likely to manifest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
