primary_zone疑问

OceanBase 技术问题
#1

version：4.3.0.1

mysql> select * from dba_ob_tenants where TENANT_ID%2=0 \G
*************************** 1. row ***************************
                 TENANT_ID: 1002
               TENANT_NAME: tnt_odc
               TENANT_TYPE: USER
               CREATE_TIME: 2024-06-16 14:02:26.701239
               MODIFY_TIME: 2024-06-16 14:02:59.517108
              PRIMARY_ZONE: RANDOM
                  LOCALITY: FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3
         PREVIOUS_LOCALITY: NULL
        COMPATIBILITY_MODE: MYSQL
                    STATUS: NORMAL
             IN_RECYCLEBIN: NO
                    LOCKED: NO
               TENANT_ROLE: PRIMARY
         SWITCHOVER_STATUS: NORMAL
          SWITCHOVER_EPOCH: 0
                  SYNC_SCN: 1736504501073148845
            REPLAYABLE_SCN: 1736504501073148845
              READABLE_SCN: 1736504501073148845
        RECOVERY_UNTIL_SCN: 4611686018427387903
                  LOG_MODE: NOARCHIVELOG
ARBITRATION_SERVICE_STATUS: DISABLED
                  UNIT_NUM: 1
                COMPATIBLE: 4.3.0.1
                 MAX_LS_ID: 1003

确认 PRIMARY_ZONE: RANDOM,然后把zone1设置为primary_zone，并且zone2优先级等于zone3

mysql> alter tenant tnt_odc PRIMARY_ZONE='zone1;zone2,zone3';
Query OK, 0 rows affected (0.06 sec)

修改后确认：

mysql> select * from dba_ob_tenants where TENANT_ID=1002\G
*************************** 1. row ***************************
                 TENANT_ID: 1002
               TENANT_NAME: tnt_odc
               TENANT_TYPE: USER
               CREATE_TIME: 2024-06-16 14:02:26.701239
               MODIFY_TIME: 2025-01-10 18:22:05.336706
              PRIMARY_ZONE: zone1;zone2;zone3
                  LOCALITY: FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3
         PREVIOUS_LOCALITY: NULL
        COMPATIBILITY_MODE: MYSQL
                    STATUS: NORMAL
             IN_RECYCLEBIN: NO
                    LOCKED: NO
               TENANT_ROLE: PRIMARY
         SWITCHOVER_STATUS: NORMAL
          SWITCHOVER_EPOCH: 0
                  SYNC_SCN: 1736504535293326649
            REPLAYABLE_SCN: 1736504535293326649
              READABLE_SCN: 1736504535136367112
        RECOVERY_UNTIL_SCN: 4611686018427387903
                  LOG_MODE: NOARCHIVELOG
ARBITRATION_SERVICE_STATUS: DISABLED
                  UNIT_NUM: 1
                COMPATIBLE: 4.3.0.1
                 MAX_LS_ID: 1003
1 row in set (0.02 sec)

image

为什么这里显示的优先级是zone1>zone2>zone3,而不是zone1>zone2=zone3 呢？

#3

通常情况下 修改了 primary_zone 后会很快生效。如果没有生效就是租户出现问题了，切主卡住了。这个需要查一下才知道。

select * from __all_rootservice_job;

找到那个 变更 primary_zone 的任务，是不是卡住了。

#4

666

#5

最后一次变更：
image

这是租户的primary_zone当前分布：

mysql> select * from dba_ob_tenants where tenant_id=1002 \G
*************************** 1. row ***************************
                 TENANT_ID: 1002
               TENANT_NAME: tnt_odc
               TENANT_TYPE: USER
               CREATE_TIME: 2024-06-16 14:02:26.701239
               MODIFY_TIME: 2025-01-10 18:22:05.336706
              PRIMARY_ZONE: zone1;zone2;zone3
                  LOCALITY: FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3
         PREVIOUS_LOCALITY: NULL
        COMPATIBILITY_MODE: MYSQL
                    STATUS: NORMAL
             IN_RECYCLEBIN: NO
                    LOCKED: NO
               TENANT_ROLE: PRIMARY
         SWITCHOVER_STATUS: NORMAL
          SWITCHOVER_EPOCH: 0
                  SYNC_SCN: 1736731160428596366
            REPLAYABLE_SCN: 1736731160428596366
              READABLE_SCN: 1736731160428596366
        RECOVERY_UNTIL_SCN: 4611686018427387903
                  LOG_MODE: NOARCHIVELOG
ARBITRATION_SERVICE_STATUS: DISABLED
                  UNIT_NUM: 1
                COMPATIBLE: 4.3.0.1
                 MAX_LS_ID: 1004
1 row in set (0.00 sec)
#6

好神奇

#7

image
image813×827 19.3 KB

#8

感觉像是踩到 bug 了。 @兹拉坦 兹拉坦

1 个赞
#9

查一下 切主事件
SELECT *

FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY

WHERE EVENT LIKE ‘%switch%’ ORDER BY TIMESTAMP DESC

#10

image
image833×307 7.95 KB

#11

嗯，我觉得也像个 bug，值班同学 @淇铭 在看了，谢谢提醒~

1 个赞
#12

查一下 这两个事件 limit不要限制 看看事件信息
SELECT *

FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY

WHERE EVENT LIKE ‘%revoke%’ ORDER BY TIMESTAMP DESC;
SELECT *

FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY

WHERE EVENT LIKE ‘%takeover%’ ORDER BY TIMESTAMP DESC;

#13

目前查询这个视图oceanbase.cdb_ob_table_locations 查看的leader分布没有问题 后面有时间了 可以再做一次 捞一下日志信息 看看什么问题导致的没有更新基表信息