Restoration architecture

This topic describes the physical restoration process and architecture.

Restoration overview

OceanBase Database provides tenant-level restoration capabilities and supports a millisecond-level restoration precision.

Tenant-level restoration ensures global consistency across tables and partitions.

The restoration process of OceanBase Database contains the following steps:

1. Restore the data of system tables.

2. Restore the logs of system tables.

3. Correct the data of system tables.

4. Restore the data of user tables.

5. Restore the logs of user tables.

For a single partition, the backup and restoration process is similar to the restart process and involves the loading of data and application logs.

Restore the data of system tables

RootService creates partitions based on the list of system tables in the data backup, and then sequentially schedules the leader of each partition to copy the metadata and macroblock data of the corresponding partition from the backup media.

Restore the logs of system tables

The log restoration process is similar to the log replay process after a restart. After the leader of a restored partition completes data restoration, the leader pulls the partition-level backup logs from the backup media, and then saves the logs to the local clog directory. When the leader is saving the restored clogs to the local directory, the clog replay thread starts to replay data to the MemStore. After all clogs are restored, the restoration of a partition is complete.

Correct the data of system tables

After system tables are restored, RootService performs the following steps to correct the data of system tables.

1. Clear unfinished index tables.

2. Make compatibility compensation after the backup data of an old version is restored to a cluster of a new version:

   1. Create new system tables.

   2. Execute a cross-version update task.

Restore the data of user tables

The data and log restoration process for user tables is similar to that for system tables. The only difference lies in the data sources of lists used for creating partitions. When RootService is restoring the data of user tables, RootService reads the required lists from the restored system tables.

Restore transaction consistency

In OceanBase Database, physical backup and restoration depends on the Global Timestamp Service (GTS) feature of tenants. GTS ensures global consistency between the backup and restored data.

Logical restoration

OceanBase Database no longer provides cluster-level logical backup and restoration in V2.2.7x and later. Instead, it provides OBDUMPER for logical backup and OBLOADER for logical restoration. OBLOADER is a client import tool developed based on Java. It can import data in the SQL or CSV format and supports throttling and resumption after an interruption during import.