OB三节点服务，在单节点100网络丢包的情况下，服务恢复时间可能达到10-15分钟

[行行速速]

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.4.2
【问题描述】
OB三节点服务，在单节点100网络丢包的情况下，分区leader一直在故障节点上，服务恢复时间会达到10-15分钟。

当前暂时复现不出来，想了解一下ob的机制，测试过程参考下方复现路径和测试图片。图片中显示节点已经不活跃了，但是分区leader一直没有切换，持续大约10-15分钟。

数据量大约1亿，持续有读写流量。
【复现路径】

之前的测试过程：

1. pod1注入100%丢包，10s内oceanbase完成leader切换。
2. 故障恢复，等待leader重新恢复。
3. 立刻给pod2注入100%丢包，oceanbase恢复要10分钟才能完成leader切换。

【附件及日志】

[wkk2025]

厉害

[辞霜]

root service节点在哪个zone

[行行速速]

这个检查的就只有图片上的内容。想了解一下有没有什么机制会导致恢复时间很长，或者已经处理过的bug？
以下情况就算恢复，然后测试的下一个节点。

1. 检查活跃情况，三个节点都ACTIVE。
2. 检查分区leader情况，三个节点都存在。

[辞霜]

pod1 pod2具体指向了集群的哪两个节点

[行行速速]

这里没有具体关系，实际测的时候是zone1，zone2，zone3轮着来，等待前一个节点状态和分区恢复后，才测试的下一个。
图片上就是zone1的observer出现了网络丢包。

1. 之前测试了zone3。
2. 10s就切换了leader。
3. 然后网络丢包恢复。
4. 恢复后测试的zone1。
5. zone1恢复大约等了12分钟。

[辞霜]

4.x选举是以日志流为单位的，测试的时候应该查一下 gv$ob_log_stat。

查内部表的切主的事件，确定下日志流具体的切主时间
SELECT value4,svr_ip,svr_port,event,name3,value3 FROM __all_server_event_history WHERE module=“ELECTION” AND value1=$tenant_id AND value2=$ls_id ORDER BY value4;

[行行速速]

好的，感谢。
这个是之前偶现的，这边进行长期持续复现测试，大约测了200次，最长恢复时间都在10s内。

[AntTech_MO4OZE]

看来网络质量很重要啊

[AntTech_MSPSKN]

6666

[行行速速]

老师，再咨询一些问题

1. 单节点故障恢复后，应该要检查哪里确认完全恢复。
2. 还有故障中，故障后都有哪些可以检查的，或者查询的，方便给一些例子么？

[wentian178]

查看 election.log 里 message not in time、lease expired；查 __all_server_event_history 选举事件OceanBase。
SELECT * FROM oceanbase.__all_server_event_history WHERE module=‘ELECTION’;

调小租约 / 选举超时、压测前停后台任务、优化网络低延迟无丢包

[辞霜]

@论坛小助手

1. 单节点故障恢复后，应该要检查哪里确认完全恢复。
2. 还有故障中，故障后都有哪些可以检查的，或者查询的，方便给一些例子么？

[论坛小助手]

单节点故障恢复后的检查步骤

在单节点故障恢复后，确保集群和数据完全恢复是非常重要的。以下是一些关键的检查点和查询示例：

1. 检查节点状态

• 确认节点是否处于ACTIVE状态：

  SELECT * FROM __all_server WHERE status = 'active';
  

2. 检查日志流（Partition）的状态

• 查看所有分区的日志流状态：

  SELECT * FROM gv$ob_log_stat;
  

• 检查特定租户和日志流的切主事件：

  SELECT value4, svr_ip, svr_port, event, name3, value3 
  FROM __all_server_event_history 
  WHERE module = 'ELECTION' 
    AND value1 = $tenant_id 
    AND value2 = $ls_id 
  ORDER BY value4;
  

3. 检查Leader副本分布

• 查看所有分区的Leader副本分布情况：

  SELECT * FROM gv$partition WHERE role = 1;
  

4. 检查Root Service的心跳状态

• 查看Root Service与OBServer节点之间的心跳状态：

  SELECT * FROM __all_virtual_server_stat;
  

5. 检查数据一致性

• 验证数据的一致性：

  -- 比较不同节点上的数据
  SELECT * FROM table_name LIMIT 100;
  

故障中和故障后的检查

故障中

• 监控网络状况：

  • 使用 tsar 工具检查网络抖动：

    tsar --tcp -i 1 -dYYYYMMDD
    

  • 检查是否有丢包或重传：

    ifconfig | grep "errors"
    

• 检查OBServer进程状态：

  • 确认OBServer进程是否正常运行：

    ps -ef | grep observer
    

• 检查日志文件：

  • 查看OBServer的日志文件，查找错误信息：

    tail -f /path/to/observer/logfile
    

故障后

• 检查节点是否重新加入集群：

  • 确认节点是否重新上线并恢复正常工作：

    SELECT * FROM __all_server WHERE status = 'active';
    

• 检查分区Leader是否正确切换：

  • 验证Leader副本是否已经切换到其他节点：

    SELECT * FROM gv$partition WHERE role = 1;
    

• 检查数据副本完整性：

  • 确认所有数据副本都已同步：

    SELECT * FROM gv$ob_log_stat;
    

• 检查系统配置项：

  • 确认 server_permanent_offline_time 配置项是否合适：

    SHOW PARAMETERS LIKE 'server_permanent_offline_time';
    

通过以上步骤，可以全面检查单节点故障恢复后的状态，并确保集群和数据的一致性和完整性。如果有任何异常，可以通过这些检查点快速定位问题。

更多信息请查看:

1. 节点故障的自动处理
2. 网络抖动
3. 遇到问题如何向技术支持同学提问
4. 重启节点
5. 多数派节点故障
6. 查看节点
7. 节点宕机