Multiversion
OceanBase Database is a multiversion distributed database service. Each row has a rowkey. Each modification of a row is called a version of this row. In the memory, a version of a row is recorded by using TransNode, and multiple versions are serialized in descending order into a linked list.
As shown in the following figure, Row A has four versions numbered as 12, 11, 8, and 2.
If the data amount in the memory exceeds the specified threshold, a minor compaction is performed to migrate the data to a disk, and the file of compacted data is called an SSTable. The SSTable also retains multiple data versions, and multi_version_start specifies the initial point of versions. In other words, the SSTable retains the multiversion information of all data from this point. base_version and snapshot_version respectively specify the left and the right boundaries of the transaction commit versions of data in the SSTable.
Multiversion information retained by restore points
A name is specified for a restore point and is associated with a version number, which is the one when the restore point is created. The data corresponding to this version number is saved for subsequent queries or for rolling back the entire database to this point. Currently, OceanBase Database does not allow you to roll back data to a restore point. Instead, you can query the data corresponding to a restore point. In OceanBase Database, a restore point is a tenant-level configuration. Therefore, only tenant data is retained when a restore point is being created.
When a restore point is being created, the current timestamp is used as the version number and is returned to the relevant client after the value of Global Timestamp Service (GTS) exceeds the timestamp. Then, the multiversion data can be directly read by using a flashback query syntax. For more information about flashback queries, see Flashback queries.
After the data of a restore point is compacted into SSTables, the backend saves these SSTables and associates them with the restore point. During garbage collection for SSTables, an SSTable cannot be deleted if it is associated with a restore point.
Usage notes
After a restore point is created, DDL statements cannot be executed on tables that already exist before the restore point is created.
Restore points depend on the globally consistent snapshots. Therefore, GTS must be enabled to use restore points.
A maximum of 10 restore points can be created in a tenant. This prevents restore points from occupying excess resources.