异常现象

一般 OceanBase 集群合并出现异常时,在 OCP 中会触发 OCP 合并超时或合并错误告警,告警信息如下图所示:

Image 404.png

同时 OceanBase 数据库日志监控中也会出现类似合并相关的错误,告警信息如下图所示:

image.png

收到合并异常告警后,管理员可登录对应告警对象的 OceanBase 集群的 sys 租户进行具体原因定位。

定位合并异常 Server

登录至 sys 租户后,可通过查询 __all_zone 表查看合并状态并定位到具体合并失败 Zone,示例语句如下所示:

  1. obclient> SELECT * FROM __all_zone WHERE name IN ('merge_status','all_merged_version');

当集群处于正常合并状态时,查询结果将如下所示:

  1. obclient> SELECT * FROM __all_zone WHERE name IN ('merge_status','all_merged_version');
  2. +----------------------------+----------------------------+---------+--------------------+-------+---------+
  3. | gmt_create | gmt_modified | zone | name | value | info |
  4. +----------------------------+----------------------------+---------+--------------------+-------+---------+
  5. | 2019-06-24 11:19:00.559234 | 2020-02-18 14:02:28.997661 | | merge_status | 1 | MERGING |
  6. | 2019-08-28 13:34:31.182559 | 2020-02-18 08:48:28.447141 | ET15_10 | all_merged_version | 773 | |
  7. | 2019-08-28 13:34:31.182986 | 2020-02-18 14:02:31.640651 | ET15_10 | merge_status | 1 | MERGING |
  8. | 2019-08-28 14:37:25.685870 | 2020-02-18 08:40:52.009764 | ET15_11 | all_merged_version | 773 | |
  9. | 2019-08-28 14:37:25.686322 | 2020-02-18 14:02:31.643109 | ET15_11 | merge_status | 1 | MERGING |
  10. | 2019-08-28 13:33:17.273600 | 2020-02-18 08:30:00.087549 | ET15_9 | all_merged_version | 773 | |
  11. | 2019-08-28 13:33:17.273964 | 2020-02-18 14:02:31.645466 | ET15_9 | merge_status | 1 | MERGING |
  12. +----------------------------+----------------------------+---------+--------------------+-------+---------+

当集群中某个 Zone 发生合并异常,对应 Zone 的 info 列的值为 TIMEOUT ,同时可以看到当前合并版本为 all_merged_versionname 列值为 all_merged_version)的 Zone 的 value 列的值为 773,说明当前正在合并版本号为 773。

将版本号 773 代入下面用来查询合并进度的 SQL 语句的 WHERE 条件 major_version 中,即可定位到合并异常 Server 的地址,此查询结果中 svr_ip 的值即为合并异常服务器 IP 地址。示例语句如下所示:

  1. obclient> SELECT zone, svr_ip, major_version, macro_block_count, use_old_macro_block_count
  2. , merge_start_time, merge_finish_time, merge_process, merge_finish_time - merge_start_time AS cost_time
  3. , macro_block_count - use_old_macro_block_count AS merge_macro_block_count
  4. , (macro_block_count - use_old_macro_block_count) / (merge_finish_time - merge_start_time) AS avg_per_sec
  5. FROM __all_virtual_partition_sstable_image_info
  6. WHERE major_version = 773
  7. AND merge_process <> 100
  8. ORDER BY zone, svr_ip, major_version;

异常原因定位

Server 异常原因定位

找到合并异常服务器 IP 后,需要先通过 SSH 登录到服务器上,排查问题是否为主机硬件或软件引起的异常,通常可对以下原因逐个进行排查:

  1. IO 性能偏低。

    合并 IO 等待超时,可以通过命令 iostat -x -k 1 进行检查,如果 IO 使用率为 100%,则会影响合并。

  2. 磁盘已满。

    此时将无法写入新数据,数据将无法写入 /home/admin/oceanbase/log、Clog 目录 、容器化的 Docker 目录这些目录下,可以通过命令 df -lh 检查磁盘空间。

  3. 硬件故障。

    运行下述语句查看硬件故障,若有返回值表示存在硬件异常:

    1. dmesg|grep -E "Failed status, reset controller|Controller encountered a fatal error and was reset|Controller encountered a fatal error and was reset"

    如果是 RAID 卡的机器,也可以通过以下命令进行检查,若有返回值则表示 RAID 卡有异常:

    1. tbraid log | grep -E "Read Medium ERR|Error"
    2. tbraid log | grep -E 'host IOs were blocked|I2C 4 cannot find idle bus'
  4. 内核原因。

    运行下述语句查看内核,若返回 task xxx blocked for more than 120 seconds 样式的信息则表示存在存在内核 Bug 导致 IO 异常:

    1. dmesg |grep blocked
  5. 网络因素。

    网卡异常时可以通过检查 Message 日志或者运行 TSAR 命令,如果出现如下所示异常则表明是网络因素:

    1. May 26 04:34:23 db142151114.na62 lldpd[67883]: iface_eth_recv: error while receiving frame on eno1: Network is down
    2. May 26 04:34:23 db142151114.na62 lldpd[67883]: iface_eth_recv: error while receiving frame on eno2: Network is down
    3. May 26 04:34:23 db142151114.na62 lldpd[67883]: iface_eth_recv: error while receiving frame on enp7s0f0: Network is down
    4. May 26 04:34:23 db142151114.na62 lldpd[67883]: iface_eth_recv: error while receiving frame on enp7s0f1: Network is down

    如果存在上述原因中的一项或多项,您可以联系我们的运维人员帮您解决异常。例如,涉及服务器替换操作,则需要进行 OBServer 节点的替换。

内部异常原因定位

除了上述由服务器本身导致的异常引起合并异常外,OceanBase 集群在运行中也可能由于网络抖动、IO 超时、参数配置等原因导致内部处理异常从而导致合并异常,您可以对以下原因逐个进行排查:

  1. 内部宏块异常。

    内部宏块异常需要通过查询定位具体异常的 Partition,方法是将定位到的合并版本号(本示例中为上一小节中的定位到的版本号 773)代入下面的 SQL,这里需要区分不同的 OceanBase 数据库版本:

    • V1.x 版本

      1. obclient> SELECT * FROM __all_meta_table WHERE data_version != 773;
    • V2.x 版本

      1. obclient> SELECT * FROM __all_virtual_meta_table WHERE data_version != 773;

      返回结果即为当前处于合并异常的 Partition 信息,包括其所在 Server 的 IP 地址和 Zone 等信息。

  2. 参数配置异常。

    OceanBase 集群中也有控制集群合并的参数,例如配置异常,也能引起合并失败。

    通过以下语句查看是否开启了手动合并参数,开启后只能通过手工合并命令进行合并,若返回值为 false 则表示正常:

    1. obclient> SHOW PARAMETERS LIKE '%enable_manual_merge%';

    通过以下语句查看是否开启升级参数,开启后所有合并均被 Block,若返回值为 false 则表示正常:

    1. obclient> SHOW PARAMETERS LIKE '%enable_upgrade%';

解决方案

上述两种异常原因它们的解决方案也不同。

Server 异常解决方案

  • 对于 Server 间歇性异常来说,此类异常一般都是瞬时性的,在确保异常不会再次出现后,可先对异常 Server 进行 STOP SERVER 操作,然后对 OBServer 进行重启。详细操作信息,请参见本手册 OBServer 管理 章节。

  • 对于 Server 持续性异常来说,此类异常一般在出现后会一直保持,需要运维人员对故障 Server 进行下线维修。下线前用户需要先对异常 Server 进行 STOP SERVER 操作,然后对 OBServer 进行替换操作。详细操作信息,请参见本手册 OBServer 管理 章节。

内部异常

  • 对于内部宏块异常来说,此类异常处理方式类似于 Server 间歇性异常。需要先对异常 Server 进行 STOP SERVER 操作,然后对 OBServer 进行重启。详细操作信息,请参见本手册 OBServer 管理 章节。

  • 对于参数配置异常来说,此类异常一般通过 ALTER 操作,将异常参数配置正常即可立即恢复,以下为示例语句:

    1. ALTER SYSTEM SET `parameter_name`= 'True';