日志归档异常导致日志流 GC 卡住的原因和解决办法

问题现象

将某个租户的 unit_num 扩容完成后，如下图所示。

该租户 primary_zone=(az1;za3,az4), unit_num=24 且没有使用复制表，即不存在广播日志流，预期只有 25 个日志流，可以通过查询 cdb_ob_ls_locations 获取 1002 租户日志流的副本分布信息，SQL 语句如下。

select count(*),b.zone,a.svr_ip,a.svr_port from cdb_ob_ls_locations a,dba_ob_servers b where (a.svr_ip=b.svr_ip and a.svr_port=b.svr_port) and a.tenant_id=1002 and a.role='leader' group by b.zone,a.svr_ip,a.svr_port;

由截图内容可知明显超过预计的 25 个日志流：

通过查询 cdb_ob_ls 获取 1002 租户的所有日志流信息，SQL 语句如下。

select * from cdb_ob_ls where tenant_id=1002;

发现有 19 条记录对应的状态是 WAIT_OFFLINE，等待被 GC 掉，如下图所示。

确认日志流 GC 时间设置的为 0，说明日志流没有设置延迟删除，SQL 语句如下。

select name,value from gv$ob_parameters where name='ls_gc_delay_time' and tenant_id=1002;

问题排查

1. 通过 问题现象 章节中有关查询 cdb_ob_ls_locations 获取 1002 租户日志流的副本分布信息的截图，可知日志流最多的节点并在此节点上过滤关键词。

   grep T1002_GC observer.log
   

   输出内容如下：

   observer.log.20240830143110520:[2024-08-30 14:31:02.753661] INFO  [CLOG] try_check_and_set_wait_gc_ (ob_garbage_collector.cpp:816) [29459][T1002_GCCollect][T1002][Y0-0000000000000000-0-0] [lt=27] try_check_and_set_wait_gc_wait archive(ls_id={id:1525}, gc_state=4, offline_scn={val:1724927645210341842, v:0}, scn={val:1724927194626714794, v:0})
   observer.log.20240830143110520:[2024-08-30 14:31:02.753676] INFO  [CLOG] handle_gc_ls_offline_ (ob_garbage_collector.cpp:1180) [29459][T1002_GCCollect][T1002][Y0-0000000000000000-0-0] [lt=14] ls handle_gc_ls_offline finished(ls_id={id:1525}, role=1,gc_state=4, is_success=false)
   

   比较日志中的 scn 与 offline_scn 大小，SQL 语句如下。

   select scn_to_timestamp(1724927194626714794) as scn,
   scn_to_timestamp(1724927645210341842) as offline_scn;
   

   输出结果如下：

   +----------------------------+----------------------------+
   | scn                        | offline_scn                |
   +----------------------------+----------------------------+
   | 2024-08-29 18:26:34.626714 | 2024-08-29 18:34:05.210341 |
   +----------------------------+----------------------------+
   1 row in set (0.01 sec)
   

   可知归档位点 scn 未越过日志流的 offline_scn。

2. 确认 1002 租户的归档情况。

   select * from cdb_ob_archivelog where tenant_id=1002;
   

   

   发现日志归档的位点在 2024-08-28 03:23:18，排查该问题是 2024-08-30 号，说明日志归档卡住了。

   确认 1002 租户日志流归档的情况，发现有 2 个日志流存在异常（input/output/file_offset 为 0）。

   select *, scn_to_timestamp(checkpoint_scn) from __all_virtual_ls_log_archive_progress where tenant_id = 1002 and piece_id = 28;
   

   

   确认以上 2 个日志流对应的 Leader 节点。

   select svr_ip from gv$ob_log_stat where tenant_id=1002 and ls_id in (1505,1523) and role='leader';
   

   这里的日志以 1505 日志流为例，经过确认没有挂载 NFS，日志信息如下。

   [2024-08-30 14:29:32.270121] INFO  [STORAGE] mkdir (ob_storage_file.cpp:268) [29596][T1002_ArcSender][T1002][xxxxx-xxxxx-xxxxx-xxxxx] [lt=0] path exist(pos=6, path=/media)
   [2024-08-30 14:29:32.270141] WDIAG [STORAGE] mkdir (ob_storage_file.cpp:304) [29596][T1002_ArcSender][T1002][xxxxx-xxxxx-xxxxx-xxxxx] [lt=11][errcode=-4009] failed to create parent dir(ret=-4009, path=/media/nfs, errno=13, errno="Permission denied)
   [2024-08-30 14:29:32.270149] WDIAG [STORAGE] mkdir (ob_storage.cpp:1159) [29596][T1002_ArcSender][T1002][xxxxx-xxxxx-xxxxx-xxxxx] [lt=8][errcode=-4009] failed to mkdir(ret=-4009, uri=file:///media/nfs/xxxx/piece_xxxxx/logstream_1505/log)
   

   重新挂载 NFS 后，日志流 GC 掉了。

适用版本

OceanBase 数据库 V4.x 版本。