Database connections are categorized into physical connections and logical connections. Physical connections refer to network connections, and logical connections refer to sessions between OceanBase Database Proxy (ODP) and OceanBase Database.
As an important feature of OceanBase Database, routing enables quick data access in a distributed architecture.
A partition is a basic unit of data storage in OceanBase Database. After a table is created, mappings between the table and its partitions are generated. If the primary/standby mode is not adopted, a non-partitioned table maps to one partition. A partitioned table maps to multiple partitions.
Based on the routing feature, a query can be accurately routed to the OBServer node where the desired data is located. In addition, a read request without high consistency requirements can be routed to an OBServer node where a replica is located. This maximizes the usage of server resources. During the routing process, SQL statements, configuration rules, and OBServer node status are used as the input, and an available OBServer node IP address is generated as the output. The following figure shows the routing logic.
The custom parser module of ODP is used to parse SQL statements. ODP needs only to parse the database names, table names, and hints in DML statements. No complex expression analysis is required.
ODP needs to determine the optimal routing rule based on different conditions. DML requests for strong consistency read are routed to the OBServer node where the leader is located, whereas DML requests for weak consistency read and other requests are evenly distributed to the OBServer nodes where the leader and followers are located. If an OceanBase cluster is deployed across regions, ODP provides logical data center (LDC) routing to preferentially route requests to an OBServer node in the same IDC, then an OBServer node in the same city, and finally an OBServer node in a different city. If the OceanBase cluster adopts the read-write splitting mode, ODP provides rules of RZone-first read, RZone-only read, and non-major-compaction-first read. You can set these rules based on your business needs. In practice, the previous rules can be combined to generate a specific routing rule.
Based on the request SQL statements of a user, ODP obtains the IP address of the OBServer node where the corresponding replica is located. ODP attempts to obtain the route table first from the local cache, then from the global cache, and finally from the OBServer node by initiating an asynchronous query task. ODP uses the trigger mechanism to update the route table. ODP forwards requests to OBServer nodes based on the route table. If a request cannot be locally processed by an OBServer node, the OBServer node places the feedback in the response packet and sends the packet to ODP. ODP determines whether to forcibly update the route table in the local cache based on the feedback. Generally, the route table changes only when an OBServer node undergoes a major compaction or when leader switching is caused by load balancing.
ODP selects an OBServer node from the route table based on the determined routing rule in the previous step and forwards requests to the OBServer node after this OBServer node passes the blocklist and graylist checks.