This topic describes the concepts of the OceanBase Cloud database proxy service.
Background information
The database proxy of OceanBase Cloud sits between the client and the OceanBase Cloud database, receiving client requests and forwarding them to the backend database. It ensures optimal routing to minimize distributed transactions and enhances the high availability of OceanBase Cloud databases by preventing application impact from single-server failures in multi-replica environments.
The OceanBase Cloud database proxy offers features such as connection management, optimal routing, high-performance forwarding, easy maintenance, high availability, and proprietary protocols. The following table describes some of the key concepts:
Term |
Description |
|---|---|
| Proxy endpoint | The proxy endpoint is at the core of the database proxy. It supports customizable access strategies, allowing you to modify endpoint prefixes, port numbers, etc. Connecting to RDS instances through the database proxy endpoint enables you to utilize advanced proxy features. |
| Connection management | For each client's physical connection, the database proxy maintains its connections to multiple backend OBServer nodes. It uses a version-based incremental synchronization method to maintain session states for each OBServer node, ensuring efficient client access to all OBServer nodes. |
| Optimal routing | The database proxy considers factors such as replica locations, user-configured read/write separation routing strategies, optimal links for OceanBase's multi-region deployments, and the status and load of each OceanBase server. This enables the proxy to route requests to the best OBServer node, ensuring the high-performance operation of OceanBase. |
| High-performance forwarding | The database proxy is fully compatible with the MySQL protocol and supports OceanBase's proprietary protocol. It employs a multi-threaded asynchronous framework and transparent stream forwarding design to ensure high-performance data forwarding while minimizing its resource consumption. |
| Easy maintenance | The database proxy is stateless and supports unlimited horizontal scaling, allowing it to access multiple OceanBase instances simultaneously. You can monitor the status of the database proxy in real-time through the OceanBase Cloud console, making maintenance simple and convenient. |
| High availability | The high availability of the database proxy is twofold: it ensures its own high availability to continuously provide proxy services, and it is a key component of OceanBase's high availability system. It shields users from downtime, upgrades, and other disruptions, ensuring stable and fast recovery of OceanBase database services. |
| Proprietary protocol | The database proxy communicates with OBServer nodes using OceanBase's proprietary protocol, which includes enhanced features such as CRC checks for data packet integrity and support for Oracle-compatible data types and interaction models. |
Proxy specification types
OceanBase Cloud provides two tiers of database proxy service: Shared and Exclusive.
Shared: The database proxy service instance shares compute resources with other customers. The size of the database proxy instance is fixed based on the actual size of the instance. This type is suitable for businesses with relatively fixed and average traffic.
Exclusive: The database proxy service instance exclusively occupies compute resources. You can expand the database proxy resources as needed based on your business requirements. This type is suitable for businesses with high traffic. The exclusive proxy service is billed by the hour based on the resources you use.
The following table describes the features and differences of the two types:
Feature |
Shared |
Exclusive |
|---|---|---|
| Billing type | Free | Pay-as-you-go |
| Resource type | Shared CPU physical resources | Exclusive CPU physical resources with more stable performance. |
| Deployment architecture | High-availability cluster deployment architecture to ensure smooth failover. | High-availability cluster deployment architecture to ensure smooth failover. |
| Instance specifications | Supports 2C to 8C | Supports 2C to 64C |
| Read/write separation | Supported | Supported |
| Transaction splitting | Supported | Supported |
| Connection keep-alive | Supported | Supported |
| Seamless scaling | Supported. The proxy automatically switches to the new specification nodes during scaling. | Supported. The proxy automatically switches to the new specification nodes during scaling. |
| SSL encryption | Supported | Supported |
Serverless database proxy cluster
Notice
The Serverless Database Proxy Cluster is currently in public beta and supports only the AWS channel. Support for other clouds will be added later.
About Serverless database proxy clusters
ODP Serverless is the serverless version of OceanBase Database Proxy. It automatically adjusts the computing resources of ODP based on the actual load of business traffic, eliminating the need for manual cluster specification planning. ODP Serverless is suitable for business scenarios with large load fluctuations and unpredictable traffic peaks and troughs, such as major promotions on e-commerce platforms, SaaS multi-tenant services, and scheduled reporting tasks.
Unlike the Serverless Database Proxy Cluster, a database proxy that uses Shared or Exclusive specifications requires you to set the proxy cluster specifications manually and then manually scale the cluster up or down when resources are insufficient or underutilized. This type is suitable for workloads with relatively stable traffic or when you want to reserve a fixed amount of compute resources for the proxy cluster.
Except for elastic scaling, the Serverless Database Proxy Cluster does not differ from non-serverless proxy clusters in disaster recovery, connection limits, or other attributes.
Serverless database proxy cluster pricing
ODP Serverless is currently free. After enabling ODP Serverless, you do not need to pay any additional fees for its elastic computing capability or proxy cluster specifications. Note that although ODP Serverless itself is free, you still need to pay cross-zone traffic fees for private network requests on AWS.
Elastic scaling mechanism
ODP Serverless combines burst load detection with a vertical elastic resource recommendation mechanism to continuously assess the resource requirements of a proxy cluster. When the system determines over multiple consecutive detection cycles that the current specification cannot meet the business load, it automatically triggers a scale-up, gradually increasing the proxy cluster's CPU and memory specifications. After each adjustment, the system re-evaluates the resource pressure; if the current specification is still insufficient, it continues to scale up until the proxy cluster returns to a reasonable and stable operational level.
Initial proxy cluster specification (base capacity)
The initial specification of a Serverless proxy cluster equals the tenant specification × number of units × 1/4. For example, if the tenant specification is 4C and the number of units is 2, the initial specification of the Serverless proxy cluster is 4C × 2/4 = 2C.
Proxy cluster elastic scaling limits (maximum and minimum capacity)
The maximum CPU specification allowed for automatic scaling up under sudden traffic and the minimum CPU specification maintained during off-peak traffic. The elastic upper limit equals 1/4 of the specification for a full-featured replica node in OceanBase. For example, for an OceanBase cluster deployed in 16C across multiple IDCs with a 2-2-2 configuration, the elastic upper limit for a single Serverless proxy cluster is 16C × 6/4 = 24C. The elastic lower limit is 1C.
Impact of elastic scaling on client connections
Generally, the Serverless Database Proxy Cluster uses in-place scaling to increase or decrease node specifications, so scaling has no impact on client connections. In rare cases, non-in-place scaling may occur, involving the creation and deletion of proxy cluster nodes. Connections on the deleted database proxy nodes will be interrupted. For this scaling method, we will send an email and an in-app notification three days in advance to inform you of the node deletion time, allowing you to contact us to modify the time. It is recommended that you configure an automatic retry mechanism for clients to avoid connection interruptions caused by non-in-place scale-ups.