Migrating or renaming without interruption of service.
The information on this page is intended for the following types of scenarios:
- Migrating a cluster, including transitioning an EC2 cluster to Amazon
virtual private cloud (VPC) or moving a cluster.
- Renaming a cluster. You cannot change the name of an existing cluster; you
must create a new cluster and migrate your data to the new cluster.
The following method migrates a cluster without service interruption and ensures that
if a problem occurs in the new cluster, you still have an existing cluster as a
fallback.
Procedure
-
Set up and configure the new cluster as described in Initializing a Cassandra cluster.
-
Set up the schema for the new cluster using CQL.
-
Configure your client to write to both clusters.
Note: Depending on how the writes are implemented, code changes may be required.
Be sure to use identical consistency levels.
-
Ensure that the data is flowing to the new nodes so you won't have any gaps
when you copy the snapshots to the new cluster in 6.
-
Snapshot the old cluster.
-
Copy the data files from your keyspaces to the nodes.
- You can copy the data files to their matching nodes in the new cluster,
which is simpler and more efficient, if:
- You are not using vnodes.
- Both clusters use the same version of the DataStax Distribution of
Apache Cassandra™ (DDAC).
- The node ratio is 1:1.
- If the clusters are different sizes or if you are using vnodes, use the
sstableloader
(sstableloader).
-
You can either switch to the new cluster all at once or perform an incremental
migration.
For example, to perform an incremental migration, you can set your client to
designate a percentage of the reads that go to the new cluster. This allows
you to test the new cluster before decommissioning the old cluster.
-
Ensure that the new cluster is operating properly and then decommission the old
cluster. See Decommissioning a datacenter.