cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Coli <>
Subject Re: Explode a keyspace into multiple ones online
Date Tue, 28 Oct 2014 17:55:26 GMT
On Tue, Oct 28, 2014 at 8:01 AM, Alain RODRIGUEZ <> wrote:

> By the way I found this reference:
> Is this still the "easiest" solution ? Does this work for same table name
> but transferring data to a new keyspace ? Can we migrate sstables this way ?

The author of that solution is as wise as he is modest... that said,
there's a really easy way to "split" some column families out of a
Keyspace, even easier than the above.
To anyone who is wondering about the manual way to do this :

1) create schema for NEW_Keyspace
2) stop writes to OLD_Keyspace from app (reads can continue)
3) flush OLD_Keyspace on every node, via nodetool
4) hard link all sstables from OLD_Keyspace directory to NEW_Keyspace
5) call nodetool -h localhost refresh NEW_Keyspace
6) enable reads/writes from/to NEW_Keyspace from app (disable reads on
7) clean up OLD_Keyspace (drop schema, delete files, etc.)

Alternately, if you don't want to do 2/6 because you can't tolerate
OLD_Keyspace not being writable, you can enable writes to NEW_Keyspace,
flush OLD_Keyspace, hard link the just-flushed tables and then enable reads
from NEW_Keyspace. This resolves the delta with a shorter window where you
can't write.

The same technique could also be applied to renaming Columnfamilies,
although in the Columnfamily case the files also need to be renamed. In
Cassandra 1.1+, the files get renamed to include the Keyspace name, so that
would have to change as appropriate.

(Additional Notes :
In 1) You have to create the scheme with all the column familys and indexes.

In 4) remember that the files that stored the sstables start with the name
of the keyspace. You have to rename the files in order to be recognized by
the nodetool refresh.)

In 5), there is a race whereby if you are writing to NEW_Keyspace, you have
a nonzero chance of clobbering files with newly flushed files [1]

I see you on that ticket (in July 2013!) but perhaps you do not remember
its relevance.. :D

The primary reason to move Columnfamlies between Keyspaces is that
replication configuration is on the Keyspace level. So you can for example
have some Columnfamilies only available in some DCs, or with a lower RF.


View raw message