Yes the "Node restart method" with -Dcassandra.join_ring=false. Note that they
advise to make a repair anyway. But thanks to join_ring=false the node will
hibernate and not serve stale data.Tell me if I'm wrong you assume that server
A is still OK, therefore system keyspace still exist? If not (disk KO) it's not
the same procedure (hence the tokens in cassandra.yaml that I mentioned).
Actually I'm not sure of what you assume by "node A crashes". You should try on
a test cluster or with CCM (https://github.com/pcmanus/ccm) in order to
familiarize yourself with the procedure.
Romain
Le Mardi 26 avril 2016 11h02, Anuj Wadehra <anujw_2...@yahoo.co.in> a écrit
:
Thanks Romain !! So just to clarify, you are suggesting following steps:
10 AM Daily Snapshot taken of node A and moved to backup location
11 AM A record is inserted such that node A and B insert the record but there
is a mutation drop on node C.
1 PM Node A crashes
1 PM Follow following steps to restore the 10 AM snapshot on node A:
1. Restore the data as mentioned in
https://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_backup_snapshot_restore_t.html
with ONE EXCEPTION >> start node A with -Dcassandra.join_ring=false
.
2. Run repair
3. Retstart the node A with -Dcassandra.join_ring=true
Please confirm.
I was not aware that join_ring can also be used using a normal reboot. I
thought it was only an option during autobootstrap :)
Thanks
Anuj
--------------------------------------------
On Tue, 26/4/16, Romain Hardouin <romainh...@yahoo.fr> wrote:
Subject: Re: Inconsistent Reads after Restoring Snapshot
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Date: Tuesday, 26 April, 2016, 12:47 PM
You can make a restore on the new node A (don't
forget to set the token(s) in cassandra.yaml), start the
node with -Dcassandra.join_ring=false and then run a repair
on it. Have a look at https://issues.apache.org/jira/browse/CASSANDRA-6961
Best,
Romain
Le Mardi 26 avril
2016 4h26, Anuj Wadehra <anujw_2...@yahoo.co.in> a
écrit :
Hi,
We
have 2.0.14. We use RF=3 and read/write at Quorum. Moreover,
we dont use incremental backups. As per the documentation
at ,
if i need to restore a Snapshot on SINGLE node in a cluster,
I would run repair at the end. But while the repair is going
on, reads may get inconsistent.
Consider
following scenario:10
AM Daily Snapshot taken of node A and moved to backup
location11
AM A record is inserted such that node A and B insert the
record but there is a mutation drop on node C.1
PM Node A crashes and data is restored from latest 10 AM
snapshot. Now, only Node B has the record.
Now,
my question is:
Till
the repair is completed on node A,a read at Quorum may
return inconsistent result based on the nodes from which
data is read.If data is read from node A and node C, nothing
is returned and if data is read from node A and node B,
record is returned. This is a vital point which is not
highlighted anywhere.
Please
confirm my understanding.If my understanding is right, how
to make sure that my reads are not inconsistent while a node
is being repair after restoring a snapshot.
I
think, autobootstrapping the node without joining the ring
till the repair is completed, is an alternative option. But
snapshots save lot of streaming as compared to
bootstrap.
Will
incremental backups guarantee that
ThanksAnuj
Sent
from Yahoo Mail on Android
