Edge cases for transitioning or migrating a cluster

Unusual migration scenarios without interruption of service.

The information in this topic is intended for the following types of scenarios (without any interruption of service):
  • Transition a cluster on EC2 to a cluster on Amazon virtual private cloud (VPC).
  • Migrate from a cluster when the network separates the current cluster from the future location.
  • Migrate from an early Cassandra cluster to a recent major version.

Procedure

The following method ensures that if something goes wrong with the new cluster, you still have the existing cluster until you no longer need it.
  1. Set up and configure the new cluster as described in Initializing a cluster.
    Note: If you're not using vnodes, be sure to configure the token ranges in the new nodes to match the ranges in the old cluster.
  2. Set up the schema for the new cluster using CQL.
  3. Configure your client to write to both clusters.

    Depending on how the writes are done, code changes may be needed. Be sure to use identical consistency levels.

  4. 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 step 6.
  5. Snapshot the old EC2 cluster.
  6. Copy the data files from your keyspaces to the nodes.
    • If not using vnodes and the if the node ratio is 1:1, it's simpler and more efficient to simply copy the data files to their matching nodes.
    • If the clusters are different sizes or if you are using vnodes, use the sstableloader (Cassandra bulk loader) (sstableloader).
  7. 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.

  8. Decommission the old cluster, as described in Decommissioning a datacenter.