Thanks Eric and Matt :) !!
Yes the purpose is to improve reliability.
Right now, from our driver we are querying using degradePolicy for
reliability.
*For changing the keyspace for RF=3, the procedure is as under:*
1. Add a new node to the cluster (new node is not in seed list)
2. ALTER KEYSPACE system_auth WITH REPLICATION =
{'class' : 'NetworkTopologyStrategy', 'dc1' : 3};
1. On each affected node, run nodetool repair
<http://docs.datastax.com/en/cassandra/1.2/cassandra/tools/toolsNodetool_r.html>.
2. Wait until repair completes on a node, then move to the next node.
Any other things to take care?
Thanks
Regards
neha
On Mon, Apr 27, 2015 at 9:45 PM, Eric Stevens <migh...@gmail.com> wrote:
> It depends on why you're adding a new node. If you're running out of disk
> space or IO capacity in your 2 node cluster, then changing RF to 3 will not
> improve either condition - you'd still be writing all data to all three
> nodes.
>
> However if you're looking to improve reliability, a 2 node RF=2 cluster
> cannot have either node offline without losing quorum, while a 3 node RF=3
> cluster can have one node offline and still be able to achieve quorum.
> RF=3 is a common replication factor because of this characteristic.
>
> Make sure your new node is not in its own seeds list, or it will not
> bootstrap (it will come online immediately and start serving requests).
>
> On Mon, Apr 27, 2015 at 8:46 AM, Neha Trivedi <nehajtriv...@gmail.com>
> wrote:
>
>> Hi
>> We have a 2 Cluster Node with RF=2. We are planing to add a new node.
>>
>> Should we change RF to 3 in the schema?
>> OR Just added a new node with the same RF=2?
>>
>> Any other Best Practice that we need to take care?
>>
>> Thanks
>> regards
>> Neha
>>
>>
>
