Traffic distribution

In OceanBase Database, leaders handle read and write requests in transactions. Therefore, the distribution of partition leaders determines the how traffic is distributed across OBServer nodes.

Traffic

The database system provides support for data storage and querying in the application architecture. The read and write requests of an application are called database traffic. Database traffic is classified into write traffic, strongly consistent read traffic, and weakly consistent read traffic. Write traffic and strongly consistent read traffic are handled by leaders in OceanBase Database, while weakly consistent read traffic is handled by leaders and followers. To route database traffic, OceanBase Database Proxy (ODP) provides a SQL parser module that extracts details such as names, table names, and hints in SQL statements. Then, ODP forwards requests to the most appropriate OBServer node based on SQL statements, routing rules, and OBServer node status.

Primary zone

In OceanBase Database, primary zones determine the traffic distribution. This is achieved by specifying the preferred locations of leaders who handle the strongly consistent read and write traffic. For example, if the primary zone setting of the t1 table is primary_zone="Zone1", the Root Service schedules leaders of the t1 table to Zone1.

A primary zone is essentially a list of priority zones separated by semicolons (;).

For zones with the same priority, they are separated by commas (,). When multiple zones exist in the primary zone, zones with different priorities have different service levels. In contrast, zones with the same priority have the same service level, and traffic is distributed evenly among them.

For example, 'hz1,hz2;sh1,sh2;sz1' indicates that hz1 and hz2 have the same priority and higher priorities than sh1/sh2 and sz1. sh1 and sh2 have the same priority and higher priorities than sz1.

OceanBase Database v4.0 allows you to configure the primary zone only for tenants, but not for tables, databases, or table groups. If you do not specify primary_zone when you create a tenant, the default value RANDOM is used, which indicates that all zones have the same priority.

You can query the primary zone settings of tenants from the PRIMARY_ZONE field in the oceanbase.DBA_OB_TENANTS view of the system tenant. Example:

obclient> SELECT * FROM oceanbase.DBA_OB_TENANTS limit 10;
+-----------+-------------------------------------+-------------+----------------------------+----------------------------+-------------------+---------------------------------------------+-------------------+--------------------+--------+---------------+--------+
| TENANT_ID | TENANT_NAME                         | TENANT_TYPE | CREATE_TIME                | MODIFY_TIME                | PRIMARY_ZONE      | LOCALITY                                    | PREVIOUS_LOCALITY | COMPATIBILITY_MODE | STATUS | IN_RECYCLEBIN | LOCKED |
+-----------+-------------------------------------+-------------+----------------------------+----------------------------+-------------------+---------------------------------------------+-------------------+--------------------+--------+---------------+--------+
|         1 | sys                                 | SYS         | 2022-12-20 17:50:17.056814 | 2022-12-20 17:51:16.162367 | zone1;zone2;zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | NULL              | MYSQL              | NORMAL | NO            | NO     |
|      1001 | META$1002                           | META        | 2022-12-20 18:04:31.683655 | 2023-02-02 17:41:43.928347 | zone1;zone3       | FULL{1}@zone1, FULL{1}@zone3                | NULL              | MYSQL              | NORMAL | NO            | NO     |
|      1002 | mysql001                            | USER        | 2022-12-20 18:04:31.689731 | 2023-02-02 17:41:43.927293 | zone1;zone3       | FULL{1}@zone1, FULL{1}@zone3                | NULL              | MYSQL              | NORMAL | NO            | NO     |
|      1009 | META$1010                           | META        | 2022-12-26 18:28:38.055294 | 2022-12-26 18:29:01.184333 | zone1;zone2;zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | NULL              | MYSQL              | NORMAL | NO            | NO     |
|      1010 | oracle001                           | USER        | 2022-12-26 18:28:38.056350 | 2023-01-16 11:03:05.726746 | zone1;zone2;zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | NULL              | ORACLE             | NORMAL | NO            | NO     |
|      1053 | META$1054                           | META        | 2023-01-30 15:07:38.504077 | 2023-01-30 15:07:58.740958 | zone1;zone2,zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | NULL              | MYSQL              | NORMAL | NO            | NO     |
|      1054 | __recycle_$_100017_1675062478777896 | USER        | 2023-01-30 15:07:38.505138 | 2023-02-23 14:53:44.500219 | zone1;zone2,zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | NULL              | MYSQL              | NORMAL | YES           | NO     |
+-----------+-------------------------------------+-------------+----------------------------+----------------------------+-------------------+---------------------------------------------+-------------------+--------------------+--------+---------------+--------+

Region

In OceanBase Database, a zone is associated with a region attribute that specifies the geographic region it belongs to. You can query for regions corresponding to zones from the REGION field in the DBA_OB_ZONES view. A zone is associated with only one region, but multiple zones can belong to the same region. The primary zone plays a pivotal role in specifying the preferred scheduling region for the leader. It has the following implications:

• The primary zone is a preferred region to which the leader is to be scheduled.

• The region to which the primary zone belongs is a preferred region to which the leader is to be scheduled.

Specifically, the leader is first scheduled to the zone with the highest priority. If the replica in the zone with the highest priority cannot become the leader, the system preferentially schedule the leader to another zone in the same region. This helps to avoid cross-city access to OceanBase Database.

Rewrite the primary zone

OceanBase Database rewrites the value that you specified for the primary zone based on the regions of the zones. Rewriting rules:

1. List the regions corresponding to all zones in the primary zone list. For example, the primary zone list is hz1,hz2;sh1,sh2;sz1, and the corresponding primary region list is hz,hz;sh,sh;sz.

2. Remove repeated regions in the primary region list and reserve the regions that appear for the first time. Then the primary region list is changed from hz1,hz2;sh1,sh2;sz1 to hz;sh;sz.

3. Supplement the primary zone list based on the priorities of regions in the primary region list. Specifically, take out the zones corresponding to the regions from the primary zone list, and re-sort the zones. Zones in a region with a higher priority have higher priorities than those in a region with a lower priority. Priorities of zones in the same region follow the zone priorities in the original primary zone list.

Example: Assume that nine zones are available in total, where Zones sh1, sh2, and sh3 belong to Region SH, Zones hz1, hz2, and hz3 belong to Region HZ, and Zones sz1, sz2, and sz3 belong to Region SZ.

• The original primary zone list is 'sh1;hz1;hz2;sz1'. It is rewritten based on Rule 1 to obtain a primary region list: 'SH;HZ;HZ;SZ'. The primary region list is rewritten based on Rule 2 to obtain a new primary region list: 'SH;HZ;SZ'. The primary zone list obtained through rewriting based on Rule 3 is 'sh1;sh2,sh3;hz1;hz2;hz3;sz1;sz2,sz3'.

  Specifically:

  Region priorities are as follows: SH > HZ > SZ. Zones in Region SH have higher priorities than those in Regions HZ and SZ. Zones in Region HZ have higher priorities than those in Region SZ. Zone priorities in Region SH are as follows: sh1 > sh2 = sh3. Zone priorities in Region HZ are as follows: hz1 > hz2 > hz3. Zone priorities in Region SZ are as follows: sz1 > sz2 = sz3. The final primary zone list is 'sh1;sh2,sh3;hz1;hz2;hz3;sz1;sz2,sz3'. Leaders are preferentially scheduled to sh1. When sh1 fails, leaders are sequentially scheduled to sh2 and sh3 based on the preceding priorities.

• The original primary zone list is 'sh1,sh2;hz1;hz2;sz1';. It is rewritten based on Rule 1 to obtain a primary region list: 'SH,SH;HZ;HZ;SZ'. The primary region list is rewritten based on Rule 2 to obtain a new primary region list: 'SH;HZ;SZ'. The final primary zone list obtained through rewriting based on Rule 3 is 'sh1,sh2;sh3;hz1;hz2;hz3;sz1;sz2,sz3'.

  Specifically:

  Region priorities are as follows: SH > HZ > SZ. Zones in Region SH have higher priorities than those in Regions HZ and SZ. Zones in Region HZ have higher priorities than those in Region SZ. Zone priorities in Region SH are as follows: sh1 = sh2 > sh3. Zone priorities in Region HZ are as follows: hz1 > hz2 > hz3. Zone priorities in Region SZ are as follows: sz1 > sz2 = sz3. The final primary zone list is 'sh1,sh2;sh3;hz1;hz2;hz3;sz1;sz2,sz3'. Leaders are preferentially evenly distributed in sh1 and sh2. When sh1 and sh2 fail, leaders are preferentially scheduled to sh3 based on the preceding priorities.

• The original primary zone list is 'sh1,hz1;hz2;sz1';. It is rewritten based on Rule 1 to obtain a primary region list: 'SH,HZ;HZ;SZ'. The primary region list is rewritten based on Rule 2 to obtain a new primary region list: 'SH,HZ;SZ'. The final primary zone list is obtained through rewriting based on Rule 3: 'sh1,hz1;hz2;sh2,sh3,hz3;sz1;sz2,sz3'.

  Specifically:

  Region priorities are as follows: SH = HZ > SZ. Zones in Regions SH and HZ have higher priorities than those in Region SZ. Zone priorities are as follows: sh1 = hz1 > hz2 > sh2 = sh3 = hz3 > sz1 > sz2 = sz3. The final primary zone list is 'sh1,hz1;hz2;sh2,sh3,hz3;sz1;sz2,sz3'. Leaders are preferentially evenly distributed in sh1 and hz1. When sh1 and hz1 fail, leaders are preferentially scheduled to hz2 based on the preceding priorities.