Cloning cluster data from clusters managed by the same OpsCenter instance

About this task

Clone cluster data from one DSE cluster to another using the Restore Backup feature in OpsCenter. This workflow requires the source and target clusters to both be managed by the same OpsCenter instance.

Prerequisites

To clone cluster data, a backup of the cluster to a supported location must exist. See adding a backup location.

When cloning a cluster:

The Backup Service requires control over the data and structure of its destination locations. The backup destinations must be dedicated for use only by OpsCenter. Any additional directories or files in those destinations can prevent the Backup Service from properly conducting a Backup or Restore operation.

Procedure

  1. Select cluster name > Services.

  2. Select the Details link for the Backup Service.

  3. In the Activity tab, click Restore Backup.

    The Restore from Backup dialog appears.

    Step 1 of 2: Select Backup

  4. In the Backups tab, select the backup that contains the data you want to clone and click Next.

    On Server backups are not eligible for cloning.

    The Restore from Backup: Step 2 of 2 dialog appears. Step 2 of 2: Configure and Restore (Clone)

  5. In Keyspaces and Graphs, select the tables or graphs you want to restore.

    • Click All Keyspaces or All Graphs to restore all keyspaces or all graphs.

    • Click the keyspace name or graph name to include all tables or all graphs in the keyspace.

    • To select specific tables or graphs, expand the keyspace name or graph name and select the specific tables or graphs to back up.

      For DSE 6.0.0-6.0.4, when restoring a DSE Graph backup without selecting Use sstableloader, DSE must be restarted to ensure all data is available.

  6. Under Location, select the target cluster for the restored data. Select a different cluster than the one that was backed up to clone the data to the cluster.

    The Location list is only available when there are multiple clusters and both clusters are managed by the same instance of OpsCenter.

  7. When cloning data, it is not necessary to select the Truncate/delete existing data before restore option because it is a not operational for a cloning workflow. The truncate option purges data on a target before a restore runs. When using the restore feature to clone, the truncate option does not do anything because there is no data to purge before the restore runs.

  8. To prevent overloading the network, set a maximum transfer rate for the restore using the Throttle DSE stream throughput at __ MB option.

    To enter a value for this option, you must select Use sstableloader. Otherwise, the transfer rate value is ignored.

  9. To bulk load external data into a cluster, select Use sstableloader.

    Using sstableloader restores data to a cluster regardless of its original topology, at the expense of speed and performance. Restoring to a cluster that uses tiered storage requires using sstableloader. See sstableloader for details.

    When restoring from a backup, OpsCenter might report that the restore was successful, even if it failed. This behavior can occur when copying SSTables into the new data directories and running nodetool refresh afterward. To determine whether the restore failed, search the DataStax Agent logs for a string indicating "Error copying sstables to data dir:". This issue is present only in OpsCenter 6.8.0.

  10. Optional If necessary, change the staging directory by setting the backup_staging_directory configuration option in the address.yaml file.

  11. Click Restore Backup.

    The Confirm Restore dialog appears.

    Confirm restore operation dialog

    If a value was not set for throttling stream output, a warning message indicates the consequences of unthrottled restores. Take one of the following actions:

    • Click Cancel and set the throttle value in the Restore from Backup dialog.

    • Set the stream_throughput_outbound_megabits_per_sec and inter_dc_stream_throughput_outbound_megabits_per_sec values in cassandra.yaml.

    • Proceed anyway at the risk of creating network bottlenecks.

      If using LCM to manage DSE cluster configuration, update Cluster Communication settings in cassandra.yaml in the configuration profile for the cluster and run a configuration job. Stream throughput (not inter-dc) is set to 200 in LCM defaults.

      Update throttle options in LCM

  12. Click Start Restore to confirm the restore.

    If the pre-restore checks detected schema differences that could not automatically be validated, the Restore Schema Validation dialog appears.

    Possible issues are listed and a comparison of the backup and current schema are presented side-by-side.

    opscBackupServiceForceRestore

  13. Review the information to determine if adjustments or corrections to the current schema are required:

    • To correct schema issues, click Cancel, rectify the issues, and try the restore again.

    • To proceed despite the schema mismatch, click Continue Restore.

      Attempting to restore a backup with an incompatible schema might result in corrupt or inaccessible data. Before forcing the restore, back up your current data.

Results

The details and progress of the restore operation are displayed in a progress dialog, and also appear in the Backup Activity of the target cluster. If you close the progress dialog, track the progress and status of the restore in the target cluster’s Backup Activity section.

The progress and details of the restore operation are displayed in the Restore Report.

cloneRestoreReport

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com