Re: Node Failure Scenario

Thank you Jonathan and all. On Tue, Nov 14, 2017 at 10:53 PM, Jonathan Haddad wrote: > Anthony’s suggestions using replace_address_first_boot lets you avoid that > requirement, and it’s specifically why it was added in 2.2. > On Tue, Nov 14, 2017 at 1:02 AM Anshu Vajpayee

Re: Node Failure Scenario

Anthony’s suggestions using replace_address_first_boot lets you avoid that requirement, and it’s specifically why it was added in 2.2. On Tue, Nov 14, 2017 at 1:02 AM Anshu Vajpayee wrote: > ​Thanks guys , > > I thikn better to pass replace_address on command line

Re: Node Failure Scenario

​Thanks guys , I thikn better to pass replace_address on command line rather than update the cassndra-env file so that there would not be requirement to remove it later. ​ On Tue, Nov 14, 2017 at 6:32 AM, Anthony Grasso wrote: > Hi Anshu, > > To add to Erick's

Re: Node Failure Scenario

Hi Anshu, To add to Erick's comment, remember to remove the *replace_address* method from the *cassandra-env.sh* file once the node has rejoined successfully. The node will fail the next restart otherwise. Alternatively, use the *replace_address_first_boot* method which works exactly the same

Re: Node Failure Scenario

Use the replace_address method with its own IP address. Make sure you delete the contents of the following directories: - data/ - commitlog/ - saved_caches/ Forget rejoining with repair -- it will just cause more problems. Cheers! On Mon, Nov 13, 2017 at 2:54 PM, Anshu Vajpayee

Node Failure Scenario

Hi All , There was a node failure in one of production cluster due to disk failure. After h/w recovery that node is noew ready be part of cluster, but it doesn't has any data due to disk crash. I can think of following option : 1. replace the node with same. using replace_address 2. Set