Strategy-based routing

This topic describes the concepts related to strategy-based routing and provides two examples to describe how to configure strategy-based routing.

Concepts

This section describes concepts related to strategy-based routing, such as logical data center (LDC), routing strategy, and routing type.

LDC

LDC-based routing can resolve the issue of latency caused by remote routing when multiple Internet data centers (IDCs) are deployed across multiple regions in a distributed relational database.

As a typical high-availability distributed relational database system, OceanBase Database uses the Paxos protocol for log synchronization. OceanBase Database natively supports multi-region and multi-IDC deployment to ensure high disaster tolerance and reliability. However, every database deployed across multiple regions and IDCs has a latency issue caused by routing. OceanBase Database provides the LDC routing feature to address this issue. If the region and IDC attributes are specified for each zone in an OceanBase cluster and the IDC name attribute is specified for OceanBase Database Proxy (ODP), when a data request is sent to ODP, ODP selects an OBServer node in the following sequence: an OBServer node in the same IDC, an OBServer node in the same region, and a remote OBServer node.

Routing strategy

ODP performs routing based on rules defined in the routing strategy in the following cases:

• Weak-consistency reads

• Strong-consistency reads based on the primary zone

• Partition calculation failure in the case of strong-consistency reads to partitioned tables

In strategy-based routing of ODP, the logical priorities of OBServer nodes are determined by the routing strategy. You can specify a routing strategy by using the ODP parameter proxy_route_policy or the user variable @proxy_route_policy. The following routing strategies are supported:

• FOLLOWER_FIRST: Read requests are first routed to followers, and are routed to the leader only when no follower is available.

• FOLLOWER_ONLY: Read requests are routed only to followers. If no follower is available, an error is returned.

• UNMERGE_FOLLOWER_FIRST: Read requests are preferentially routed to followers not in a major compaction.

• TARGET_REPLICA_TYPE_WITH_LEADER: Read requests are routed to specified replicas. In this strategy, the leader and followers have the same priority. The replica type is specified by route_target_replica_type.

• TARGET_REPLICA_TYPE_FOLLOWER_FIRST: Read requests are routed to specified replicas and to followers preferentially. If all specified followers are unavailable, read requests are routed to the leader. The replica type is specified by route_target_replica_type.

• TARGET_REPLICA_TYPE_FOLLOWER_ONLY: Read requests are routed to specified followers. If all specified followers are unavailable, the connection to the client is terminated. The replica type is specified by route_target_replica_type.

• WEAKREAD_WEIGHT_LOAD_BALANCE: Load-balanced routing is performed based on weights. You can use specify the weakread_weight_zone parameter to set a weight for each zone in the cluster.

For more information about route_target_replica_type, see route_target_replica_type. For more information about weakread_weight_zone, see weakread_weight_zone.

Routing type

A routing strategy is a collection of logical priorities and consists of multiple routing types. A routing type consists of five dimension attributes of replicas.

• Paxos type: LEADER and FOLLOWER

• Partitioned table type: PARTITION and NONPARTITION

• Zone type: READWRITE and READONLY

• Major compaction status of SSTable: UNMERGE and MERGE

• Geographic location: LOCAL, REGION, and REMOTE

• Replication table replica: DUP and -

For example, priorities in the FOLLOWER_FIRST routing strategy are arranged in descending order as follows:

• FOLLOWER_PARTITION_UNMERGE_LOCAL: follower, partition replica, merged, same rack

• FOLLOWER_PARTITION_UNMERGE_REGIO: follower, partition replica, merged, same region

• FOLLOWER_PARTITION_MERGE_LOCAL: follower, partition replica, merging, same rack

• FOLLOWER_PARTITION_MERGE_REGION: follower, partition replica, merging, same region

• LEADER_PARTITION_UNMERGE_LOCAL: leader, partition replica, merged, same rack

• LEADER_PARTITION_UNMERGE_REGIO: leader, partition replica, merged, same region ...

Use strategy-based routing

The procedure for using strategy-based routing is as follows:

1. Configure an LDC for an OceanBase cluster.

2. Configure the instance-level parameter proxy_idc_name of ODP.

   Notice

   If proxy_idc_name is left empty, LDC-based routing will fail.

3. Configure the instance-level parameter proxy_route_policy of ODP for more fine-grained priority control. If you only need to control the routing to a zone or IDC, you can skip this configuration step. If this parameter is not configured, ODP uses the default routing strategy MERGE_IDC_ORDER.

4. Initiate a read request.

Example 1: Route to the specified IDC

Step 1: Configure the IDCs of an OceanBase cluster

Log in to the OceanBase cluster as the root@sys user and execute the following statements to configure the LDC of the cluster. In this example, the cluster has three zones and each zone contains one OBServer node.

Configure the region of z1. The parameter REGION specifies the region where the zone resides and is usually set to a city name, which is case-sensitive.

obclient [oceanbase]> ALTER SYSTEM MODIFY ZONE "z1" SET REGION = "SHANGHAI"; 

Configure the IDC where z1 resides. The IDC parameter specifies the IDC where the zone resides and is usually set to an IDC name, which is in lowercase.

obclient [oceanbase]> ALTER SYSTEM MODIFY ZONE "z1" SET IDC = "zue";

The following table lists the configurations of the cluster.

Step 2: Configure the ODP parameter

Configure the proxy_idc_name parameter to specify the location of ODP in the LDC. This example assumes that all weak-consistency read requests are routed to z1. Execute the following statement to set proxy_idc_name to zue:

obclient [oceanbase]> ALTER PROXYCONFIG SET PROXY_IDC_NAME ='zue';

Step 3: Initiate a read request

1. Create a table named t1 and initiate a weak-consistency read request.

   obclient [test]> SELECT /*+READ_CONSISTENCY(WEAK) */ * FROM test.t1;
   

2. Execute the EXPLAIN ROUTE statement to view the routing process in ODP.

   obclient [test]> EXPLAIN ROUTE SELECT /*+READ_CONSISTENCY(WEAK) */ * FROM test.t1\G
   

   In the following return result, the idc_type value is SAME_IDC, which indicates that the replica is in the same IDC as ODP, that is, z1.

   *************************** 1. row ***************************
   ...
   Route Plan
   -----------------
   > SQL_PARSE:{cmd:"COM_QUERY", table:"t1"}
   > ROUTE_INFO:{route_info_type:"USE_PARTITION_LOCATION_LOOKUP"}
     > TABLE_ENTRY_LOOKUP_DONE:{table:"t1", table_id:500006, table_type:"USER TABLE", entry_from_remote:false}
   > ROUTE_POLICY:{replica:"10.10.10.1:50109", idc_type:"SAME_IDC", zone_type:"ReadWrite", role:"LEADER", type:"FULL", is_partition_server:true, chosen_route_type:"ROUTE_TYPE_PARTITION_UNMERGE_LOCAL", route_policy:"MERGE_IDC_ORDER", trans_consistency:"WEAK", session_consistency:"STRONG", proxy_idc_name:"zue"}
   > CONGESTION_CONTROL:{svr_addr:"10.10.10.1:50109"}
   

Example 2: Route to followers in the specified IDC

Step 1: Configure an OceanBase cluster

Log in to the OceanBase cluster as the root@sys user and execute the following statements to configure the LDC of the cluster. In this example, the cluster has three zones and each zone contains one OBServer node.

Configure the region of z1. The parameter REGION specifies the region where the zone resides and is usually set to a city name, which is case-sensitive.

obclient [oceanbase]> ALTER SYSTEM MODIFY ZONE "z1" SET REGION = "SHANGHAI"; 

Configure the IDC where z1 resides. The IDC parameter specifies the IDC where the zone resides and is usually set to an IDC name, which is in lowercase.

obclient [oceanbase]> ALTER SYSTEM MODIFY ZONE "z1" SET IDC = "zue";

Create a table named t1 and execute the following statement to view the leader and followers of the table:

obclient [oceanbase]> select * from oceanbase.DBA_OB_TABLE_LOCATIONS where DATABASE_NAME='test' and TABLE_NAME like 't1'\G

The following table lists the configurations of the cluster.

Step 2: Configure the ODP parameter

Configure the proxy_idc_name parameter to specify the location of ODP in the LDC. Configure the proxy_route_policy parameter to specify the routing strategy. This example assumes that all weak-consistency read requests are routed to a follower in the same IDC. Here are the sample statements:

obclient [oceanbase]> ALTER PROXYCONFIG SET PROXY_IDC_NAME ='zue';
obclient [oceanbase]> ALTER PROXYCONFIG SET proxy_route_policy = FOLLOWER_FIRST;

Step 3: Initiate a read request

Execute the EXPLAIN ROUTE statement to view the routing process in ODP.

obclient [oceanbase]> EXPLAIN ROUTE SELECT /*+READ_CONSISTENCY(WEAK) */ * FROM test.t1\G

In the following return result, the idc_type value is SAME_IDC, which indicates that the replica is in the same IDC as ODP, and the role value is FOLLOWER, which indicates that the request is routed to a follower.

...
Route Plan
-----------------
> SQL_PARSE:{cmd:"COM_QUERY", table:"t1"}
> ROUTE_INFO:{route_info_type:"USE_PARTITION_LOCATION_LOOKUP"}
  > TABLE_ENTRY_LOOKUP_DONE:{table:"t1", table_id:500006, table_type:"USER TABLE", entry_from_remote:false}
> ROUTE_POLICY:{replica:"10.10.10.2:50110", idc_type:"SAME_IDC", zone_type:"ReadWrite", role:"FOLLOWER", type:"FULL", is_partition_server:true, chosen_route_type:"ROUTE_TYPE_FOLLOWER_PARTITION_UNMERGE_LOCAL", route_policy:"FOLLOWER_FIRST", trans_consistency:"WEAK", session_consistency:"STRONG", proxy_idc_name:"zue"}
> CONGESTION_CONTROL:{svr_addr:"10.10.10.2:50110"}