当前位置：首页 > 问答 > 正文

MySQL报错MY-013101，ER_BINLOG_ROW_VALUE_OPTION_IGNORED导致故障，远程帮忙修复方案分享

歧云亭
问答
2026-01-01 19:55:29
4

MySQL报错MY-013101，这个错误编号对应的内部错误代码是ER_BINLOG_ROW_VALUE_OPTION_IGNORED，这个错误本身通常不会直接导致数据库服务崩溃之类的严重故障，但它是一个非常重要的警告信号，表明数据库的复制（Replication）机制可能没有按照您预期的方式工作，如果被忽略,最终会引发主从数据库数据不一致的严重故障。

错误含义浅析

这个错误发生在MySQL的主从复制环境中，当主数据库（Master）将数据的变更写入到一种叫做“二进制日志（binlog）”的文件中时，它会记录下变更的具体内容，从数据库（Slave）会读取这个日志，然后在自己的数据库上重放这些操作,从而保持和主数据库一致。

MySQL提供了几种记录变更的方式，其中一种最常用的、能最大限度保证数据一致性的方式叫做“行格式（Row-Based Replication, RBR）”，在这种格式下，binlog记录的不仅仅是执行的SQL语句,而是数据行在变更前和变更后的具体值。

错误ER_BINLOG_ROW_VALUE_OPTION_IGNORED的意思是：您在主数据库上设置了一些关于“如何记录binlog”的选项，但是这些选项在当前情况下被忽略了,没有被实际采用。

导致错误和故障的常见场景

根据MySQL官方文档和社区常见问题汇总，以下几种情况会触发这个错误,并可能埋下数据不一致的隐患：

设置了部分日志选项（binlog_row_value_options）：这是一个MySQL的系统变量，您可能将它设置成了PARTIAL_JSON，这个选项的目的是为了优化对JSON类型数据的日志记录，当更新一个非常大的JSON字段时，如果只修改了其中一小部分，使用PARTIAL_JSON可以只在binlog里记录被修改的那部分，而不是整个JSON文档,从而节省磁盘空间和网络带宽。
- 为什么被忽略：这个PARTIAL_JSON优化功能只有在同时满足以下两个条件时才会生效：
  - binlog格式必须是ROW。
  - 必须使用“完整行镜像”（即binlog_row_image设置为FULL）。
- 故障风险：如果您将binlog_row_image设置成了MINIMAL（它只记录被更改的列以及唯一标识该行的列），那么即使您设置了binlog_row_value_options=PARTIAL_JSON，MySQL也会忽略这个PARTIAL_JSON设置，转而采用MINIMAL的方式记录，并抛出MY-013101警告，如果从库期望接收到部分JSON更新但实际上收到了最小行镜像,在某些复杂情况下可能导致复制中断或数据错误。
表结构不支持：即使您的设置完全正确（binlog_format=ROW且binlog_row_image=FULL），如果您要操作的表没有主键，或者缺乏有效的唯一索引，MySQL为了保证复制的安全性，也可能无法使用部分日志功能，从而忽略该选项并报出此警告，因为没有唯一标识,精确复制会变得困难。

远程帮忙修复方案分享

当在日志中发现这个错误时，修复的核心思路是：确保您的binlog相关配置是自洽的，并且符合您的业务需求。 以下是逐步排查和修复的方案：

第一步：确认当前配置

远程连接上出现问题的MySQL主库服务器，执行以下SQL语句,查看当前的配置状态：

SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';
SHOW VARIABLES LIKE 'binlog_row_value_options';

记录下这三个变量的值。

MySQL报错MY-013101，ER_BINLOG_ROW_VALUE_OPTION_IGNORED导致故障，远程帮忙修复方案分享

第二步：分析和调整配置（根据第一步的结果决定）

场景A：您确实需要PARTIAL_JSON优化
- 检查：如果binlog_row_value_options的值是PARTIAL_JSON，但binlog_row_image的值是MINIMAL或NOBLOB。
- 修复：您需要将binlog_row_image设置为FULL。
  - 在线修改（重启后失效）：SET GLOBAL binlog_row_image = 'FULL';
  - 永久修改：编辑MySQL配置文件（如my.cnf或my.ini），在[mysqld]段落下添加或修改：binlog_row_image = FULL,然后重启MySQL服务使配置永久生效。
- 注意：改为FULL会增加binlog日志的大小,请确保磁盘空间充足。
场景B：您不需要PARTIAL_JSON优化
- 检查：如果您不确定PARTIAL_JSON的作用,或者您的业务中没有频繁更新大JSON字段的需求。
- 修复：最简单的办法是关闭这个选项，避免不必要的警告。
  - 在线修改：SET GLOBAL binlog_row_value_options = '';
  - 永久修改：在配置文件中设置binlog_row_value_options = ‘’ 或直接注释掉该行,然后重启MySQL。
场景C：检查表结构
- 检查：即使配置正确也报错，请检查操作所涉及的表是否定义了主键（Primary Key）或非空的唯一索引（Unique Key）。
- 修复：为表添加主键，这是数据库设计的最佳实践,对复制性能和数据一致性都至关重要。

第三步：验证修复结果

完成配置调整后，在主库上执行一个会触发此警告的SQL操作（比如更新一个JSON字段）。
查看MySQL的错误日志（error log），确认MY-013101错误是否已经不再出现。
密切观察从库的复制状态，在从库上执行 SHOW SLAVE STATUS\G，检查Slave_IO_Running和Slave_SQL_Running是否均为Yes，以及Seconds_Behind_Master参数是否显示为0或一个很小的数字,这表示主从复制是正常且同步的。

MY-013101错误是一个“配置不匹配”的警告，远程修复的关键在于通过查看系统变量，理解各个变量之间的依赖关系，然后做出正确的调整，对于绝大多数追求稳定性的业务来说，如果不需要PARTIAL_JSON的特定优化，直接禁用它是最简单稳妥的办法，如果需要该优化，则必须保证配套设置binlog_row_image=FULL，无论哪种情况，确保所有数据表都有主键，是避免许多复制问题的根本前提，处理完毕后，一定要持续监控主从复制的状态,确保数据一致性这一最终目标得以实现。

引用来源说明： 以上分析和解决方案基于MySQL官方文档中关于“二进制日志记录”和“系统变量”的章节，以及Percona、MySQL官方论坛等社区中关于ER_BINLOG_ROW_VALUE_OPTION_IGNORED错误代码的实际案例讨论。