Was this page helpful?
Note
Currently, Scylla Manager supports only entire schema restoration, so --keyspace
flag is not allowed.
Note
Because of small size of schema files, resuming schema restoration always starts from scratch.
In order to restore Scylla cluster schema use sctool restore with --restore-schema
flag.
Scylla Manager with CQL credentials to restore destination cluster.
Otherwise, the restored schema might be overwritten by the already existing one and cause unexpected errors.
All nodes in restore destination cluster should be in the UN
state (See nodetool status for details).
After successful restore it is important to perform necessary follow-up action. In case of restoring schema, you should make a rolling restart of an entire cluster. Without the restart, the restored schema might not be visible, and querying it can return various errors.
It is recommended to drop all materialized views and secondary indexes that are part of the restored schema.
The next step, --restore-tables
, does not restore materialized views or secondary indexes.
It is the end user’s responsibility to drop and recreate them after the tables have been successfully restored.
Because of being unable to alter schema tables tombstone_gc
option, restore procedure “simulates ad-hoc repair”
by duplicating data from each backed-up node into each node in restore destination cluster.
Fortunately, the small size of schema files makes this overhead negligible.
Validate that all nodes are in the
UN
stateFor each backup location:
Find all Scylla nodes with location access and use them for restoring schema from this location
List backup manifests for specified snapshot tag
For each manifest:
Filter relevant tables from the manifest
For each table:
For each node (in
--parallel
):
Download all SSTables
For all nodes in restore destination cluster:
nodetool refresh on all downloaded schema tables (full parallel)
Was this page helpful?