OceanBase Database Proxy (ODP), also known as OBProxy, is a proxy service for OceanBase Database. ODP is equipped with high availability (HA) design.
ODP deployment modes
Merged deployment
Boot in OCP
ODP can access multiple clusters.
When OceanBase Cloud Platform (OCP) is down, ODP can still access the clusters that have been accessed but cannot access the clusters that have not been accessed.
Boot based on the RootService list (Only access to a single cluster is allowed by using the IP address 127.0.0.1.)
ODP accesses a fixed cluster that is independent of OCP. If the local server fails, the server load balancer (SLB) detects the failure and performs traffic switchover without the need for additional operations of ODP.
Server failures in specific scenarios can be handled.
Independent deployment
Boot in OCP
ODP can access multiple clusters.
When OCP is down, ODP can still access the clusters that have been accessed but cannot access the clusters that have not been accessed.
Boot based on the RootService list
- ODP accesses a fixed cluster that is independent of OCP. If an error occurs with the RootService list, the cluster may become inaccessible.
ODP disaster recovery
Failure detection
Schedule tasks to refresh the status of the OBServer nodes, zones, and primary/standby cluster.
- Limitations: This solution depends on the status updates of the OBServer nodes. When an OBServer node is down, for example, when its disk is unresponsive, the OBServer node may not become inactive or be stopped. In this case, the status of the OBServer node does not change.
Implement the server persistent connection and keepalive mechanisms to check the connections between ODP and backend OBServer nodes. This way, ODP can identify the situation where an idle connection is abnormally closed at the earliest opportunity, release the connection, and establish a new one.
Implement the client keepalive mechanism to check the connections between ODP and clients to avoid timeout errors of idle SLBs.
Failure handling
Processing of ongoing requests
Implement the asynchronous termination mechanism. When an OBServer node failure is detected, the connection is promptly terminated to avoid a long waiting period and prevent the service connection pool from being exhausted.
Processing of new requests
Use the blocklist to avoid sending new requests to a failed OBServer node.
An OBServer node with multiple access failures is blocklisted. After an OBServer node is blocklisted for a period of time, a detection request is sent to this OBServer node to check whether it becomes accessible.
Limitations: If a client times out and disconnects from an OBServer node, the OBServer node is not blocklisted.
If the status of the OBServer node changes to inactive, the OBServer node is blocklisted.
Limitations: The recovery time objective (RTO) depends on the OBServer node detection time and the interval at which a scheduled task is triggered to refresh the status of the OBServer node. The default interval is 20s. You can also specify a custom interval.
Asynchronously refresh the table location cache to detect replica switchover operations. If a replica switchover operation is performed upon a server failure, requests are routed to the new replica.
Limitations: The OBServer node must notify ODP of routing failures. If the OBServer node fails and does not return routing information, the table location cache is not refreshed.
Adopts the primary/standby cluster architecture for two IDCs in the Physical Standby Database solution. If the primary cluster is changed, ODP can switch to the new primary cluster efficiently.
Limitations: The RTO depends on the OBServer node switchover time and the interval at which a scheduled task is triggered to refresh the status of the OBServer node. The default interval is 20s. You can also specify a custom interval.