OBServer 线程主动 hung 问题

适用版本

OceanBase 数据库 V2.x、V3.x 版本。

问题描述

1. 日志中可以看到如下报错。

   ERROR right_to_die_or_duty_to_live (ob_hang_fatal_error.cpp:34) [32338][0][Y65DD645869DF-0005E28D74051991-0-0] [lt=46] [dc=0] Trying so hard to die, extra_info=((null)) BACKTRACE:xxx
   

2. 租户无法登录和连接，其他租户或者系统租户此时可能是正常的。

3. OBServer crash 同时在 crash 之前发生过 right_to_die_or_duty_to_live 的主动报错，并且 crash 为使用已经释放的内存从而导致的非法访问。

问题原因

OceanBase 数据库在特别的处理场景下，会主动发起和挂起 thread 的行为。该行为可能因为类型比较出错无法进行下去，或者因为存储层 compact 的过程中迭代发现错误行等行为触发。一旦在 observer.log 发现 right_to_die_or_duty_to_live 的关键词，即可表示该问题被触发。

[2023-01-31 16:32:34.117489] ERROR right_to_die_or_duty_to_live (ob_hang_fatal_error.cpp:37) [290927][T1006_TNT_L0_G0][T1006][Y243F0BA2DA34-0005F38A4673BD03-0-0] [lt=10][errcode=-4396] Worker thread pannic, thread may be terminated or hung(msg="Trying so hard to die", info={cur_sql:"delete from tbl_29 where not ( tbl_29.col_3465 != "{\"obj1\": {\"sub_obj0\":100}}" ) "......

OceanBase 数据库在后续版本已经尽量避免使用这种方式，但是仍然在类型，collation 比较过程中可能触发该问题。此时无法执行具体的操作并返回客户端具体的错误码，客户端的执行返回通常是超时报错。

解决方法

1. 收集日志。并且如果可能，尽快获取 obstack 的堆栈信息。最佳方式是获取 OBServer 的进程 core dump，可以通过如下命令获取。

   sudo kill -6 pgrep observer 
   

2. 重启节点可以临时解决这个问题。

更多信息

OceanBase 数据库做了租户的资源隔离，因此一个业务租户的 SQL 如果触发了 right_to_die_or_duty_to_live 那么很可能会不断重试。经过多次重试后，业务所有的租户线程全部被占用，导致无法正常连接和登录租户，系统其他租户是正常的。此过程中，需要找到问题并解决，否则重启后，副本 leader 切主，业务重试可能再次将另外一个节点的租户线程全部 hung 住。