Reputation: 21245
I know Cassandra is smart enough to not serve any read requests when a new node is bootstrapped and joins a cluster until all the data has been replicated to the node.
Question is, does Cassandra behave the same for an existing datacenter rejoining a cluster? Specifcally for the following scenario:
If I have 2 DCs and DC1 is used for all reads/writes and DC2 is just for backup. If DC1 goes down and DC2 takes over for all the writes. When DDC1 comes back now, does Cassandra prevent DC1 from read requests until all data has been fully replicated.
Upvotes: 3
Views: 133
Reputation: 57748
Question is, does Cassandra behave the same for an existing datacenter rejoining a cluster?
If you follow the standard data center build procedure, where empty nodes are stood-up, and then streamed data through the nodetool rebuild
process, then the answer is "not necessarily." Rebuilding a node doesn't work the same as bootstrapping it, and thus, it may still try to serve requests.
Of course, the flip side of that coin, is that your application teams shouldn't deploy or activate any services which are defaulted or "sticky" to a new or "rejoining" data center, until you give them the ok. That's one reason why all client applications should specify a default data center, and use the NetworkTopologyStrategy for their keyspaces.
If I have 2 DCs and DC1 is used for all reads/writes and DC2 is just for backup. If DC1 goes down and DC2 takes over for all the writes. When DC1 comes back now, does Cassandra prevent DC1 from read requests until all data has been fully replicated?
In this scenario, the answer is "no" it does not prevent DC1 from serving requests. If an app is sticky to DC1, and it exists, it will serve requests regardless of whether or not its data is out of sync. If it were me, I would use Reaper to ensure repair has run on DC1, and tell my application teams to configure their apps/services to use only DC2 until otherwise indicated.
Upvotes: 2