如何排查位点统计卡住

SYNC_SCN 卡住

REPLAYABLE_SCN 是 SYNC_SCN 与 READABLE_SCN 计算的结果，所以如果位点卡住，只会是 SYNC_SCN 或者 READABLE_SCN 卡住，REPLAYABLE_SCN 是受害者，所以这里的卡住，属于 SYNC_SCN 和 READABLE_SCN 卡住的问题。

若 SYNC_SCN 卡住，按照以下步骤排查：

1. 在系统租户下确定 SYNC_SCN 是否停止变化，执行如下查询。

   select * from oceanbase.__all_virtual_tenant_info where tenant_id = xxxx;
   

   如果 SYNC_SCN 一段时间内没有发生变化，则需要看 RECOVERY_UNTIL_SCN，如果 SYNC_SCN 已经大于等于 RECOVERY_UNTIL_SCN，则 SYNC_SCN 没有发生变化是预期内的。

2. 如果未达到到 RECOVERY_UNTIL_SCN，则需要进一步排查是哪个日志流的 SYNC_SCN 不推进了。

   在系统租户下执行如下查询语句。

   select * from oceanbase.__all_virtual_ls_recovery_stat where tenant_id = xxxx;
   

   每个日志流的同步位点的汇报都由本日志流选举的 leader 进行。所以在确定某个日志流不推进了，需要在是 leader 的机器上找日志。

3. 在去排查日志之前，在系统租户下执行如下命令，查询是否由于没拉日志导致的没有汇报。 在系统租户下执行查询语句。

   select * from oceanbase.__all_virtual_log_stat where tenant_id = xxx and ls_id = yyy;
   

   如果 leader 副本的 END_SCN 和 SYNC_SCN 是相等。那就是没有拉日志导致的。

4. 如果没有拉日志，可以在系统租户下查看日志流的恢复状态是不是到了拉日志的状态，执行如下查询语句。

   select * from oceanbase.__all_virtual_ls_meta_table where tenant_id = xxx and ls_id = yyy;
   

   看 leader 副本的 is_restore 状态。如果是备库的话，请联系 OceanBase 技术支持团队协助排查。

系统日志流

系统日志流需要去 Txxx_RecLSSer 下找日志。 关键日志，要去找 thread_idx= 1 线程日志。如果这个线程有报错，可以联系 OceanBase 技术支持团队协助排查。

 LOG_INFO("[LS_RECOVERY] finish one round"

示例命令如下：

fgrep "T1004_RecLSSer" rootservice.log | grep "finish one round" | grep "thread_idx=1" | vim -

这个线程池内有两个线程，只有 thread_idx= 1 是用来汇报同步位点的，所以要据此信息找到对应报错线程的日志。

普通日志流

普通日志流需要找 Txxx_TeRec 找日志。

示例命令如下：

fgrep "T1004_TeRec" rootservice.log | grep "id:1003" | vim -

如果这个线程有报错，请联系 OceanBase 技术支持团队协助排查。

READABLE_SCN 卡住

READABLE_SCN 可读点不同于 SYNC_SCN，可读点统计的是多数派副本的最小的可读点。

例如一个日志流 3 个副本，leader 副本的可读点是 10 点，follower 副本 1 的位点是 11 点，follower 副本 2 的位点是 9 点，最后统计出来的可读点就是 10 点。

和 SYNC_SCN 一样，READABLE_SCN 可读点的汇报是和 SYNC_SCN 在同一个线程中的。

若 READABLE_SCN 卡住，按照以下步骤排查:

1. 在系统租户下确定 READABLE_SCN 是否停止变化，执行如下查询语句。

   select * from oceanbase.__all_virtual_tenant_info where tenant_id = xxxx;
   

   如果 READABLE_SCN 在一段时间内没有发生变化，则需要看 SYNC_SCN，如果 READABLE_SCN 已经等于 SYNC_SCN，则 READABLE_SCN 没有发生变化是在预期内的。

2. 如果未达到到 SYNC_SCN，则需要进一步排查是哪个日志流的 READABLE_SCN 不推进了。

   在系统租户下执行如下查询语句。

   select * from oceanbase.__all_virtual_ls_recovery_stat where tenant_id = xxxx;
   

   每个日志流的同步位点的汇报都由本日志流的选举的 leader 进行。所以在确定某个日志流不推进了，需要去 leader 的机器上找日志。

   确定落后的日志流及其 WEAK_READ_TIMESTAMP。

3. 如果多数派的 WEAK_READ_TIMESTAMP 落后，执行如下查询语句，检查回放是否卡住。

   select * from oceanbase.__all_virtual_ls_info where tenant_id = xxxx and ls_id = yyy;//WEAK_READ_TIMESTAMP
   

   如果经过上面的查询多数派的 WEAK_READ_TIMESTAMP 是落后的，那大概率就是回放卡住了。如果回放卡住了，需要去回放卡住的副本上去找相应的日志。

4. 确认是否有待回放的任务，执行如下查询语句。

   select * from oceanbase.__all_virtual_replay_stat where tenant_id = xxxx and ls_id = yyy
   

   如果可读点的汇报确实卡住了，请按照 SYNC_SCN 卡住排查位点的方法，分系统日志流和普通日志流分别去不同的线程中找相应的日志，并联系 OceanBase 技术支持团队协助排查。