Question-: You are planning to decommission a node from the Cassandra cluster, which of the following is correct in this case? A. Token ranges would be assigned to remaining node after the decommissioning of the node B. All the data would be copied from the decommissioned nodes to other nodes. C. All the data would be copied from the other replicas in the cluster. D. Data would be automatically cleaned from the decommissioned node and you bring it back in service if required.
Answer: A, B Exp: This question is asked in the context of the approaches of removing a particular node from the cluster. Suppose you are removing a node from the cluster. Then there are two approaches you can follow. 1. Nodetool decommission 2. Nodetool removenode In case of decommission or removing nodes - Existing token range would be handled by the other nodes in the Cassandra cluster. And data should be replicated properly. Now in both the case copying data would have different approaches 1. If you are using decommission approach then in this case data would be copied from the decommissioned node. 2. If you are using removenode command then data would be copied from the existing nodes in the cluster. And also remember than when you decommission a node from the Cassandra cluster then data would not be automatically cleaned. If you want reuse the same node in Cassandra cluster then you have to first clean the data your own. And you can put it back with the different token range.
Question-: You want to replace the existing node in the cluster with the new node. Hence, you add the new node as well as keep the older node in the cluster. Once data is fully copied on the new node, you would be removing the one node, which is not needed anymore. A. True B. False
Answer: B Exp: In Cassandra to replace a node, you need to follow the certain steps. Just adding new node and removing a node from the cluster would not work. How tokens would be taken care also matters. Hence, to replace a node in Cassandra cluster, you just mark the JVM startup falg -Dcassandra.replace_address_first_boot= . Once this property is enabled then node would start in hibernate state, during which all the other nodes will see this node to be in DOWN(DN), however this node will see itself as UP(UN). Now you can start the replacing node (new node) and it will bootstrap the data from the rest of the nodes in the cluster. A replacing node will only receive writes during the bootstrapping phase, if it has a different ip address to the node that is being replaced. Once the bootstrapping completes the node will be marked as “UP�.
Question-: Please map the below A. Repair Process B. Incremental Repair C. Full Repair D. Operate/repair all the token ranges replicated by the node on which repair started
1. Synchronizes the data between nodes by comparing their respective datasets for their common token ranges. 2. Repair the data that’s been written since last repair. 3. Access Mostly Uused Products by 50000+ Subscribers 4. nodetool repair
Answer: A-1,B-2,C-3, D-4
Explanation: Repair process in Cassandra synchronizes the data between the nodes by comparing their respective datasets for the common token ranges. And stream any differences for out of sync data between the nodes. There are two types of repairs which you can run. 1. Incremental 2. Full For incremental repair which is the default repair mechanism, only repairs the data that’s been written since the previous incremental repair. Once data is repaired with the incremental repair, it would not be part of next incremental repair again. And not a good option in case if you have disc corruption, data loss by operator or bugs in Cassandra. Hence, it is required you regularly run the fill repair as well. By default, repair will operate on all token ranges replicated by the node your are running repair on, which will cause the du[plicate work if you run it on every node. The -pr flag will only repair the “primary� ranges on a node. Hence you should use the “nodetool repair -pr� command.