A host can replace itself using the method I described
> On Jun 12, 2019, at 7:10 AM, Alan Gano <ag...@tsys.com> wrote: > > I guess I’m considering this scenario: > · host and configuration have survived > · /data is gone > · /backups have survived > > I have tested recovering from this scenario with an evict/re-add, which > worked fine. > > If I restore from backup, the node will be behind the cluster – errrr, does > it get caught up after a restore and start it up? > > Alan > > From: Jeff Jirsa [mailto:jji...@gmail.com] > Sent: Wednesday, June 12, 2019 10:02 AM > To: user@cassandra.apache.org > Subject: Re: Recover lost node from backup or evict/re-add? > > To avoid violating consistency guarantees, you have to repair the replicas > while the lost node is down > > Once you do that it’s typically easiest to bootstrap a replacement (there’s a > property named “replace address first boot” you can google or someone can > link) that tells a new joining host to take over for a failed machine. > > > On Jun 12, 2019, at 6:54 AM, Alan Gano <ag...@tsys.com> wrote: > > > If I lose a node, does it make sense to even restore from > snapshot/incrementals/commitlogs? > > Or is the best way to do an evict/re-add? > > > Thanks, > > Alan. > > NOTICE: This communication is intended only for the person or entity to whom > it is addressed and may contain confidential, proprietary, and/or privileged > material. Unless you are the intended addressee, any review, reliance, > dissemination, distribution, copying or use whatsoever of this communication > is strictly prohibited. If you received this in error, please reply > immediately and delete the material from all computers. Email sent through > the Internet is not secure. Do not use email to send us confidential > information such as credit card numbers, PIN numbers, passwords, Social > Security Numbers, Account numbers, or other important and confidential > information. > NOTICE: This communication is intended only for the person or entity to whom > it is addressed and may contain confidential, proprietary, and/or privileged > material. Unless you are the intended addressee, any review, reliance, > dissemination, distribution, copying or use whatsoever of this communication > is strictly prohibited. If you received this in error, please reply > immediately and delete the material from all computers. Email sent through > the Internet is not secure. Do not use email to send us confidential > information such as credit card numbers, PIN numbers, passwords, Social > Security Numbers, Account numbers, or other important and confidential > information.