This guide introduces how to back up meta service data and restore from a backup.
A meta snapshot is a backup of meta service’s data at a specific point in time. Meta snapshots are persisted in S3-compatible storage.
Before you can create a meta snapshot, you need to set the backup_storage_url
and backup_storage_directory
system parameters prior to the first backup attempt.
Be careful not to set the backup_storage_url
and backup_storage_directory
when there are snapshots. However, it’s not strictly forbidden. If you insist on doing so, please note the snapshots taken before the setting will all be invalidated and cannot be used in restoration anymore.
To learn about how to configure system parameters, see How to configure system parameters.
Meta snapshot is created by meta service whenever requested by users. There is no automatic process in the RisingWave kernel that creates meta snapshot regularly. However, external tools like RisingWave Console can provide automated backup scheduling and management.
Using RisingWave Console
You can create and manage metadata snapshots through the RisingWave Console, which provides a web-based interface for snapshot operations including manual snapshot creation and automated backup configuration.
Using Command Line
Here’s an example of how to create a new meta snapshot with risectl
:
risectl
is included in the pre-built RisingWave binary. Use the following command instead:
The following SQL command lists existing meta snapshots:
Example output:
Here’s an example of how to delete a meta snapshot with risectl
:
Below are two separate methods to restore from a meta snapshot using SQL database and etcd as the meta store backend.
If the cluster has been using a SQL database as meta store backend, follow these steps to restore from a meta snapshot.
This step is especially important because the meta backup and recovery process does not replicate SST files. It is not permitted for multiple clusters to run with the same SSTs set at any time, as this can corrupt the SST files.
restore-meta
reads snapshot data from backup storage and writes them to meta store and hummock storage.
For example, given the cluster settings below:
Parameters to risectl meta restore-meta
should be:
--backup-storage-url s3://backup_bucket
.--backup-storage-directory backup_data
.--hummock-storage-url s3://state_bucket
. Note that the hummock+
prefix is stripped.--hummock-storage-directory state_data
.If the cluster has been using etcd as meta store backend, follow these steps to restore from a meta snapshot.
This step is especially important because the meta backup and recovery process does not replicate SST files. It is not permitted for multiple clusters to run with the same SSTs set at any time, as this can corrupt the SST files.
If etcd enables authentication, also specify the following:
restore-meta
reads snapshot data from backup storage and writes them to meta store and hummock storage.
For example, given the cluster settings below:
Parameters to risectl meta restore-meta
should be:
--backup-storage-url s3://backup_bucket
.--backup-storage-directory backup_data
.--hummock-storage-url s3://state_bucket
. Note that the hummock+
prefix is stripped.--hummock-storage-directory state_data
.This guide introduces how to back up meta service data and restore from a backup.
A meta snapshot is a backup of meta service’s data at a specific point in time. Meta snapshots are persisted in S3-compatible storage.
Before you can create a meta snapshot, you need to set the backup_storage_url
and backup_storage_directory
system parameters prior to the first backup attempt.
Be careful not to set the backup_storage_url
and backup_storage_directory
when there are snapshots. However, it’s not strictly forbidden. If you insist on doing so, please note the snapshots taken before the setting will all be invalidated and cannot be used in restoration anymore.
To learn about how to configure system parameters, see How to configure system parameters.
Meta snapshot is created by meta service whenever requested by users. There is no automatic process in the RisingWave kernel that creates meta snapshot regularly. However, external tools like RisingWave Console can provide automated backup scheduling and management.
Using RisingWave Console
You can create and manage metadata snapshots through the RisingWave Console, which provides a web-based interface for snapshot operations including manual snapshot creation and automated backup configuration.
Using Command Line
Here’s an example of how to create a new meta snapshot with risectl
:
risectl
is included in the pre-built RisingWave binary. Use the following command instead:
The following SQL command lists existing meta snapshots:
Example output:
Here’s an example of how to delete a meta snapshot with risectl
:
Below are two separate methods to restore from a meta snapshot using SQL database and etcd as the meta store backend.
If the cluster has been using a SQL database as meta store backend, follow these steps to restore from a meta snapshot.
This step is especially important because the meta backup and recovery process does not replicate SST files. It is not permitted for multiple clusters to run with the same SSTs set at any time, as this can corrupt the SST files.
restore-meta
reads snapshot data from backup storage and writes them to meta store and hummock storage.
For example, given the cluster settings below:
Parameters to risectl meta restore-meta
should be:
--backup-storage-url s3://backup_bucket
.--backup-storage-directory backup_data
.--hummock-storage-url s3://state_bucket
. Note that the hummock+
prefix is stripped.--hummock-storage-directory state_data
.If the cluster has been using etcd as meta store backend, follow these steps to restore from a meta snapshot.
This step is especially important because the meta backup and recovery process does not replicate SST files. It is not permitted for multiple clusters to run with the same SSTs set at any time, as this can corrupt the SST files.
If etcd enables authentication, also specify the following:
restore-meta
reads snapshot data from backup storage and writes them to meta store and hummock storage.
For example, given the cluster settings below:
Parameters to risectl meta restore-meta
should be:
--backup-storage-url s3://backup_bucket
.--backup-storage-directory backup_data
.--hummock-storage-url s3://state_bucket
. Note that the hummock+
prefix is stripped.--hummock-storage-directory state_data
.