OceanBase Database in shared storage mode relies on Log Service for data persistence and multi-replica computing nodes for high availability. This topic describes the disaster recovery deployment options supported by OceanBase Database in shared storage mode.
OceanBase Database in shared storage mode ensures data integrity through object storage and log integrity through Log Service, providing the following high availability solutions:
High availability solution based on Paxos consensus protocol for LogService This solution provides multi-replica high availability disaster recovery capabilities based on the Paxos consensus protocol. Write nodes (RW) directly write data to multiple replicas of LogService through the Paxos protocol to ensure data persistence. Read-only nodes (RO) read logs from the most recent LogService replica and replay hot data locally. If a minority of replicas are unavailable (up to one replica in a three-replica cluster), the computing nodes can still provide services without affecting read and write operations.
High availability solution for RW nodes based on multi-replica computing nodes This solution provides disaster recovery capabilities through multi-replica read-only nodes. If RW nodes are unavailable, the database automatically executes a disaster recovery switch and restores services, ensuring no data loss (RPO = 0) and a fault recovery time of less than 8 seconds (RTO < 8s).
High availability solution based on single-replica startup This solution provides disaster recovery capabilities even without computing nodes. If there are no read-only nodes for disaster recovery, the database stores data in object storage and ensures incremental data integrity through Log Service. A new computing node can then be started to restore full service capabilities. This involves restoring data and metadata from object storage and incremental data from Log Service, ensuring no data loss (RPO = 0) and a fault recovery time of minutes (RTO in minutes).
OceanBase Database in shared storage mode recommends the following deployment modes, which you can choose based on your IDC configuration and performance and availability requirements. | Deployment mode | Disaster recovery capability | RTO | RPO | |---------|---------|-----|-----| | Single IDC (multi-replica computing nodes) | Machine-level lossless disaster recovery | Within 8 seconds | 0 | | Single IDC (single-replica computing node) | Single-replica startup disaster recovery | Minutes | 0 | | Multi-IDC (multi-replica computing nodes) | IDC-level lossless disaster recovery | Within 8 seconds | 0 | | Three IDCs (three-replica LogService) | LogService-level lossless disaster recovery | Within 8 seconds | 0 |
Single IDC deployment (multi-replica computing nodes)
If you have only one IDC, you can deploy RW nodes and multiple RO nodes within the same IDC to achieve machine-level lossless disaster recovery. If the server hosting the RW node fails, the system automatically executes a disaster recovery switch, promoting an RO node to an RW node to continue providing services without data loss (RPO = 0) and a fault recovery time of less than 8 seconds (RTO < 8s).
Single IDC deployment (single-replica computing node)
If you have only one IDC and deploy a single computing node, you can use the single-replica startup mechanism to provide disaster recovery capabilities. If the computing node is unavailable, a new computing node can be started to restore full service capabilities by restoring data and metadata from object storage and incremental data from Log Service. This solution ensures no data loss (RPO = 0) and a fault recovery time of minutes (RTO in minutes).
Multi-IDC deployment (multi-replica computing nodes)
If you have multiple IDCs in the same city, you can deploy computing nodes (RW and RO) across IDCs to achieve IDC-level lossless disaster recovery. If the IDC hosting the RW node is unavailable, the system automatically executes a disaster recovery switch to an RO node in another IDC, continuing to provide services without data loss (RPO = 0) and a fault recovery time of less than 8 seconds (RTO < 8s).
Three IDCs deployment (three-replica LogService)
Log Service supports three-replica deployment across three IDCs, ensuring IDC-level disaster recovery capabilities. Deploy one replica of Log Service in each of three different IDCs. If any one IDC is unavailable, Log Service can still provide services, ensuring log persistence and integrity.
Note
- Computing nodes (RW and RO) and Log Service are currently supported only for deployment within the same city.
- Computing nodes support deployment in a single IDC or multiple IDCs, while Log Service is supported only for three-replica deployment across three IDCs.