OceanBase Database enables Global Timestamp Service (GTS) for each tenant. When OceanBase Database commits transactions, it uses GTS of each tenant to retrieve the transaction versions. This ensures that the transactions are committed in the order of their versions.
High availability of services
GTS is the core of a cluster and must be highly available.
For tenants, OceanBase Database uses the leader of tenant-level log stream 1 as the GTS provider, and the time is sourced from the persisted allocatable range of the leader. GTS has three replicas by default, and its high availability capability is the same as that of standard tables.
The GTS leader writes logs of the pre-allocated range to apply for an allocatable range, and synchronizes information between replicas based on log synchronization to avoid data loss.
Assurance of correct timestamps
GTS is globally incremental. This ensures that timestamps remain accurate even if exceptions occur.
- Before a new leader takes effect, it replays the logs written by the older leader for the pre-allocated range, retrieves the maximum value of the old pre-allocated range, and uses the value as the baseline for its timestamp authorization. Therefore, in this scenario, the timestamp provided by GTS does not roll back.
GTS retrieval optimization
Retrieval optimization of the statement snapshot
Transactions update the Global Committed Version of the located server when submitting. If the query of a statement only points to one server, the statement directly uses the Global Committed Version of the server, to reduce the request pressure on the global timestamp.
Retrieval optimization of the transaction commit version
Multiple transactions can uniformly obtain the global timestamp. You can send requests to obtain the timestamp in advance to shorten the transaction commit time.