异常现象

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

Image 404.png

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

image.png

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

定位合并异常 Server

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

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

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

  1. mysql> 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_version （ name 列值为 all_merged_version）的 Zone 的 value 列的值为 773，说明当前正在合并版本号为 773。

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

  1. 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"
  3. tbraid log | grep -E 'host IOs were blocked|I2C 4 cannot find idle bus'
  1. 内核原因。运行下述语句查看内核，若返回 task xxx blocked for more than 120 seconds 样式的信息则表示存在存在内核 Bug 导致 IO 异常：
  1. dmesg |grep blocked
  1. 网络因素。网卡异常时可以通过检查 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 节点的替换，详细操作信息，请参阅本手册 OBServer 管理 章节里的内容。

内部异常原因定位

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

  1. 内部宏块异常。内部宏块异常需要通过查询定位具体异常的 Partition，方法是将定位到的合并版本号（本示例中为上一小节中的定位到的版本号 773）代入下面的 SQL，这里需要区分不同的 OceanBase 版本：
  1. (1.x) select * from __all_meta_table where data_version != 773;
  3. (2.x) select * from __all_virtual_meta_table where data_version != 773;

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

  1. 参数配置异常。OceanBase 集群中也有控制集群合并的参数，如配置异常，也能引起合并失败。通过以下语句查看是否开启了手动合并参数，开启后只能通过手工合并命令进行合并，若返回值为 false 则表示正常：
  1. show parameters like '%enable_manual_merge%';

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

  1. 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';