Restore architecture

This topic describes the physical restore process and architecture.

Restore overview

OceanBase Database provides tenant-level restore capabilities and supports full restore and partial restore to the specified system change number (SCN) or timestamp. An SCN is a precise data version number in OceanBase Database. A timestamp is accurate to microseconds in MySQL mode, and the precision after microseconds will be lost.

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

The restore process of OceanBase Database contains the following steps:

1. RootService creates the required log streams based on the backup data.

2. The leader of the log streams dispatches the data and logs recovered on it, and the followers pull data and logs from the leader.

3. After RootService detects that all log streams are recovered, it considers that tenant data restore is completed.

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

Restore transaction consistency

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