cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maki Watanabe <watanabe.m...@gmail.com>
Subject Re: Changing the replication factor of a keyspace
Date Tue, 25 Oct 2011 05:42:43 GMT
Konstantin,

You can modify the RF of the keyspace with following command in cassandra-cli:

  update keyspace KEYSPACE_NAME with storage_options = {replication_factor:N};

When you decrease RF, you need to run nodetool clean on each node.
When you increase RF, you need to run nodetool repair on each node.

Please refer to:
http://wiki.apache.org/cassandra/Operations#Replication
for more information.


2011/10/25 Konstantin Naryshkin <konstantinn@a-bb.net>:
> We are setting up my application around Cassandra .8.0 (will move to
> Cassandra 1.0 in the near future). In production the application will
> be running in a two (or more) node cluster with RF 2. In development,
> we do not always have 2 machines to test on, so we may have to run a
> Cassandra cluster consisting of only a single node. In this case, we
> have to reduce the RF of the column family to 1. We may need to switch
> machines from one schema to the other and back again. This is not
> something that will occur often and not in live production. I noticed
> that there is an alter keyspace command in the cassandra-cli and
> PyCassa, which should allow me to change the strategy options. So, it
> is possible to switch a Cassandra instance from RF 1 to RF 2 and back
> again? Will we have something horrible happen if we try to do it on a
> node with data? Is there anything in particular that we have to do
> before/after the transition to make the transition safe?
>
> I assume that we have to first alter the keyspace and then
> decommission one of the nodes and this will prevent us from losing
> half of our data.
>



-- 
w3m

Mime
View raw message