Consistency Level Considered Connectivity Checker

The connectivity checker runs during the startup of Cassandra, more specifically right after CassandraDaemon#setup. In general, it blocks for a certain period of time in order to establish connections with the peers in the cluster. The blocking is a best-effort one, meaning that the checker allows Cassandra to continue booting even if the criteria is not met.

The Consistency Level Considered Connectivity Checker prioritizes the peers to connect, while still satisfying the desired Consistency Level. The goal of the new connectivity checker is to solve the read unavailable/timeout.

The Consistency Level Considered Connectivity Checker (CL checker) uses the consistency level specified by the block_for_peers_consistency_level property to determine the number of peers to wait for in the local or remote datacenter before offering itself as a coordinator. Subject to the timeout specified by block_for_peers_timeout_in_secs.

The supported values for the CL checker are ALL, QUORUM, LOCAL_QUORUM, and EACH_QUORUM. The value is specified in the block_for_peers_consistency_level property defined in cassandra.yaml. The default consistency level is LOCAL_QUORUM.

During the connectivity checker execution, peers are categorized into primary and secondary peers, such that primary peers are the sufficient number of peers required to satisfy the consistency level specified in block_for_peers_consistency_level. If the connection fails to any of the primary peers, additional connections are performed to secondary peers, and after the block_for_peers_timeout_in_secs timeout, validation is performed to make sure the CL is satisfied for all the natural replicas for every node.

The CL checker does not support vnodes.