Hi,
Is there any use case where we need full repair and incremental repair will
> not help?
To complete the answer from Jon above, my understanding is that even if
incremental repairs work well for you, if a node loses some repaired
information for some reason (corrupted SSTable, disk failure, .
What is the correct process to backup and restore in cassandra?
Should we do backup node by node like first schema backup from all the
nodes then all other stuff?
In restore the schema should be restored on one node or all the nodes
again?It will give Already Exists Exception but still what's the c
Can you do a nodetool describecluster and check if the schema version is
matching on all the nodes?
On Tue, Nov 21, 2017 at 11:52 PM, @Nandan@
wrote:
> Hi Team,
>
> Today I set up a test cluster with 4 nodes and using Apache Cassandra
> 3.1.1 version.
> After setup when I checked output.log fil
Hi Jai,
I checked nodetool describecluster and got same schema version on all 4
nodes.
> [nandan@node-1 ~]$ nodetool describecluster
Cluster Information:
Name: Nandan
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema version
Hi guys,
I have two questions about the drain status.
The doc says when a node is drained it stops accepting new requests and
flush memtable to disk. Does it stops accepting new requests immediately or
wait for the majority of the nodes to gossip about the DRAINED status? If
it stops accepting ne
It stops accepting writes immediately. New requests won't be sent to the
node, but existing in-flight queries should be completed. There could be
some client exceptions for coordinated queries, but if you have speculative
execution set up on your clients these cases should be covered.
Consistency
