Traffic distribution

In OceanBase Database, leaders handle read and write requests in transactions. Therefore, the distribution of partition leaders determines the distribution of traffic on 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, strong-consistency read traffic, and weak-consistency read traffic. Write traffic and strong-consistency read traffic are handled by leaders in OceanBase Database, while weak-consistency 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 database 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 strong-consistency read and write traffic. For example, if the primary zone setting of the t1 table is primary_zone="Zone1", the RootService schedules leaders of the t1 table to Zone1.

The primary zone is essentially a list of zones. The list specifies zone priorities in the following way:

If the primary zone list contains multiple zones, the zones with different priorities are separated with semicolons (;), and those with the same priority are separated with commas (,). For zones with the same priority, traffic is distributed in the zones and all these zones provide services at the same time.

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

The current version of OceanBase Database supports only tenant-level primary zones and no longer supports table-level, database-level, or table group-level primary zones. 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 column in the oceanbase.DBA_OB_TENANTS view of the sys tenant. Here is an 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 | TENANT_ROLE | SWITCHOVER_STATUS | SWITCHOVER_EPOCH | SYNC_SCN            | REPLAYABLE_SCN      | READABLE_SCN        | RECOVERY_UNTIL_SCN  | LOG_MODE     | ARBITRATION_SERVICE_STATUS |
+-----------+-------------+-------------+----------------------------+----------------------------+--------------+---------------+-------------------+--------------------+--------+---------------+--------+-------------+-------------------+------------------+---------------------+---------------------+---------------------+---------------------+--------------+----------------------------+
|         1 | sys         | SYS         | 2023-05-17 18:10:19.940353 | 2023-05-17 18:10:19.940353 | RANDOM       | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 |                NULL |                NULL |                NULL |                NULL | NOARCHIVELOG | DISABLED                   |
|      1001 | META$1002   | META        | 2023-05-17 18:15:21.455549 | 2023-05-17 18:15:36.639479 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 |                NULL |                NULL |                NULL |                NULL | NOARCHIVELOG | DISABLED                   |
|      1002 | mysql001    | USER        | 2023-05-17 18:15:21.461276 | 2023-05-17 18:15:36.669988 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 | 1684398681521302749 | 1684398681521302749 | 1684398681345969089 | 4611686018427387903 | NOARCHIVELOG | DISABLED                   |
|      1003 | META$1004   | META        | 2023-05-17 18:18:19.927859 | 2023-05-17 18:18:36.443233 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 |                NULL |                NULL |                NULL |                NULL | NOARCHIVELOG | DISABLED                   |
|      1004 | oracle001   | USER        | 2023-05-17 18:18:19.928914 | 2023-05-17 18:18:36.471606 | zone1        | FULL{1}@zone1 | NULL              | ORACLE             | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 | 1684398681335427475 | 1684398681335427475 | 1684398681144712832 | 4611686018427387903 | NOARCHIVELOG | DISABLED                   |
|      1005 | META$1006   | META        | 2023-05-18 15:48:57.441320 | 2023-05-18 15:49:12.820051 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 |                NULL |                NULL |                NULL |                NULL | NOARCHIVELOG | DISABLED                   |
|      1006 | mq_t1       | USER        | 2023-05-18 15:48:57.447657 | 2023-05-18 15:49:12.857944 | zone1        | FULL{1}@zone1 | NULL              | MYSQL              | NORMAL | NO            | NO     | PRIMARY     | NORMAL            |                0 | 1684398680916392609 | 1684398680916392609 | 1684398680742451346 | 4611686018427387903 | NOARCHIVELOG | DISABLED                   |
+-----------+-------------+-------------+----------------------------+----------------------------+--------------+---------------+-------------------+--------------------+--------+---------------+--------+-------------+-------------------+------------------+---------------------+---------------------+---------------------+---------------------+--------------+----------------------------+
7 rows in set

Region

In OceanBase Database, each zone has a region attribute, which indicates the region to which the zone belongs. You can query for regions corresponding to zones from the REGION column in the DBA_OB_ZONES view. You can configure only one region for each zone. Multiple zones can belong to the same region. The primary zone indicates a preferred region for scheduling the leader. Therefore, setting the primary zone has the following meanings:

• 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 preferentially scheduled to the zone with the highest priority. If the replica in the zone with the highest priority cannot become the leader, the leader is preferentially scheduled to another zone in the same region, to avoid cross-city access to OceanBase Database.

Rewrite the primary zone

OceanBase Database rewrites the value that you specified for the primary_zone parameter based on the regions of the zones. The rewriting rules are as follows:

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.

For 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.