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, and weak-consistency read traffic is handled by leaders and followers. OceanBase Database Proxy (ODP) supports routing for database traffic. ODP provides a simple SQL parser module. The SQL parser module obtains database names, table names, and hints in SQL statements through parsing, and forwards the request to the most appropriate OBServer node based on the business 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. Assume that the primary zone of the t1 table is Zone1. 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, the value 'hz1,hz2;sh1,sh2;sz1' indicates that the hz1 and hz2 zones have the same priority and a higher priority than the sh1, sh2, and sz1 zones. Similarly, the sh1 and sh2 zones have the same priority and a higher priority than the sz1 zone.

OceanBase Database supports only tenant-level primary zones in the current version and no longer supports table-, database-, or table group-level primary zones. If you do not specify primary_zone when you create a tenant, the default value is RANDOM, which indicates that all zones have the same priority.

You can query the PRIMARY_ZONE field in the oceanbase.DBA_OB_TENANTS view of the sys tenant for the primary zone attributes of a 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 the REGION field in the DBA_OB_ZONES view for regions corresponding to zones. You can configure only one region for each zone. Multiple zones can belong to the same region. The primary zone setting indicates the preferred regions for scheduling the leaders. Therefore, setting the primary zone attribute has the following meanings:

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

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

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-region access to OceanBase Database.

Rewrite the primary zone setting

OceanBase Database rewrites the value that you specified for the primary_zone parameter based on the regions of the zones. The following rules are applied to rewrite the value:

1. List the regions corresponding to all zones in the primary zone setting. For example, if the value of the primary_zone parameter is hz1,hz2;sh1,sh2;sz1, the corresponding value of the primary_region parameter 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 value of the primary_region parameter is changed from hz1,hz2;sh1,sh2;sz1 to hz;sh;sz.

3. Rearrange the zones in the primary zone setting based on the priorities of the regions in the primary region list. For zones of different regions, zones in a high-priority region have higher priority than those in a low-priority region. Zones of the same region are arranged based on the priorities in the original primary zone setting.

For example, assume that nine zones are available, and zones sh1, sh2, and sh3 are in the SH region, zones hz1, hz2, and hz3 are in the HZ region, and zones sz1, sz2, and sz3 are in the SZ region.

• Assume that the primary_zone parameter is set to 'sh1;hz1;hz2;sz1'. The primary region list obtained through rewriting based on Rule 1 is 'SH;HZ;HZ;SZ'. The primary region list obtained through rewriting based on Rule 2 is 'SH;HZ;SZ'. The primary region list obtained through rewriting based on Rule 3 is 'sh1;sh2,sh3;hz1;hz2;hz3;sz1;sz2,sz3'.

  Specifically:

  The priority order of the three regions is SH > HZ > SZ. Zones in the SH region have higher priorities than those in regions HZ and SZ. Zones in the HZ region have higher priorities than those in the SZ region. The priority order of zones in each region is as follows: sh1 > sh2 = sh3 in the SH region, hz1 > hz2 > hz3 in the HZ region, and sz1 > sz2 = sz3 in the SZ region. Therefore, the new value of the primary_zone parameter is 'sh1;sh2,sh3;hz1;hz2;hz3;sz1;sz2,sz3'. Leaders are preferentially scheduled to the sh1 zone. When the sh1 zone fails, leaders are sequentially scheduled to zones sh2 and sh3 based on the preceding priorities.

• Assume that the primary_zone parameter is set to 'sh1,sh2;hz1;hz2;sz1'. The primary region list obtained through rewriting based on Rule 1 is 'SH,SH;HZ;HZ;SZ'. The primary region list obtained through rewriting based on Rule 2 is 'SH;HZ;SZ'. The primary region list obtained through rewriting based on Rule 3 is 'sh1,sh2;sh3;hz1;hz2;hz3;sz1;sz2,sz3'.

  Specifically:

  The priority order of the three regions is SH > HZ > SZ. Zones in the SH region have higher priorities than those in regions HZ and SZ. Zones in the HZ region have higher priorities than those in the SZ region. The priority order of zones in each region is as follows: sh1 = sh2 > sh3 in the SH region, hz1 > hz2 > hz3 in the HZ region, and sz1 > sz2 = sz3 in the SZ region. Therefore, the new value of the primary_zone parameter is 'sh1,sh2;sh3;hz1;hz2;hz3;sz1;sz2,sz3'. Leaders are preferentially scheduled to zones sh1 and sh2. When zones sh1 and sh2 fail, leaders are sequentially scheduled to zones sh3 based on the preceding priorities.

• Assume that the primary_zone parameter is set to 'sh1,hz1;hz2;sz1'. The primary region list obtained through rewriting based on Rule 1 is 'SH,HZ;HZ;SZ'. The primary region list obtained through rewriting based on Rule 2 is 'SH,HZ;SZ'. The primary region list obtained through rewriting based on Rule 3 is 'sh1,hz1;hz2;sh2,sh3,hz3;sz1;sz2,sz3'.

  Specifically:

  The priority order of the three regions is SH = HZ > SZ. Zones in regions SH and HZ have higher priorities than those in the SZ region. The priority order of the zones is as follows: sh1 = hz1 > hz2 > sh2 = sh3 = hz3 > sz1 > sz2 = sz3. Therefore, the new value of the primary_zone parameter is 'sh1,hz1;hz2;sh2,sh3,hz3;sz1;sz2,sz3'. Leaders are preferentially scheduled to zones sh1 and hz1. When zones sh1 and hz1 fail, leaders are sequentially scheduled to zones hz2 based on the preceding priorities.