observer 进程异常退出

问题排查思路

当正在运行的 OBServer 异常退出时，您通过操作系统（例如 ps -ef 命令）查询不到 observer 进程的存在。此时，如果不是硬件损坏或者操作系统的问题，可尝试拉起 observer 进程作为应急手段。

OBServer 在退出时会生成 core dump 文件，该文件通常比较大，可达几十 GB 甚至上百 GB，可以此为依据进行 OBServer 的异常退出根因分析。通常情况下，OBServer 可能是由于 signal 11（无效内存访问)、signal 6（进程放弃）等异常原因退出。因此在进行问题排查时一般考虑是由于 OBServer 本身的问题，或者操作系统或者底层的原因。

问题排查方法

在分析 OBServer 异常退出产生 core dump 问题的根因时，根据当前版本不同，排查的方法稍有差别，具体如下：

• V3.x 及以上的版本

  可直接分析 observer.log 。因为这些版本对诊断功能进行了增强。对于异常退出的场景，会直接在 observer.log 中打印携带 CRASH ERROR!!! 关键字的 call stack（也称 backtrace）的信息，这些信息里包含了 OBServer 异常退出的直接原因和问题现场。具体信息如下：

  CRASH ERROR!!! sig=11, sig_code=1, sig_addr=0x42, tid=27311, tname=test_context, 
  trace_id=Y0-0000000000000000, extra_info=((null)), lbt=0x58b9f0 0x58c00f 0x7fcb153fe61f
  0x4a1342 0x9fc8fb 0x9f66f5 0x9dc80e 0x9dd097 0x9dd727 0x9e3fdf 0x9fdcd9 0x9f74eb 0x9e2c1b
  0x4abcc0 0x4a801b 0x7fcb144b6444 0x4a1028 Segmentation fault (core dumped)
  

问题排查步骤

对于 observer 退出的根因，如果您无法判断为已知问题并可自行修复，需要您获取相关信息给到 OceanBase 技术支持人员进行根因分析。 若因 core 文件过大或者生产环境无法及时将文件传给相关人员，请先在问题现场对异常退出的 observer 进行初步诊断，其中最重要的是获取 OBServer 异常退出时的直接原因及退出线程的线程栈信息。

请您根据当前版本情况按照如下步骤进行分析。

1. V3.x 及以上的版本

   通过 OBServer 的可执行文件获取线程栈的 call stack 信息，或者调试 core 文件。如果 observer.log 里在进程退出时生成了 CRASH ERROR!!! 关键字，记录了 observer 线程异常退出的 call stack 重要信息 （'lbt=' 关键字后尾随的地址 hex 值），执行以下命令获取线程信息。

   addr2line -pCfe $observer $symbol_addr
   

   示例如下：

   addr2line -pCfe /home/admin/oceanbase/bin/observer 0x58b9f0 0x58c00f 0x7fcb153fe61f 0x4a1342 0x9fc8fb 0x9f66f5 0x9dc80e 0x9dd097 0x9dd727 0x9e3fdf 0x9fdcd9 0x9f74eb 0x9e2c1b 0x4abcc0 0x4a801b 0x7fcb144b6444 0x4a1028
   

   这里的信息包含 CRASH ERROR!!! 原始信息和打印的线程栈信息。

收集完以上信息后，请将包含进程退出的直接原因（signal 信息）、线程栈信息和 OBServer 的版本信息发送给 OceanBase 技术支持人员。