Restore a cluster
Restore data to a cluster from local keyspace backups and backups stored to cloud storage providers like Amazon S3. These restores can be from a particular point-in-time if commit log backups are enabled.
When performing a restore operation, you can restore all the keyspaces from a backup or select specific keyspaces and tables.
|
Keep the following caveats in mind when creating and restoring backups: |
-
Restoring a snapshot that contains only the system keyspace is not allowed. There must be both system and non-system keyspaces, or only non-system keyspaces in the snapshot you want to restore.
-
Restoring a snapshot that does not contain a table definition is not allowed.
-
Restoring a snapshot to a location with insufficient disk space fails. The Restore Report indicates which nodes do not have sufficient space and how much space is necessary for a successful restore. For more information and tips for preventative measures, see Monitor sufficient disk space for restoring backups.
-
OpsCenter does not back up indexes. Therefore, DSE must recompute the indexes after a restore.
Restoring backups stored on Amazon S3
When restoring from backups stored on Amazon S3, OpsCenter chooses a DataStax Agent to determine which nodes in the cluster have data that needs to be restored.
The SSTables stored in the S3 bucket are sorted into directories with the node ID of the original node.
If the cluster topology is unchanged from when the backup was taken, OpsCenter instructs each node to restore the set of SSTables that were stored on that node before.
If the cluster topology has changed since the backup was completed, OpsCenter attempts to match the SSTables to the node that originally stored the SSTable, and distributes the remaining SSTables to the remaining nodes to balance the load evenly.
Restore backups with materialized views
When restoring backups on clusters running DSE 6.0.0 to 6.0.2, materialized views might return no results when queried. To mitigate this issue, do one of the following:
-
Run another restore operation with SSTableloader and truncation enabled.
Running another restore means running SSTableloader, which impacts performance and can cause slowdowns. If performance loss is an issue and you are restoring only a few materialized views, consider the other option to recreate the materialized views.
If you didn’t use SSTableloader for the initial restore, SSTableloader must be selected for the additional restore.
-
Manually recreate materialized views:
-
Get the materialized view schema with
DESCRIBE MATERIALIZED VIEWcommand. -
Copy the output, which is a CQL statement you can use to create the same materialized view.
-
Delete the original materialized view with the
DROP MATERIALIZED VIEWcommand. -
Recreate the materialized view using the output of the
DESCRIBEcommand, which is aCREATE MATERIALIZED VIEWcommand. -
Repeat for all materialized views that need to be recreated.
This option is less involved than running an additional restore, but it can be time consuming if you need to recreate a significant number of materialized views.
-
