恢复失败的数据库

在集群失败或数据库损坏后恢复数据库。

当集群发生故障或数据库损坏时，您必须：

1. 从 CCS 文件恢复集群配置
2. 使用以前的配置和数据恢复数据库

要将数据还原到新集群中的数据库， 您必须将数据库持久性文件（备份、AOF 或快照文件）还原到数据库。 这些文件存储在持久性存储位置。

数据库恢复过程包括：

1. 如果集群失败，请恢复集群。
2. 确定可恢复的数据库。
3. 还原数据库数据。
4. 验证数据库是否处于活动状态。

先决条件

• 在开始数据库恢复之前，请确保托管数据库的集群运行状况良好。 在集群发生故障的情况下， 您必须先恢复集群，然后才能恢复数据库。

• 我们建议您为新的集群节点分配新的持久性存储驱动器。 如果您使用原始存储驱动器， 确保将旧的 Persistent Storage 驱动器上的所有文件备份到另一个位置。

恢复数据库

准备托管数据库的集群后， 您可以从rladmin命令行界面 （CLI）。

要恢复数据库：

1. 将包含恢复文件的持久性存储驱动器挂载到新节点。 这些驱动器必须包含集群配置备份文件和数据库持久性文件。

   注意：

   确保用户redislabs有权访问存储位置 的配置和持久性文件。

   如果您使用本地持久性存储，请将所有恢复文件放在每个集群节点上。

2. 要查看哪些数据库是可恢复的，请运行：

   rladmin recover list
   

   The status for each database can be either ready for recovery or missing files. An indication of missing files in any of the databases can result from:

   • The storage location is not found - Make sure the recovery path is set correctly on all nodes in the cluster.
   • Files are not found in the storage location - Move the files to the storage location.
   • No permission to read the files - Change the file permissions so that redislabs:redislabs has 640 permissions.
   • Files are corrupted - Locate copies of the files that are not corrupted.

   If you cannot resolve the issues, contact Redis support.

3. Recover the database using one of the following rladmin recover commands:

   • Recover all databases from the persistence files located in the persistent storage drives:

     rladmin recover all
     

   • Recover a single database from the persistence files located in the persistent storage drives:

     • By database ID:

       rladmin recover db db:<id>
       

     • By database name:

       rladmin recover db <name>
       

   • Recover only the database configuration for a single database (without the data):

     rladmin recover db <name> only_configuration
     

   Note:

   • If persistence was not configured for the database, the database is restored empty.
   • For Active-Active databases that still have live instances, we recommend that you recover the configuration for the failed instances and let the data update from the other instances.
   • For Active-Active databases where all instances need to be recovered, we recommend you recover one instance with the data and only recover the configuration for the other instances. The empty instances then update from the recovered data.
   • If the persistence files of the databases from the old cluster are not stored in the persistent storage location of the new node, you must first map the recovery path of each node to the location of the old persistence files. To do this, run the node <id> recovery_path set command in rladmin. The persistence files for each database are located in the persistent storage path of the nodes from the old cluster, usually under /var/opt/redislabs/persist/redis.

4. To verify that the recovered databases are now active, run:

   rladmin status
   

PUT /v1/cluster/policy
{
  "auto_recovery": true
}

PUT /v1/bdbs/<bdb_uid>
{
  "recovery_wait_time": 3600
}