oceanbase 物理备库同步消息

【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】我有两台 ocenabase 机器，物理备库形式搭建。主库防火墙规则出问题了一会，没过一会恢复了。后面主备同步了一段时间，最后卡在了 11:41
【复现路径】断开主备 ocenabase 之间网络
【附件及日志】
oceanbase_bak.tar.gz (10.1 MB)

@论坛小助手 物理备库同步日志以及错误信息，应该在哪个文档看呢？

根据您的描述，主备库之间存在同步延迟问题，可能是由于防火墙规则导致的。推荐使用 obdiag 工具进行日志采集，以便您查看相关日志和错误信息。

日志采集场景: 主备库延迟
日志采集命令: obdiag gather scene run --scene=observer.delay_of_primary_and_backup

请您执行上述命令采集日志，并将生成的日志压缩包提供给我们以便进一步分析。

另外，为了更好地帮助您解决问题，需要您提供以下信息：

1. 主库和备库之间的网络是否已经恢复正常？
2. 防火墙规则调整后，是否有验证过主备库之间的连通性？
3. 备库卡在 11:41 的具体表现是什么（例如是否有报错信息、日志中是否有异常记录）？
4. 当前主备库的同步模式是同步还是异步？
5. 是否可以提供主库和备库的相关配置信息（如 zone、region 等）？

附上敏捷诊断工具 obdiag 使用帮助链接

1、已经恢复正常，我重建了备租户
2、是连通的，因为恢复之后我看继续同步了一段时间才停止
3、通过 sql 查询，同步进度停留在了 11:41；查询 sql如下：
SELECT TENANT_NAME, TENANT_ID, TENANT_ROLE, SCN_TO_TIMESTAMP(SYNC_SCN) FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = ‘tenant’;
4、同步

另外我想问下，普通 ob 日志里面是否有主从同步相关日志呢？

根据您的问题和补充信息，以下是针对您提出的问题的解答：

1. 关于主备库同步相关日志

普通 OB 日志中确实包含主从同步相关的日志信息。这些日志可以帮助您排查主备库同步过程中可能存在的问题。以下是具体说明：

• 日志路径：OceanBase 的日志文件通常位于数据目录下的 log 文件夹中。例如：

  /home/admin/oceanbase/log/
  

  其中，observer.log 是主要的日志文件，记录了数据库运行过程中的各种事件，包括主备同步相关信息。

• 日志关键字：在 observer.log 中，您可以搜索以下关键字来查看主备同步相关的日志：

  • sync standby：与备库同步相关的日志。
  • replay log：与日志回放相关的日志。
  • archive log：与归档日志相关的日志。
  • standby tenant：与备租户相关的日志。

• 日志级别：默认情况下，日志级别为 INFO，如果您需要更详细的日志信息，可以将日志级别调整为 DEBUG 或 TRACE。调整方法如下：

  ALTER SYSTEM SET ob_log_level='DEBUG';
  

• 日志采集工具：为了更方便地收集和分析日志，建议使用 obdiag 工具。您可以执行以下命令采集日志：

  obdiag gather log --start-time="2023-11-01 00:00:00" --end-time="2023-11-02 00:00:00"
  

  这将采集指定时间段内的日志文件。

2. 关于重建备租户后同步停止的问题

根据您提供的查询 SQL 和结果，备租户的同步进度停留在了 11:41。以下是可能的原因及解决方法：

原因分析

• 防火墙规则导致短暂断连：虽然网络已经恢复，但防火墙规则的变化可能导致备库未能及时重新连接到主库，从而造成同步中断。
• 未执行 RECOVER 命令：根据文档片段 4 的描述，如果未执行 RECOVER 命令或执行了 ALTER SYSTEM RECOVER xxx CANCEL 命令，备租户的日志同步会停留在某个固定时间点。
• 日志恢复源问题：根据文档片段 3 的描述，如果备租户的日志恢复源为空或被损坏，也会导致同步卡住。

解决方法

1. 检查日志恢复源：

   • 确保备租户的日志恢复源正确配置。如果是基于网络的物理备库，请确认主租户未被删除且复制专用账号密码未被修改。
   • 如果是基于归档的物理备库，请确认用于恢复日志的归档目录未被删除。

2. 重新执行 RECOVER 命令：

   • 在系统租户下，执行以下命令开启备租户的日志同步：

     ALTER SYSTEM RECOVER STANDBY TENANT = standby_tenant UNTIL UNLIMITED;
     

   • 在备租户下，执行以下命令开启日志同步：

     ALTER SYSTEM RECOVER STANDBY UNTIL UNLIMITED;
     

3. 检查主备库角色：

   • 使用以下 SQL 查询主备库的角色，确保主库角色为 PRIMARY，备库角色为 STANDBY：

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

4. 查看日志同步进度：

   • 使用以下视图查看日志同步进度，确认是否恢复正常：

     SELECT * FROM oceanbase.DBA_OB_LS;
     

3. 总结

• 普通 OB 日志中确实包含主从同步相关日志，您可以搜索 sync standby、replay log 等关键字进行排查。
• 针对重建备租户后同步停止的问题，建议检查日志恢复源、重新执行 RECOVER 命令，并确认主备库角色是否正确。
• 如果问题仍未解决，建议使用 obdiag 工具采集日志并提供更多信息以便进一步分析。

希望以上信息对您有所帮助！如果还有其他问题，请随时提问。

更多信息请查看:

1. 暂停或开启日志同步
2. 物理备库同步过程中卡住
3. oceanbase.DBA_OB_TENANTS
4. 负载均衡
5. RECOVER STANDBY
6. oceanbase.DBA_OB_LS
7. oceanbase.DBA_OB_BACKUP_TASKS

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

是重建完以后 恢复了同步 同步一段时间以后 同步卡住了是么？ob的版本号提供一下

信息查一下
select * from oceanbase.DBA_OB_TENANTS\G;
-在备租户查一下信息
select * from __all_virtual_tenant_info where tenant_id = 1002\G;

排查思路：
1.检查日志流恢复状态
2.网络
3.时钟同步情况
4.主库日志拉取情况
5.备库日志流 leader 状态

是的，4.2.4

目前已经重建了备租户，下次如果遇到。我查一下。这里的逻辑是什么呢？

如果发现主库日志流正常记录，备库日志流leader卡主不动。应该怎么继续排查呢？

你这个同步卡住 差不多可以按照这几步排查一下

确认租户角色以及可恢复位点

select * from __all_virtual_tenant_info where tenant_id = 1002;

查看日志流恢复状态表

重点关注 “sync_status” 列，表示日志流恢复状态，正常为 NORMAL，其他状态表示恢复异常
select * from v$ob_ls_log_restore_status where tenant_id = 1002;

查看日志恢复源

select * from cdb_ob_log_restore_source where tenant_id = 1002;

查找最慢日志流

select *, scn_to_timestamp(end_scn) from gv$ob_log_stat where tenant_id = 1002 and role = ‘leader’ order by end_scn;

observer的日志

好的，observer 中主备同步日志有什么特点么?和上面说的一样吗

• sync standby：与备库同步相关的日志。
• replay log：与日志回放相关的日志。
• archive log：与归档日志相关的日志。
• standby tenant：与备租户相关的日志。

到时候可以直接提供过来 这样可以帮助分析看看什么问题

好的，谢谢