物理备库同步过程中卡住

本文主要介绍物理备库在同步过程中出现日志同步卡住时问题的排查及定位方法。

问题一：未执行 RECOVER 命令、执行 RECOVER 命令恢复到指定终点或执行过 ALTER SYSTEM RECOVER xxx CANCEL 命令

问题现象

• 用户通过物理恢复的方式恢复出备租户后，未执行 RECOVER 命令更改新备租户的恢复终点，当日志流恢复到某个指定的终点，备租户的日志同步卡住。
• 用户通过物理恢复的方式恢复出备租户后，执行 RECOVER 命令到指定终点，当日志流恢复到某个指定的终点，备租户的日志同步卡住。
• 用户通过物理恢复的方式恢复出备租户，执行 RECOVER 命令后，又执行了 ALTER SYSTEM RECOVER xxx CANCEL 命令，当日志流恢复到某个指定的终点，备租户的日志同步卡住。

问题原因

通常情况下，通过物理恢复的方式恢复出备租户后，如果不执行 RECOVER 命令或者执行 RECOVER 命令恢复到指定终点，备租户的日志同步就会停留在指定的恢复终点。此外，如果备租户执行 RECOVER 命令后，又执行了 ALTER SYSTEM RECOVER xxx CANCEL 命令，备租户的日志同步也会停留在某个恢复终点。

如下所示的示例中，租户 restore_oracle_tenant 的租户角色为 STANDBY，其同步进度卡在了某个固定时间点。造成该现象的原因是用户未执行 RECOVER 命令或执行 RECOVER 命令恢复到指定终点，又或者是执行 RECOVER 命令后又执行过 ALTER SYSTEM RECOVER xxx CANCEL 命令，当租户同步位点 SYNC_SCN 等于可恢复位点 RECOVERY_UNTIL_SCN，备租户无需再同步更多日志。

*************************** 1. row ***************************
                     TENANT_ID: 1002
                   TENANT_NAME: restore_oracle_tenant
                   TENANT_ROLE: STANDBY
                        STATUS: NORMAL
             SWITCHOVER_STATUS: NORMAL
                      SYNC_SCN: 1690425747241344851
                REPLAYABLE_SCN: 1690425747241344851
                  READABLE_SCN: 1690425747241344851
            RECOVERY_UNTIL_SCN: 1690425747241344851
1 row in set

排查步骤

可以通过 DBA_OB_TENANTS 视图确认同步位点信息。

1. 租户管理员登录问题租户或问题租户所在集群的 sys 租户。

2. 根据租户的 TENANT_ID 或 TENANT_NAME 查询问题租户的基本状态信息，包括租户角色、同步位点等信息。

   • 系统租户查看指定租户

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
     

   • 问题租户查询本租户

     MySQL 模式

     Oracle 模式

     语句如下：

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
     

     语句如下：

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS;
     

   查询结果中，重点关注以下几列的值：

   • TENANT_ROLE：STANDBY 表示备租户；PRIMARY 表示主租户。
   • SYNC_SCN：表示租户的同步位点。
   • REPLAYABLE_SCN：表示租户的可回放位点，SCN 大于该位点的日志不能回放。
   • RECOVERY_UNTIL_SCN：表示租户可恢复到的终点，如果值为 4611686018427387903，则表示恢复到无穷。

   有关视图 DBA_OB_TENANTS 的更多说明，请参见 DBA_OB_TENANTS。

问题二：租户未设置日志恢复源、日志恢复源为空或日志恢复源被损坏

问题现象

• 使用 BACKUP DATABASE PLUS ARCHIVELOG 命令创建备租户后，未再设置日志恢复源或设置的日志恢复源为空，即 ALTER SYSTEM SET log_restore_source = '';。
• 备租户被清空过日志恢复源
• 主租户通过 Switchover 命令切换为备租户后，未设置日志恢复源

问题原因

在 OceanBase 数据库中，备租户通过日志恢复源来拉取上游的日志。通过物理备份恢复功能创建的备租户，用户在执行 RECOVER 命令后，默认会继续从恢复时指定的归档目录继续恢复日志；通过 CREATE STANDBY TENANT 命令创建的备租户，默认会通过网络直接从主租户处同步日志；而通过 BACKUP DATABASE PLUS ARCHIVELOG 命令创建的备租户未指定日志恢复源，无法直接开启日志持续同步。

此外，当备租户的日志恢复源为空，或者设置的日志恢复源被损坏时，同样会导致备租户卡住，例如，基于网络的物理备库其主租户被删除或者用于访问主租户的复制专用账号的密码被修改，基于归档的物理备库其用于恢复日志的归档目录被删除等。

排查步骤

可以通过视图 CDB_OB_LOG_RESTORE_SOURCE 或 DBA_OB_LOG_RESTORE_SOURCE 来确认问题租户是否设置了日志恢复源。

1. 租户管理员登录问题租户或问题租户所在集群的 sys 租户。

2. 确认问题租户是否设置了日志恢复源。

   • 系统租户查看指定租户

     SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE TENANT_ID=1xxx;
     

   • 问题租户查看本租户

     MySQL 模式

     Oracle 模式

     语句如下：

     SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE;
     

     语句如下：

     SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE;
     

   查询结果中，重点关注以下几列的值：

   • TYPE：如果值为 LOCATION，则表示当前租户通过归档日志从源端租户同步日志，即属于基于归档的物理备库；如果值为 SERVICE，则表示当前租户通过网络从主租户直接同步日志，即属于基于网络的物理备库。通过执行 ALTER SYSTEM SET log_restore_source 命令，可以切换备租户的日志同步源。

   • VALUE：其值与 TYPE 的值对应，分别为源端租户的归档目录以及主租户的 Access Point。

   如下所示的查询结果中，如果租户 restore_oracle_tenant 的日志恢复源查询结果为空，则表示该租户未设置日志恢复源，备租户的日志同步自然会卡住。如果查询结果的值为归档目录，则需要检查归档目录在主、备租户的所有机器上是否均可以访问；如果值为主租户的 Access Point，则需要确认 IP 列表、USER、PASSWORD 等是否均设置正确。

   *************************** 1. row ***************************
                      tenant_id: 1002
                           type: LOCATION
                          value: file:///data/1
             recovery_until_scn: 4611686018427387903
   1 row in set
   

   有关视图 CDB_OB_LOG_RESTORE_SOURCE 和视图 DBA_OB_LOG_RESTORE_SOURCE 的更多说明，请参见 CDB_OB_LOG_RESTORE_SOURCE 和 DBA_OB_LOG_RESTORE_SOURCE。

问题三：备库日志同步状态异常

问题现象

在问题一和二都不存在的情况下，仍然出现备租户日志同步异常的情况。

问题原因

日志同步过程中，可能由于主租户日志流回收、网络原因等造成备租户落后或者卡住的情况。

排查步骤

视图 V$OB_LS_LOG_RESTORE_STATUS 汇总了所有日志流的同步状态，可以通过该视图来确认租户所有日志流的同步状态。

1. 租户管理员登录问题租户或问题租户所在集群的 sys 租户。

2. 查看问题租户所有日志流 Leader 的同步状态。

   • 系统租户查看指定租户

     SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS WHERE TENANT_ID=1xxx;
     

   • 问题租户查看本租户

     MySQL 模式

     Oracle 模式

     语句如下：

     SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS;
     

     语句如下：

     SELECT * FROM SYS.V$OB_LS_LOG_RESTORE_STATUS;
     

     查询结果中，重点关注以下几列的值：

     • SYNC_SCN：表示该日志流的同步位点。

     • SYNC_STATUS：表示该日志流同步状态，其中，NORMAL 表示该日志流的日志同步状态正常，如果为其他状态则表示异常。日志同步状态及其含义如下表所示。

     有关视图 V$OB_LS_LOG_RESTORE_STATUS 的更多说明，请参见 V$OB_LS_LOG_RESTORE_STATUS。

   日志同步状态	含义
   NORMAL	正常同步中
   SOURCE HAS A GAP	备租户与源端日志有 gap，主租户的日志未同步到备租户就已回收
   STANDBY LOG NOT MATCH	恢复日志与备租户冲突，可能是出现双 PRIMARY 或者日志恢复源设置错误
   CHECK USER OR PASSWORD	复制账户用户名或密码不对，无法访问原主租户
   CHECK NETWORK	主租户不可达，需要检查网络是否异常
   RESTORE SUSPEND	备租户已经恢复到指定位点
   STANDBY NEED UPGRADE	备租户的 Binary 版本落后，需要升级
   PRIMARY TENANT DROPPED	主租户已经被删除
   FETCH LOG TIMEOUT	同步日志超时，需要排查网络健康状况或者调大备租户日志同步超时的租户级配置项 standby_db_fetch_log_rpc_timeout，有关 standby_db_fetch_log_rpc_timeout 的详细说明请参见 standby_db_fetch_log_rpc_timeout
   STANDBY IN THROTTLING	备租户写入限速中
   STANDBY LOG DISK IS FULL	备租户磁盘空间不足
   WAIT LOG STREAM CREATED	等待备租户创建日志流完成
   NOT AVAILABLE	其他异常导致的日志同步不可用

问题四：备租户同步位点推进卡住

问题现象

当备租户未出现问题一、问题二、问题三等以上描述的所有问题，但是依然卡住，可以尝试分析是否是备租户同步位点推进卡住。

问题原因

备租户在同步日志的过程中，遵循所有日志流齐步走的策略，因此每个日志流均会考虑租户的 SYNC_SCN，并且会基于一定的策略超前拉取日志。由于租户的 SYNC_SCN 不推进，会导致日志同步也停止，直到租户的 SYNC_SCN 恢复后才能重新开始日志同步。

排查步骤

1. 租户管理员登录问题租户或问题租户所在集群的 sys 租户。

2. 通过视图 DBA_OB_TENANTS 查看租户的同步位点 SYNC_SCN。

   可以根据租户的 TENANT_ID 或 TENANT_NAME 查询问题租户的 SYNC_SCN。

   • 系统租户查看指定租户的 SYNC_SCN

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
     

   • 问题租户查询本租户 SYNC_SCN

     MySQL 模式

     Oracle 模式

     语句如下：

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
     

     语句如下：

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS;
     

   查询结果中，重点关注以下几列的值：

   • TENANT_ROLE：STANDBY 表示备租户；PRIMARY 表示主租户。
   • SYNC_SCN：表示租户的同步位点。

3. 通过 V$OB_LS_LOG_RESTORE_STATUS 视图查询所有日志流 Leader 的 SYNC_SCN。

   • 系统租户查看指定租户

     SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS WHERE TENANT_ID=1xxx;
     

   • 问题租户查看本租户

     MySQL 模式

     Oracle 模式

     语句如下：

     SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS;
     

     语句如下：

     SELECT * FROM SYS.V$OB_LS_LOG_RESTORE_STATUS;
     

     查询结果中，重点关注 SYNC_SCN 列，它表示日志流的同步位点。

     根据两次的查询结果，比较所有日志流的 SYNC_SCN 与租户的 SYNC_SCN。如果所有日志流的 SYNC_SCN 均大于租户的 SYNC_SCN 并且没有变化，则表示租户的日志同步进度统计有问题，需要进一步排查租户日志同步进度统计的问题。

     有关视图 V$OB_LS_LOG_RESTORE_STATUS 的更多说明，请参见 V$OB_LS_LOG_RESTORE_STATUS。

问题五：主备租户的角色都是 STANDBY

问题现象

在无级联备库的场景中，主备关系的租户需要至少一个主租户（即租户角色为 PRIMARY），否则两个租户的日志同步进度会表现为不再推进。

问题原因

在主租户上执行 Switchover 主切备后，原主备租户的角色都是 STADNBY，就会发生这种情况。

排查步骤

可以通过 DBA_OB_TENANTS 视图分别查看主备租户的角色，确认主备租户的角色是否都是 STANDBY。

1. 租户管理员分别登录主备租户或主备租户所在集群的 sys 租户。

2. 分别执行以下语句，查询主备租户的角色。

   • 系统租户查看主租户或备租户

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS FROM oceanbase.DBA_OB_TENANTS;
     

   • 主租户或备租户查看本租户

     MySQL 模式

     Oracle 模式

     语句如下：

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS FROM oceanbase.DBA_OB_TENANTS;
     

     语句如下：

     SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS FROM SYS.DBA_OB_TENANTS;
     

   查询结果中：

   • TENANT_ID：表示租户 ID。
   • TENANT_NAME：表示租户名。
   • TENANT_ROLE：表示租户角色。PRIMARY 表示主租户；STANDBY 表示备租户。

   根据查询结果，确认是否出现主备租户的角色都是 STANDBY 的情况。

   有关视图 DBA_OB_TENANTS 的更多说明，请参见 DBA_OB_TENANTS。