If you are doing this full bulk reload a lot, it may make more sense to use a separate cluster to bring up the new data and then atomically switch your clients/apps to the IP address of the new cluster once you've validated it, and then decommission and recyle the machines of the old cluster. This would maximize performance of the production cluster and maximize performance of the staging process as well. And you would need less hardware for each node/cluster as well since you won't need to support two copies of the data on a single node/cluster. It will also make it a lot easier to upgrade the cluster without worry about impact on production during the upgrade since the client/app would only ever see a fully consistent cluster. (I lost count of how many wins this approach would give you!)
-- Jack Krupansky On Wed, Jan 27, 2016 at 10:53 AM, Jonathan Haddad <j...@jonhaddad.com> wrote: > Why rename the keyspace? If it was me I'd just give it a name that > includes the date or some identifier and include that logic in my app. > That's way easier. > On Wed, Jan 27, 2016 at 6:49 AM Jean Tremblay < > jean.tremb...@zen-innovations.com> wrote: > >> Hi, >> >> I have a huge set of data, which takes about 2 days to bulk load on a >> Cassandra 3.0 cluster of 5 nodes. That is about 13 billion rows. >> >> Quite often I need to reload this data, new structure, or data is >> reorganise. There are clients reading from a given keyspace (KS-X). >> >> Since it takes me 2 days to load my data, I was planning to load the new >> set on a new keyspace (KS-Y), and when loaded drop KS-X and rename KS-Y to >> KS-X. >> >> Now I know "renaming keyspace" is a functionality which was removed. >> >> Would this procedure work to destroy an old keyspace KS-X and rename a >> new keyspace KS-Y to KS-X: >> >> 1) nodetool drain each node. >> 2) stop cassandra on each node. >> 3) on each node: >> 3.1) rm -r data/KS-X >> 3.2) mv data/KS-Y data/KS-X >> 4) restart each node. >> >> Could someone please confirm this? I guess it would work, but I’m just >> afraid that there could be in some system table some information that would >> not allow this. >> >> Thanks for your help. >> >> Cheers >> >> Jean > >
