Migrating or renaming a cluster

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), moving a cluster, or upgrading from an early version cluster to a recent major version.
  • 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

  1. Set up and configure the new cluster as described in Initializing a DataStax Enterprise 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. See Initializing single-token architecture datacenters.
  2. Set up the schema for the new cluster using CQL.
  3. 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.
  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 6.
  5. Snapshot the old cluster.
  6. 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 DataStax Enterprise (DSE).
      • The node ratio is 1:1.
    • If the clusters are different sizes or if you are using vnodes, use the sstableloader (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. Ensure that the new cluster is operating properly and then decommission the old cluster. See Decommissioning a datacenter.