Overview
Routing strategies help ODP select a suitable replica for SQL statements. The multiple replicas can be the multiple replicas selected during follower routing or during tenant server routing for statements such as select 1 from dual.
ODP implements three types of routing strategies:
Primary zone-based routing, which takes the top priority
LDC-based routing, which takes the second priority
Random routing, which takes the third priority
Primary zone-based routing
ODP sends an SQL request preferentially to the server where the primary zone is located. The zone where the leader is located is called the primary zone. Adopt this routing strategy in the following scenarios:
In the high-performance deployment architecture commonly used for OceanBase Database, the primary zone of a tenant is deployed on one server. This mechanism reduces network overheads for a distributed system.
During leader routing, ODP may fail to get the table name or calculate the partition ID. In this case, ODP can adopt this routing strategy to send the requests to the leader as far as possible.
LDC-based routing
LDC-based routing is a routing strategy based on location information, which includes the following attributes:
IDC: indicates a logical data center.
Region: indicates a city.
Both ODP and OBServers can set the LDC information. Based on the LDC information, ODP can determine the location relationship with an OBServer. After the LDC information is specified, ODP adopts LDC-based routing by default.
LDC settings for an OBServer
You can set the Region or IDC attribute for each zone of an OBServer. The Region attribute is usually set to the city name, which is case-sensitive. The IDC attribute specifies the data center where the zone is located. Generally, the data center name in lowercase is specified for the IDC attribute. The SQL statement is as follows:
alter system modify zone "z1" set region = "SHANGHAI";
alter system modify zone "z1" set idc = "zue";
Return result:
mysql> select * from DBA_OB_ZONES;
+-------+----------------------------+----------------------------+--------+-----+----------------+-----------+
| ZONE | CREATE_TIME | MODIFY_TIME | STATUS | IDC | REGION | TYPE |
+-------+----------------------------+----------------------------+--------+-----+----------------+-----------+
| z1 | 2022-10-31 11:48:29.040552 | 2022-10-31 11:48:29.041609 | ACTIVE | zue | SHANGHAI | ReadWrite |
+-------+----------------------------+----------------------------+--------+-----+----------------+-----------+
| z2 | 2022-10-31 11:48:29.040552 | 2022-10-31 11:48:29.041609 | ACTIVE | zue | SHANGHAI | ReadWrite |
+-------+----------------------------+----------------------------+--------+-----+----------------+-----------+
| z3 | 2022-10-31 11:48:29.040552 | 2022-10-31 11:48:29.041609 | ACTIVE | ztg | HANGZHOU | ReadOnly |
+-------+----------------------------+----------------------------+--------+-----+----------------+-----------+
3 rows in set
LDC settings for ODP
You can configure LDC settings for ODP in one of the following ways. In this example, the sample zue IDC is used.
Set the LDC parameters when you start the obproxy process. This is the recommended method. Sample code:
cd /opt/taobao/install/obproxy ./bin/obproxy -o proxy_idc_name=zueExecute the ALTER statement on a support client tool to modify the ODP settings. Sample statement:
mysql> alter proxyconfig set proxy_idc_name='zue';
Run the internal command show proxyinfo idc; of ODP to check the LDC configuration for ODP.
mysql> show proxyinfo idc;
+-----------------+--------------+-----------------+-----------------+--------------------------------------------------------+-------------+--------------------+
| global_idc_name | cluster_name | match_type | regions_name | same_idc | same_region | other_region |
+-----------------+--------------+-----------------+-----------------+--------------------------------------------------------+-------------+--------------------+
| zue | obcluster | MATCHED_BY_NONE | [] | [[0]"z1", [1]"z1", [2]"z2", [3]"z2", [4]"z3", [5]"z3"] | [] | [] |
+-----------------+--------------+-----------------+-----------------+--------------------------------------------------------+-------------+--------------------+
| zue | obcluster | MATCHED_BY_IDC | [[0]"SHANGHAI"] | [[0]"z1", [1]"z1", [2]"z2", [3]"z2"] | [] | [[0]"z3", [1]"z3"] |
+-----------------+--------------+-----------------+-----------------+--------------------------------------------------------+-------------+--------------------+
| zue | obcluster | MATCHED_BY_IDC | [[0]"SHANGHAI"] | [[0]"z1", [1]"z1", [2]"z2", [3]"z2"] | [] | [[0]"z3", [1]"z3"] |
+-----------------+--------------+-----------------+-----------------+--------------------------------------------------------+-------------+--------------------+
3 rows in set
Note
If OceanBase Database is deployed in only one IDC, the LDC information is of little use, because the latency among servers in the same IDC is the same by default. If you still want to adopt the LDC-based routing strategy in this case, plan the LDC architecture, and set the LDC attributes for both the OBServer and ODP. If OceanBase Database is deployed across multiple IDCs, you can plan the LDCs based on the IDCs and city.
In some special cases, you can specify LDC settings by using the trick method to enable LDC-based routing. However, we do not recommend you do that.
Random routing
ODP adopts the random routing strategy when multiple replicas are still available for selection after the primary zone-based routing and LDC-based routing. If primary zone-based routing is not enabled or LDC-based routing is not configured, ODP directly uses random routing.
Configure and view routing strategies
Data routing is complex because different routing strategies are available. By default, ODP first perform leader routing and follower routing, and performs tenant server routing if no replica is available. If only one replica is selected, ODP directly routes the data to the replica. Otherwise, ODP routes the data based on routing strategies.
Primary zone-based routing and LDC-based routing are controlled by the following parameters:
enable_primary_zone: specifies whether to use the primary zone-based routing strategy. The valuetrueindicates to use primary zone-based routing.proxy_idc_name: specifies the name of the IDC. LDC-based routing is used when this parameter is specified.
If you want to use routing strategies other than the existing ones, you can modify the proxy_route_policy parameter to set the new strategy with the top priority. The following two routing strategies are frequently used, which are both related to weak reading.
FOLLOWER_FIRST: Requests are first routed to a follower, and are routed to the leader only when no follower is available.FOLLOWER_ONLY: Requests are routed only to a follower. If no follower is available, an error is returned.
You can query the route_type field in ODP logs for the routing strategies used by ODP. For example, ROUTE_TYPE_LEADER indicates that leader routing is used. ROUTE_TYPE_NONPARTITION_UNMERGE_LOCAL indicates a more complex situation. The keywords are described as follows:
PARTITON: indicates to select a server with replica data, regardless of the replica type.NONPARTITION: indicates to select a tenant server regardless of the table data distribution.FOLLOWER: indicates to send the request to a follower.LEADER: indicates to send the request to the leader.UNMERGE: indicates to send the request to a server not in the progress of major compaction.MERGE: indicates to send the request to a server in the progress of major compaction.LOCAL: indicates to send the request to a server in the same IDC.REMOTE: indicates to send the request to a server in a different IDC in the same city.REGION: indicates to send the request to a server in another city.READONLY: indicates to send the request to a server in a READONLY zone.READWRITE: indicates to send the request to a server in a READWRITE zone.DUP: indicates to send the request to a server where the replicated table is located.