ODP routing

ODP allows you to access different servers of different tenants in different clusters through cluster routing, tenant routing, and intra-tenant routing. This topic describes the routing features of ODP in terms of cluster routing and tenant routing. For more information about intra-tenant routing, see Intra-tenant routing.

Cluster routing

Cluster routing allows you to access different clusters. The key to cluster routing is to obtain the mapping between a cluster name and an RS list.

• In the startup method in which the RS list is specified by using a startup parameter, the mapping between a cluster name and the RS list is also specified by using the startup parameter.

• In the startup method in which the obproxy_config_server_url parameter is specified in the startup command, the mapping between a cluster name and an RS list is obtained from the access URL.

Notice

The RS list does not need to contain all the cluster servers. ODP obtains the list of servers in a cluster from a view. Generally, the RS list contains servers where RootService is located.

As can be seen from the preceding figure, OceanBase Cloud Platform (OCP) is a key module in cluster routing. If there is an abnormality in the OCP module, the common problems are as follows:

• The service is unavailable: ODP fails to obtain the mapping between the cluster name and the RS list from OCP. As a result, logon fails.

• The returned result is incorrect: If ODP accesses OCP over HTTP to obtain a result, the obtained result is in the JSON format. If the format is incorrect, the result cannot be parsed correctly.

ODP obtains the RS list when you log on to access a cluster for the first time. ODP then saves the RS list to the memory. In subsequent accesses to the cluster, ODP directly obtain the RS list from the memory.

Notice

If an OCP issue occurs after the cluster memory information is created, you must troubleshoot the issue in a timely manner even if ODP still works properly.

Tenant routing

In OceanBase Database, a cluster has multiple tenants. The tenant routing feature of ODP allows you to access different tenants. Different from other tenants, the sys tenant is similar to an administrator tenant, and is related to cluster management. This section separately describes routing for the sys tenant and routing for a user tenant.

Routing for the sys tenant

After completing cluster routing, ODP obtains the RS list of the cluster. In this case, ODP logs on to a server in the RS list with the proxyro@sys account and obtains all the servers in the cluster from the DBA_OB_SERVERS view. In the implementation of OceanBase Database, the sys tenant is distributed on each node. Therefore, the result retrieved from the DBA_OB_SERVERS view is the routing information of the sys tenant.

ODP accesses the DBA_OB_SERVERS view every 15 seconds to maintain the latest routing information and to perceive node changes in the cluster.

In addition to the cluster server list, ODP also obtains information such as the partition distribution information, zone information, and tenant information from the sys tenant. Therefore, the sys tenant is crucial to ODP.

Routing for a user tenant

Unlike the routing information of the sys tenant, the routing information of a user tenant is about the servers where the tenant resources are located.

Notice

The routing information of a user tenant is not obtained from a unit-related table, but is obtained by using the special table name __all_dummy, which indicates a query for the tenant information. ODP obtains the server list of the tenant from the internal table __all_virtual_proxy_schema. For ODP to access the __all_virtual_proxy_schema table, you must specify the table name __all_dummy and the tenant name to obtain the node information of the tenant.

ODP stores the obtained tenant information in the local memory and updates the cache information according to certain strategies. For the sys tenant, ODP initiates a pull task every 15 seconds to obtain the latest information. For user tenants, ODP refreshes the routing cache in accordance with the following strategies:

• Creation: When you access a tenant for the first time, ODP accesses the __all_virtual_proxy_schema table to obtain the routing information of a user tenant and creates the routing cache.

• Eviction: ODP disables the cache when the OBServer returns the OB_TENANT_NOT_IN_SERVER error code.

• Update: ODP accesses the __all_virtual_proxy_schema table again to obtain the routing information of the user tenant when the cache is disabled.

In summary, in the multi-tenant architecture, ODP obtains metadata information from the sys tenant. The routing information of the sys tenant is a list of servers in the cluster. Then, ODP obtains the routing information of tenants from the metadata information. With the tenant routing feature, ODP supports the multi-tenant architecture of OceanBase Database.