This topic describes the physical restore process and architecture.
Restore overview
OceanBase Database provides restore capabilities at the tenant level, supporting full recovery and partial recovery with specified SCN or timestamp. In this context, SCN represents the precise internal version number of OceanBase Database. The timestamp, in Oracle mode, is accurate up to nanoseconds without any loss of precision. In MySQL mode, the timestamp is accurate up to microseconds but loses precision beyond that.
Tenant-level restore ensures global consistency across tables and partitions.
The restore process of OceanBase Database contains the following steps:
RootService creates the required log streams based on the backup data.
The leader of the log streams dispatches the data and logs restored on it, and the followers pull data and logs from the leader.
After RootService detects that all log streams are restored, 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 restored data.