This topic explains the technical principles behind table-level restore.
Overall process
The table-level restore feature in OceanBase Database allows users to restore specific tables from backup data into an existing tenant. The target tenant can be the same as the original tenant, a different tenant within the same cluster, or even a tenant in a different cluster.
The process of table-level restore involves the following steps:
Restore an auxiliary tenant.
Use backup and archived data to restore an auxiliary tenant to a specified point in time.
Import tables across tenants.
Import the structure, data, and related schemas (such as indexes) of the specified table from the auxiliary tenant to the target tenant.
Clean up the auxiliary tenant and release resources.
The auxiliary tenant serves a similar role to the auxiliary instance in Oracle databases. It is a temporary tenant used during the restoration process and consumes additional computing and storage resources.
Mechanism for cross-tenant table import
In the current version, the table-level restore feature in OceanBase Database supports a three-level parallelism mechanism (L1/L2/L3) during the cross-tenant table import phase.
The three levels of parallelism for cross-tenant table import are as follows:
L1-level multi-table parallelism: Allows for the concurrent execution of cross-tenant table import tasks for up to recover_table_concurrency tables.
L2-level parallelism within a table: All partitions of a single table are restored in parallel.
L3-level parallelism within a partition: The system splits each partition into up to recover_table_dop subtasks for restoring a partition, with each subtask executed by an independent table-level restore thread, achieving internal parallelism within a partition.
L1/L2/L3-level parallel tasks require thread resources from the table-level restore thread pool. The number of threads in this pool is controlled by the configuration item ddl_thread_score.
Data is imported from the auxiliary tenant to the target tenant in parallel, which consumes resources of the target tenant. We recommend that you configure resource isolation for the target tenant to avoid impact on business requests.