Perform a physical restore

This topic describes how to perform a physical restore at the tenant level by using commands. Currently, OceanBase Database allows you to restore all data at the tenant level based on a point in time.

You can restore data to a tenant within the same cluster or to a tenant in a different cluster.

The restore process first recovers the required macroblocks from the full backup and incremental backup to the target tenant based on the command you enter. Then, it synchronously pulls and replays transaction logs.

Prerequisites

Before you perform a physical restore, make sure that you have completed the pre-recovery preparations. For more information, see Prepare for a restore.

Procedure

1. Log in to the sys tenant of the cluster as the root user.

2. (Optional) Execute the following statements to set the restore password for the backup.

   If you add a password when you back up data, you must set a restore password.

   SET DECRYPTION IDENTIFIED BY 'password';
   

   In this statement, you need to replace password with the password you added when you back up data. If the passwords for full backup and incremental backup are different, you must enter both passwords separated by a comma (,). The password for full backup is placed before the password for incremental backup.

   Here is an example where the passwords for full backup and incremental backup are the same:

   SET DECRYPTION IDENTIFIED BY '******';
   

   Here is an example where the passwords for full backup and incremental backup are different:

   SET DECRYPTION IDENTIFIED BY '******','******';
   

3. Execute the following statement to set the encryption information.

   Note

   If you can access the original key management service before or during restore, skip this step.

   obclient [(none)]> SET @kms_encrypt_info = '<encrypted string>';
   

   Here, <encrypted string> is the value of the EXTERNAL_KMS_INFO tenant-level parameter, which is a string that contains some encrypted key management information.

   Note

   The external_kms_info parameter is used to store some key management information. For more information, see external_kms_info.

4. Execute the following statement to start the restore task.

   The statement syntax is as follows:

   • Restore to a specified timestamp

     ALTER SYSTEM RESTORE dest_tenant_name FROM uri UNTIL TIME='timestamp' WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];
     

   • Restore to a specified SCN

     ALTER SYSTEM RESTORE dest_tenant_name FROM uri UNTIL SCN=scn WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];
     

   • Restore to the latest checkpoint

     ALTER SYSTEM RESTORE dest_tenant_name FROM uri WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];
     

   In these statements:

   • dest_tenant_name: the name of the new tenant to restore to.

   • You need to specify the uri parameter, which consists of the data backup path and the log archive path, separately.

   • UNTIL [TIME|SCN] indicates the restore end point, which is the checkpoint where the restore is to end. The restore is performed up to and including the specified checkpoint. When you restore to TIME or SCN, you must use = to connect the specified value. For more information about how to select TIME or SCN, see Physical restore parameters.

   • restore_option supports the pool_list, locality, primary_zone, concurrency, and kms_encrypt parameters. These parameters are separated with &. When you specify locality and primary_zone, we recommend that you maintain the homogeneity with the source tenant. If the configurations are heterogeneous, the system may perform load balancing operations to make the tenant homogeneous after it is activated as the primary tenant, which affects the performance.

     • pool_list: the resource pool created for the new tenant. Multiple resource pools are separated with commas (,).

     • Locality: the locality information of the replicas of the new tenant. It must match the zone information of the pool_list parameter of the target cluster. If you maintain the homogeneity with the source tenant, we recommend that you set the number of full-featured replicas (F) of the new tenant the same as that of the source tenant.

     • primary_zone: the preferred zone of the leader replica. It must match the pool_list and locality parameters. If you maintain the homogeneity with the source tenant, we recommend that you set the number of primary zones of the new tenant the same as that of the source tenant.

     • concurrency: the degree of concurrency for restoring data. If you do not specify this parameter, the default value, which is equal to the maximum number of CPU cores allocated to the tenant, is used. For example, in this topic, the system tenant has allocated 16 CPU cores to the tenant to be restored.

     • kms_encrypt: specifies whether to use the encryption information specified earlier (kms_encrypt_info). If you set this parameter to true, you must specify the kms_encrypt_info parameter. The value of this parameter is false by default.

     For more information about the parameters, see Parameters for physical restore.

   • WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password': the secret key backup information of the tenant to be restored. You must specify this parameter if transparent encryption is configured for the source tenant. Otherwise, the data of the tenant cannot be restored.

     • backup_key_path: the backup path of the tenant's secret key.

     • password: the encryption password set when you back up the tenant's secret key.

     For more information about how to back up the secret key, see Backup the secret key in Prepare for data backup.

   Here are some restore examples:

   • NFS

     • Restore the mysql tenant to the specified timestamp 2020-06-01 00:00:00, the new tenant is named restore_tenant, the resource pool is named restore_pool, and the secret key of the source tenant is restored.

       ALTER SYSTEM RESTORE mysql FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive' UNTIL TIME='2020-06-01 00:00:00' WITH 'pool_list=restore_pool' WITH KEY FROM 'file:///data_backup_dest/key' ENCRYPTED BY '******';
       

     • Restore the mysql tenant to the latest archive checkpoint, the new tenant is named restore_tenant, the resource pool is named restore_pool, and the degree of concurrency is 50.

       ALTER SYSTEM RESTORE mysql FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive' WITH 'pool_list=restore_pool&concurrency=50';
       

     • Restore the mysql tenant to the specified SCN 1658285759724047000, the new tenant is named restore_tenant, and the resource pool is named restore_pool.

       ALTER SYSTEM RESTORE mysql FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive' UNTIL SCN=1658285759724047000 WITH 'pool_list=restore_pool';
       

     • Restore the mysql tenant to the specified timestamp 2020-06-01 00:00:00, the new tenant is named restore_tenant, the resource pool is named restore_pool, and the replica locality is F@z1,F@z2,F@z3.

       ALTER SYSTEM RESTORE mysql FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive' UNTIL TIME='2020-06-01 00:00:00' WITH 'pool_list=restore_pool&locality=F@z1,F@z2,F@z3';
       

     • Restore the mysql tenant to the specified timestamp 2020-06-01 00:00:00, the new tenant is named restore_tenant, the resource pool is named restore_pool, the replica locality is F@z1,F@z2,F@z3, and the primary zone is z1.

       ALTER SYSTEM RESTORE mysql FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive' UNTIL TIME='2020-06-01 00:00:00' WITH 'pool_list=restore_pool&locality=F@z1,F@z2,F@z3&primary_zone=z1';
       

   • OSS

     Apart from the url parameter, the syntax is the same as that for NFS.

     Restore the mysql tenant to the specified timestamp 2020-06-01 00:00:00, the new tenant is named restore_tenant, the resource pool is named restore_pool.

     ALTER SYSTEM RESTORE mysql FROM 'oss://oceanbase-test-bucket/backup/data/?host=xxx.aliyun-inc.com&access_id=xxx&access_key=xxx,oss://oceanbase-test-bucket/backup/archive/?host=xxx.aliyun-inc.com&access_id=xxx&access_key=xxx' UNTIL TIME='2020-06-01 00:00:00' WITH 'pool_list=restore_pool';
     

   • COS

     Apart from the url parameter, the syntax is the same as that for NFS.

     Restore the mysql tenant to the specified timestamp 2020-06-01 00:00:00, the new tenant is named restore_tenant, and the resource pool is named restore_pool.

     ALTER SYSTEM RESTORE mysql FROM 'cos://oceanbase-test-appid/backup?host=cos.ap-xxxx.myqcloud.com&access_id=xxx&access_key=xxx&appid=xxx, cos://oceanbase-test-appid/backup/archive?host=cos.ap-xxxx.myqcloud.com&access_id=xxx&access_key=xxx&appid=xxx' UNTIL TIME='2020-06-01 00:00:00' WITH 'pool_list=restore_pool';
     

5. (Optional) After the Meta tenant corresponding to the tenant to be restored is created, you can accelerate the restore by configuring the scheduling weight of the restore task based on the ha_high_thread_score parameter.

   1. Use the oceanbase.DBA_OB_TENANTS view to check whether the Meta tenant corresponding to the tenant to be restored has been created.

      The sample statement is as follows:

      SELECT * FROM oceanbase.DBA_OB_TENANTS;
      

      In the query result, a tenant whose name starts with META$ in the TENANT_NAME column is the Meta tenant. If the status of the Meta tenant is TENANT_STATUS_NORMAL, the Meta tenant has been created.

      For more information about the DBA_OB_TENANTS view, see DBA_OB_TENANTS.

   2. Configure the ha_high_thread_score parameter.

      The ha_high_thread_score tenant-level parameter specifies the number of current high-priority threads for high availability. The default value is 0, and the value range is [0, 100]. We recommend that you set the value to 10. For more information about the ha_high_thread_score parameter, see ha_high_thread_score.

      Here is a sample statement:

      ALTER SYSTEM SET ha_high_thread_score =10 TENANT = mysql;
      

Next steps

• After you initiate a restore task, you can view the restore progress and results through the console. For more information, see Check the restore progress.

• When the restore task is completed, if you restore the backup data from a lower-version cluster to a higher-version cluster, you need to upgrade the restored tenant. For more information, see Upgrade the tenant after the restore.

• The physical restore process is the same as that in a physical standby database. After the physical restore, the tenant database becomes a standby tenant database. You can use the standby tenant database to provide standby services or primary services. To segmentally archive logs from the source tenant and restore them to the standby tenant, perform the following steps: Prepare the standby tenant for log archive; to switch the standby tenant to a primary tenant, perform the following steps: Convert a standby tenant into a primary tenant.

References

For more information about restores, see Recovery architecture.