OceanBase 数据库 V3.x 版本 replay checksum error（日志回放报错 -4103）问题的原因及解决方法

问题现象

用户在使用 OceanBase 数据库的过程中系统日志报错（OCP 告警）MT_CTX: replay checksum error，可能伴随着悬挂事务，Follower 日志回放卡住，主备库间日志不同步等不同现象。尝试重启也会持续失败，系统日志会报错 replay has encount fatal error 并且报错 error_ret:=4103。

关键信息

• 悬挂事务、Follower 节点日志回放卡住，主备库中备库日志回放卡住等情况，导致系统持续不健康，日志 error 告警，关键报错信息为。

  MT_CTX: replay checksum error
  

• 如果日志回放校验失败后再进行重启，会导致重启失败，并且报错。

  replay has encount fatal error 并且报错 error_ret:=4103
  

通常情况下，如果系统存在日志回放 checksum 校验不通过的问题，系统出现事务悬挂等不健康，日志长时间不同步，并且伴随着大量 ERROR 日志告警的情况下，现场可能会尝试重启，这时候会导致重启失败。仍然无法恢复系统的可用行。

问题原因

OceanBase 数据库从 V2.x 版本开始增加了日志回放（replay log）阶段的 checksum 校验机制。这种校验本质是将回放日志后的数据与原数据进行 checksum 校验，使得 OceanBase 数据库在日志回放阶段就有能力对可能造成数据正确性操作进行防御、报错。日志回放失败的结果对可能的更严重的问题进行拦截。当 OceanBase replay checksum 发现日志回放不一致时，可能会导致如下情况。

• 悬挂事务、Follower 节点日志回放卡住，主备库中备库日志回放卡住等情况，导致系统持续不健康，日志 error 告警，关键报错信息为。

  MT_CTX: replay checksum error
  

• 如果日志回放校验失败后再进行重启，会导致重启失败，并且报错。

  replay has encount fatal error  并且报错 error_ret:=4103
  

通常情况下，如果系统存在日志回放 checksum 校验不通过的问题，系统出现事务悬挂等不健康，日志长时间不同步，并且伴随着大量 ERROR 日志告警的情况下，现场可能会尝试重启，这时候会导致重启失败。仍然无法恢复系统的可用行。

OceanBase 数据库在 V2.x 版本设计日志回放校验机制时，事务模型还相对简单。随着产品复杂度不断提升，比如包括大事务、PDML 场景等更多事务模型的丰富，原始的日志回放校验机制出现了一些不适配的情况，导致数据本身是正确的，但是 replay log checksum 报错 4103，最终系统不可用。在这种场景下，可以尝试 ignore_replay_checksum_error=true 来恢复系统可用性的。这个参数控制系统可以跳过日志回放校验的逻辑继续运行。

OceanBase 数据库 V3.x 版本有已知的 insert ignore 使用场景会造成正确性的问题 （OceanBase 数据库 V3.x 版本 insert ignore 已知问题及风险-正确性问题），如果正在使用存在问题的 OBServer 版本，且业务中使用了 insert ignore 的用法，建议绕过 insert ignore 的用法并且尽快升级到修复的版本。如果没有任何其他已知的问题，当 OceanBase 数据库 V3.x 版本遇到 replay log checksum error 时，可以尝试配置 ignore_replay_checksum_error=true 来应急恢复系统的可用性。如果系统恢复后，正常运行，且没有数据层的 4103 报错（典型的如在合并时发起的 checksum 校验），那么基本上说明数据是正确的，并不存在实质的风险。 但是如果系统仍然出现问题，需要保存数据现场和系统日志现场，并联系 OceanBase 数据库技术支持。

OceanBase 数据库 V4.x 版本从设计之初就增强了日志回放 checksum 校验对更复杂的事务模型的适配，校验的逻辑是正确有效的。OceanBase 数据库 V4.x 版本维持 OBServer 内核的默认行为即可。不建议改动。 如果遇到日志回放 checksum 报错 4103，请联系 OceanBase 数据库技术支持解决问题。

关于打开 ignore_replay_checksum_error（关闭日志回放校验）的影响，需要解释的是 OceanBase 数据库的正确性防御机制：OBServer 内核在合并时会执行存储层的正确性校验，如果有非预期的存储层校验结果，会报错 -4103。常见的合并时存储层校验 4103 报错有如主表和索引表不一致，Leader 副本与 Follower 副本不一致等等。存储层的一致性（正确性）校验是滞后的。如果关闭了 ignore_replay_checksum_error，有可能在日志回放阶段防御的正确问题会滞后到合并数据校验时发生。OceanBase 数据库 V3.x 版本已经把已知的，可以导致日志回放校验报错的问题进行了修复，理论上内核 BUG 引发的正确性问题导致日志回放阶段 checksum error 的场景是非常少的。另外 OceanBase 数据库相对比较新的版本（如 V3.1.2 BP5 及之后版本）在执行 DML 的时候就会校验数据的正确性，如有非预期的校验结果会直接报错 -4377 中断执行，也从更多的使用场景上增加了正确性风险的拦截和防御机制。OceanBase 数据库内核也在持续地清除正确性问题的风险。

问题的风险及影响

悬挂事务、Follower 节点日志回放卡住，主备库中备库日志回放卡住等情况，导致系统持续不健康，日志 ERROR 告警，现场可能会尝试重启，这时候会导致重启失败。仍然无法恢复系统的可用行

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

适用版本

OceanBase 数据库 V3.x 版本。

解决方法

OceanBase 数据库 V3.x 版本，如果不是已知问题（如上述提到的 insert ignore 问题），可以尝试通过配置 ignore_replay_checksum_error=true 来应急恢复系统的可用性。如果系统恢复后，正常运行，且没有数据层的4103报错（典型的如在合并时发起的 checksum 校验），那么基本上说明数据是正确的，并不存在实质的风险。 但是如果系统仍然出现问题，需要保存数据现场，并联系 OceanBase 数据库技术支持。

OceanBase 数据库 V4.x 版本，如果遇到日志回放 checksum 报错 4103，请联系 OceanBase 数据库技术支持解决问题。