MySQL8 中文参考（八十）（2）

MySQL8 中文参考（八十）（1）https://developer.aliyun.com/article/1565887

19.5.1.9 源表和副本表定义不同的复制

源表和目标表的复制不必完全相同。源表可以比副本表的副本具有更多或更少的列。此外，源表和副本的对应表列可以使用不同的数据类型，但必须满足一定条件。

注意

不支持不同分区的表之间的复制。参见 Section 19.5.1.24, “复制和分区”。

在所有源表和目标表定义不完全相同的情况下，数据库和表名必须在源表和副本上相同。在以下两个部分中讨论了其他条件，并给出了示例。

19.5.1.9.1 源表或副本表中有更多列的复制

可以将表从源复制到副本，使得源表和副本表的列数不同，但必须满足以下条件：

• 两个表共有的列必须在源表和副本上以相同顺序定义。（即使两个表具有相同数量的列也是如此。）
  
• 两个表共有的列必须在任何额外列之前定义。
  这意味着在副本上执行ALTER TABLE语句，向表中插入一个新列，该列位于两个表共有的列范围内，会导致复制失败，如下例所示：
  假设表t在源和副本上存在，并由以下CREATE TABLE语句定义：

CREATE TABLE t (
    c1 INT,
    c2 INT,
    c3 INT
);

• 假设在副本上执行了以下ALTER TABLE语句：

ALTER TABLE t ADD COLUMN cnew1 INT AFTER c3;

• 之前的ALTER TABLE在副本上是允许的，因为表t的两个版本中共有的列c1、c2和c3在任何不同的列之前都保持在一起。
  然而，在副本上执行以下ALTER TABLE语句会导致复制中断：

ALTER TABLE t ADD COLUMN cnew2 INT AFTER c2;

• 在副本上执行刚刚显示的ALTER TABLE语句后，复制失败，因为新列cnew2位于t两个版本共有的列之间。
• 在列更多的表版本中，每个“额外”列必须有一个默认值。
  列的默认值由多种因素决定，包括其类型、是否使用DEFAULT选项定义、是否声明为NULL，以及创建时服务器 SQL 模式的有效性；更多信息，请参见第 13.6 节，“数据类型默认值”）。
  

此外，当副本表比源表具有更多列时，两个表中共有的每一列必须在两个表中使用相同的数据类型。

示例。 以下示例说明了一些有效和无效的表定义：

源表中有更多列。 以下表定义是有效的，并且可以正确复制：

source> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
replica>  CREATE TABLE t1 (c1 INT, c2 INT);

下表定义会引发错误，因为两个版本表共有的列的定义在副本表上的顺序与源表上的顺序不同：

source> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
replica>  CREATE TABLE t1 (c2 INT, c1 INT);

下表定义也会引发错误，因为源表中额外列的定义出现在两个版本共有的列定义之前：

source> CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);
replica>  CREATE TABLE t1 (c1 INT, c2 INT);

副本表中有更多列。 以下表定义是有效的，并且可以正确复制：

source> CREATE TABLE t1 (c1 INT, c2 INT);
replica>  CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);

下列定义会引发错误，因为两个版本表共有的列在源表和副本表上的定义顺序不同：

source> CREATE TABLE t1 (c1 INT, c2 INT);
replica>  CREATE TABLE t1 (c2 INT, c1 INT, c3 INT);

下表定义也会引发错误，因为副本版本表中额外列的定义出现在两个版本共有的列定义之前：

source> CREATE TABLE t1 (c1 INT, c2 INT);
replica>  CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);

下表定义失败，因为副本版本表比源版本表多了额外列，并且两个版本的表对于共有列c2使用了不同的数据类型：

source> CREATE TABLE t1 (c1 INT, c2 BIGINT);
replica>  CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);

19.5.1.9.2 具有不同数据类型的列的复制

源表和副本表中相应的列的副本应该具有相同的数据类型。然而，并不总是严格执行这一规定，只要满足一定条件即可。

通常可以从具有特定数据类型的列复制到具有相同类型和大小或宽度的另一列，如适用，或更大的列。例如，可以从CHAR(10)列复制到另一个CHAR(10)列，或者从CHAR(10)列复制到CHAR(25)列而不会出现问题。在某些情况下，还可以从源表中具有一种数据类型的列复制到副本中具有不同数据类型的列；当源表中列的数据类型提升为副本中相同大小或更大的类型时，这称为属性提升。

属性提升可用于基于语句和基于行的复制，并且不依赖于源或副本使用的存储引擎。但是，日志格式的选择确实会影响允许的类型转换；具体内容将在本节后面讨论。

重要提示

无论您使用基于语句还是基于行的复制，如果希望使用属性提升，则副本表的副本不能包含比源表的副本更多的列。

基于语句的复制。 在使用基于语句的复制时，一个简单的经验法则是，“如果在源上运行的语句也可以在副本上成功执行，则它也应该成功复制”。换句话说，如果语句使用与副本上给定列类型兼容的值，则可以复制该语句。例如，您可以将适合TINYINT列的任何值插入到BIGINT列中；因此，即使您将副本表中的TINYINT列的类型更改为BIGINT，任何成功插入该列的源上的插入也应该在副本上成功，因为不可能有一个合法的TINYINT值大到足以超过BIGINT列。

基于行的复制：属性提升和降级。 基于行的复制支持较小数据类型和较大类型之间的属性提升和降级。还可以指定是否允许对降级列值进行有损（截断）或无损转换，如本节后面所述。

有损和无损转换。 在目标类型无法表示要插入的值的情况下，必须决定如何处理转换。如果我们允许转换但截断（或以其他方式修改）源值以在目标列中实现“适合”，我们进行的是所谓的有损转换。不需要截断或类似修改以使源列值适合目标列的转换是无损转换。

类型转换模式。 系统变量replica_type_conversions（从 MySQL 8.0.26 开始）或slave_type_conversions（在 MySQL 8.0.26 之前）的全局值控制副本上使用的类型转换模式。此变量接受以下列表中的一组值，描述了每种模式对副本的类型转换行为的影响：

ALL_LOSSY

在此模式下，允许会导致信息丢失的类型转换。

这并不意味着允许非损失转换，仅表示只允许需要损失转换或根本不需要转换的情况；例如，仅启用此模式允许将INT列转换为TINYINT（损失转换），但不允许将TINYINT列转换为INT列（非损失）。在这种情况下尝试后者的转换会导致副本停止并显示错误。

ALL_NON_LOSSY

此模式允许不需要截断或其他特殊处理源值的转换；也就是说，它允许目标类型的范围比源类型更宽的转换。

设置此模式不影响是否允许有损转换；这由ALL_LOSSY模式控制。如果只设置了ALL_NON_LOSSY，但没有设置ALL_LOSSY，那么尝试进行可能导致数据丢失的转换（例如INT到TINYINT，或CHAR(25)到VARCHAR(20)）会导致副本停止并显示错误。

ALL_LOSSY,ALL_NON_LOSSY

当设置此模式时，允许所有支持的类型转换，无论它们是否是有损转换。

ALL_SIGNED

将提升的整数类型视为有符号值（默认行为）。

ALL_UNSIGNED

将提升的整数类型视为无符号值。

ALL_SIGNED,ALL_UNSIGNED

尽可能将提升的整数类型视为有符号，否则视为无符号。

[空]

当未设置replica_type_conversions或slave_type_conversions时，不允许进行属性提升或降级；这意味着源表和目标表中的所有列必须是相同类型。

这是默认模式。

当整数类型被提升时，其符号性不会被保留。默认情况下，副本将所有这些值视为有符号的。您可以使用ALL_SIGNED、ALL_UNSIGNED或两者来控制此行为。ALL_SIGNED告诉副本将所有提升的整数类型视为有符号；ALL_UNSIGNED指示将其视为无符号。如果同时指定两者，副本将尽可能将值视为有符号，否则将视为无符号；它们列出的顺序并不重要。如果至少没有使用ALL_LOSSY或ALL_NONLOSSY中的一个，那么ALL_SIGNED和ALL_UNSIGNED都不会产生任何效果。

更改类型转换模式需要使用新的replica_type_conversions或slave_type_conversions设置重新启动副本。

支持的转换。 支持不同但相似数据类型之间的转换列在以下列表中：

• 在任何整数类型TINYINT，SMALLINT，MEDIUMINT，INT和BIGINT之间。
  这包括这些类型的有符号和无符号版本之间的转换。
  通过将源值截断为目标列允许的最大（或最小）值来进行有损转换。为了确保从无符号到有符号类型的非有损转换，目标列必须足够大，以容纳源列中的值范围。例如，您可以将TINYINT UNSIGNED非有损地降级为SMALLINT，但不能降级为TINYINT。
  
• 在任何十进制类型DECIMAL，FLOAT，DOUBLE和NUMERIC之间。
  FLOAT到DOUBLE是非有损转换；DOUBLE到FLOAT只能以有损方式处理。从DECIMAL(*M*,*D*)到DECIMAL(*M’*,*D’*)的转换，其中*D’* >= *D*和(*M’*-*D’*) >= (*M*-*D*)是非有损的；对于任何*M’* < *M*，*D’* < *D*，或两者都是的情况，只能进行有损转换。
  对于任何十进制类型，如果要存储的值无法适应目标类型，则根据文档中其他地方定义的服务器舍入规则将该值向下舍入。有关十进制类型的此类操作的详细信息，请参见第 14.24.4 节，“舍入行为”。
  
• 在任何字符串类型CHAR，VARCHAR和TEXT之间，包括不同宽度之间的转换。
  将CHAR，VARCHAR或TEXT转换为大小相同或更大的CHAR，VARCHAR或TEXT列永远不会有损。有损转换通过在副本上仅插入字符串的前*N个字符来处理，其中N*是目标列的宽度。
  重要提示
  不支持在使用不同字符集的列之间进行复制。
  
• 任意二进制数据类型BINARY，VARBINARY和BLOB之间的转换，包括不同宽度之间的转换。
  将BINARY，VARBINARY或BLOB转换为相同大小或更大的BINARY，VARBINARY或BLOB列永远不会有损失。有损转换通过仅在副本上插入字符串的前*N字节来处理，其中N*是目标列的宽度。
  
• 任意两个不同大小的BIT列之间。
  当将来自BIT(*M*)列的值插入到BIT(*M’*)列中，其中*M’* > *M*时，BIT(*M’*)列的最高有效位被清除（设置为零），而BIT(*M*)值的*M*位被设置为BIT(*M’*)列的最低有效位。
  当将来自源BIT(*M*)列的值插入到目标BIT(*M’*)列中，其中*M’* < *M*时，BIT(*M’*)列被赋予最大可能的值；换句话说，目标列被赋予“全置位”值。
  

类型转换不在前述列表中的类型是不允许的。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-directory.html

19.5.1.10 复制和 DIRECTORY 表选项

如果在源服务器的CREATE TABLE语句中使用了DATA DIRECTORY或INDEX DIRECTORY表选项，则该表选项也会在副本上使用。如果在副本主机文件系统中不存在相应的目录，或者存在但对副本 MySQL 服务器不可访问，则可能会出现问题。可以通过在副本上使用NO_DIR_IN_CREATE服务器 SQL 模式来覆盖此行为，这会导致副本在复制CREATE TABLE语句时忽略DATA DIRECTORY和INDEX DIRECTORY表选项。结果是MyISAM数据和索引文件将在表的数据库目录中创建。

查看更多信息，请参见第 7.1.11 节，“服务器 SQL 模式”。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-drop-if-exists.html

19.5.1.11 复制DROP ... IF EXISTS语句

DROP DATABASE IF EXISTS，DROP TABLE IF EXISTS和DROP VIEW IF EXISTS语句始终会被复制，即使要删除的数据库、表或视图在源上不存在。这是为了确保一旦副本赶上源，要删除的对象在源或副本上都不再存在。

DROP ... IF EXISTS 语句用于存储程序（存储过程和函数，触发器和事件），即使要删除的存储程序在源上不存在，也会被复制。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-floatvalues.html

19.5.1.12 复制和浮点值

在基于语句的复制中，值从十进制转换为二进制。由于十进制和二进制表示之间的转换可能是近似的，涉及浮点值的比较是不精确的。这对明确使用浮点值的操作，或者隐式转换为浮点的值都是适用的。由于计算机架构、用于构建  MySQL 的编译器等方面的差异，源服务器和副本服务器上对浮点值的比较可能产生不同的结果。参见第 14.3  节，“表达式评估中的类型转换”，以及第 B.3.4.8 节，“浮点值的问题”。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-flush.html

19.5.1.13 复制和 FLUSH

一些形式的FLUSH语句不会被记录，因为如果被复制到副本中可能会引起问题：FLUSH LOGS和FLUSH TABLES WITH READ LOCK。有关语法示例，请参见 Section 15.7.8.3, “FLUSH Statement”。FLUSH TABLES、ANALYZE TABLE、OPTIMIZE TABLE和REPAIR TABLE语句会被写入二进制日志，因此会被复制到副本中。通常这不是问题，因为这些语句不会修改表数据。

然而，在某些情况下，这种行为可能会引起困难。如果在mysql数据库中复制权限表并直接更新这些表而不使用GRANT，则必须在副本上发出FLUSH PRIVILEGES以使新权限生效。此外，如果在重命名作为MERGE表的MyISAM表时使用FLUSH TABLES，则必须在副本上手动发出FLUSH TABLES。除非指定NO_WRITE_TO_BINLOG或其别名LOCAL，否则这些语句将被写入二进制日志。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-functions.html

19.5.1.14 复制和系统函数

在某些情况下，某些函数无法很好地进行复制：

• USER()、CURRENT_USER()（或CURRENT_USER）、UUID()、VERSION()和LOAD_FILE()函数在复制时不会更改，因此在副本上无法可靠工作，除非启用了基于行的复制。（参见 Section 19.2.1, “复制格式”。）
  在MIXED模式下使用基于行的复制时，USER()和CURRENT_USER()会自动复制，并在STATEMENT模式下生成警告。（另请参阅 Section 19.5.1.8, “CURRENT_USER()的复制”的复制")。）对于VERSION()和RAND()也是如此。
  
• 对于NOW()，二进制日志包括时间戳。这意味着源上调用此函数返回的值会被复制到副本中。为了避免在不同时区的 MySQL 服务器之间复制时出现意外结果，请在源和副本上都设置时区。更多信息，请参见 Section 19.5.1.33, “复制和时区”。
  为了解释在不同时区的服务器之间复制时可能出现的问题，假设源位于纽约，副本位于斯德哥尔摩，两台服务器都使用当地时间。进一步假设，在源上，你创建了一个表mytable，对该表执行了一个INSERT语句，然后从表中选择，如下所示：

mysql> CREATE TABLE mytable (mycol TEXT);
Query OK, 0 rows affected (0.06 sec)
mysql> INSERT INTO mytable VALUES ( NOW() );
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM mytable;
+---------------------+
| mycol               |
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)

• 斯德哥尔摩的当地时间比纽约晚 6 小时；因此，如果你在副本上的确切时刻发出SELECT NOW()，将返回值2009-09-01 18:00:00。因此，如果在复制了刚刚显示的CREATE TABLE和INSERT语句之后，从副本的mytable复制，你可能期望mycol包含值2009-09-01 18:00:00。然而，事实并非如此；当你从副本的mytable复制时，你得到的结果与源上完全相同：

mysql> SELECT * FROM mytable;
+---------------------+
| mycol               |
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)

• 与NOW()不同，SYSDATE()函数不是复制安全的，因为它不受二进制日志中SET TIMESTAMP语句的影响，并且在使用基于语句的日志记录时是不确定的。如果使用基于行的日志记录，则不会出现问题。
  另一种选择是使用--sysdate-is-now选项，使SYSDATE()成为NOW()的别名。这必须在源和副本上都执行才能正常工作。在这种情况下，此函数仍会发出警告，但只要在源和副本上都使用--sysdate-is-now，就可以安全地忽略。
  当使用MIXED模式时，SYSDATE()会自动使用基于行的复制进行复制，并在STATEMENT模式下生成警告。
  另请参阅 Section 19.5.1.33, “Replication and Time Zones”。
• 以下限制仅适用于基于语句的复制，不适用于基于行的复制。 处理用户级锁的GET_LOCK()、RELEASE_LOCK()、IS_FREE_LOCK()和IS_USED_LOCK()函数在源上处理并在副本上不知道并发上下文。因此，这些函数不应用于插入源表，因为副本上的内容会有所不同。例如，不要发出类似INSERT INTO mytable VALUES(GET_LOCK(...))的语句。
  当使用MIXED模式时，这些函数会自动使用基于行的复制进行复制，并在STATEMENT模式下生成警告。
  

作为解决方案，当基于语句的复制生效时，您可以使用将有问题的函数结果保存在用户变量中，并在后续语句中引用该变量的策略。例如，以下单行INSERT由于引用UUID()函数而存在问题：

INSERT INTO t VALUES(UUID());

要解决这个问题，可以这样做��

SET @my_uuid = UUID();
INSERT INTO t VALUES(@my_uuid);

该序列的语句之所以能够复制，是因为@my_uuid的值作为用户变量事件存储在二进制日志中，先于INSERT语句，并且可以在INSERT中使用。

相同的思路也适用于多行插入，但使用起来更加繁琐。对于两行插入，您可以这样做：

SET @my_uuid1 = UUID(); @my_uuid2 = UUID();
INSERT INTO t VALUES(@my_uuid1),(@my_uuid2);

但是，如果行数很大或者未知，解决方法就会变得困难或者不可行。例如，你无法将以下语句转换为一个语句，其中一个给定的个人用户变量与每一行相关联：

INSERT INTO t2 SELECT UUID(), * FROM t1;

在存储函数中，RAND() 只要在函数执行过程中仅调用一次，就能正确复制。（你可以将函数执行时间戳和随机数种子视为在源和副本上相同的隐式输入。）

FOUND_ROWS() 和 ROW_COUNT() 函数在基于语句的复制中无法可靠复制。一个解决方法是将函数调用的结果存储在用户变量中，然后在 INSERT 语句中使用。例如，如果你希望将结果存储在名为 mytable 的表中，你可能会像这样做：

SELECT SQL_CALC_FOUND_ROWS FROM mytable LIMIT 1;
INSERT INTO mytable VALUES( FOUND_ROWS() );

但是，如果你正在复制 mytable，你应该使用 SELECT ... INTO，然后将变量存储在表中，就像这样：

SELECT SQL_CALC_FOUND_ROWS INTO @found_rows FROM mytable LIMIT 1;
INSERT INTO mytable VALUES(@found_rows);

这样，用户变量将作为上下文的一部分进行复制，并在副本上正确应用。

当使用 MIXED 模式时，这些函数会在基于行的复制中自动复制，并在 STATEMENT 模式下生成警告。（Bug #12092, Bug #30244）

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-fractional-seconds.html

19.5.1.15 复制和分数秒支持

MySQL 8.0 允许TIME、DATETIME和TIMESTAMP值使用微秒（6 位数字）精度的分数秒。请参见第 13.2.6 节，“时间值中的分数秒”。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-invoked.html

19.5.1.16 调用特性的复制

调用特性的复制，如可加载函数和存储程序（存储过程和函数、触发器和事件），提供以下特性：

• 特性的效果始终会被复制。
  
• 以下语句使用基于语句的复制进行复制：

• CREATE EVENT
  
• ALTER EVENT
  
• DROP EVENT
  
• CREATE PROCEDURE
  
• DROP PROCEDURE
  
• CREATE FUNCTION
  
• DROP FUNCTION
  
• CREATE TRIGGER
  
• DROP TRIGGER
  

• 但是，使用这些语句创建、修改或删除的特性的效果是使用基于行的复制进行复制的。
  注意
  尝试使用基于语句的复制复制调用特性会产生警告“Statement  is not safe to log in statement  format”。例如，尝试使用基于语句的复制复制可加载函数会生成此警告，因为当前无法由 MySQL  服务器确定函数是否是确定性的。如果您绝对确定调用特性的效果是确定性的，可以安全地忽略此类警告。
  
• 在CREATE EVENT和ALTER EVENT的情况下：

• 事件的状态在副本上设置为SLAVESIDE_DISABLED，无论指定的状态如何（这不适用于DROP EVENT）。
  
• 在副本上，通过其服务器 ID 标识创建事件的源。INFORMATION_SCHEMA.EVENTS中的ORIGINATOR列存储此信息。有关更多信息，请参见第 15.7.7.18 节，“SHOW EVENTS Statement”。
  

• 该功能的实现位于副本中，处于可更新状态，因此如果源失败，副本可以被用作源而不会丢失事件处理。
  

要确定在 MySQL 服务器上是否有任何在不同服务器（作为源服务器）上创建的计划事件，请以类似于此处所示的方式查询信息模式EVENTS表：

SELECT EVENT_SCHEMA, EVENT_NAME
    FROM INFORMATION_SCHEMA.EVENTS
    WHERE STATUS = 'SLAVESIDE_DISABLED';

或者，您可以使用SHOW EVENTS语句，如下所示：

SHOW EVENTS
    WHERE STATUS = 'SLAVESIDE_DISABLED';

将具有此类事件的副本升级为源时，必须使用ALTER EVENT *event_name* ENABLE来启用每个事件，其中*event_name*是事件的名称。

如果在创建此副本上的事件时涉及多个源，并且您希望识别仅在具有服务器 ID *source_id*的给定源上创建的事件，请修改前面在EVENTS表上的查询，包括ORIGINATOR列，如下所示：

SELECT EVENT_SCHEMA, EVENT_NAME, ORIGINATOR
    FROM INFORMATION_SCHEMA.EVENTS
    WHERE STATUS = 'SLAVESIDE_DISABLED'
    AND   ORIGINATOR = '*source_id*'

您可以以类似的方式使用SHOW EVENTS语句中的ORIGINATOR：

SHOW EVENTS
    WHERE STATUS = 'SLAVESIDE_DISABLED'
    AND   ORIGINATOR = '*source_id*'

在启用从源复制的事件之前，您应该在副本上禁用 MySQL 事件调度程序（使用类似于SET GLOBAL event_scheduler = OFF;的语句），运行任何必要的ALTER EVENT语句，重新启动服务器，然后在副本上重新启用事件调度程序（使用类似于SET GLOBAL event_scheduler = ON;的语句）-

如果稍后将新源重新降级为副本，则必须手动禁用由ALTER EVENT语句启用的所有事件。您可以通过在单独的表中存储先前显示的SELECT语句中的事件名称，或使用ALTER EVENT语句将事件重命名为具有replicated_前缀的公共前缀来执行此操作。

如果您重命名事件，那么在将此服务器重新降级为副本时，您可以通过查询EVENTS表来识别事件，如下所示：

SELECT CONCAT(EVENT_SCHEMA, '.', EVENT_NAME) AS 'Db.Event'
      FROM INFORMATION_SCHEMA.EVENTS
      WHERE INSTR(EVENT_NAME, 'replicated_') = 1;

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-json.html

19.5.1.17 JSON 文档的复制

在 MySQL 8.0 之前，对 JSON 列的更新始终被写入二进制日志作为完整文档。在 MySQL 8.0 中，可以记录 JSON 文档的部分更新（请参阅 JSON 值的部分更新），这更有效率。记录行为取决于所使用的格式，如下所述：

基于语句的复制。 JSON 部分更新始终被记录为部分更新。在使用基于语句的日志记录时，无法禁用此功能。

基于行的复制。 默认情况下，JSON 部分更新不会被记录为部分更新，而是被记录为完整文档。要启用部分更新的记录，请设置binlog_row_value_options=PARTIAL_JSON。如果复制源设置了此变量，则来自该源的部分更新将由副本处理和应用，而不管副本自身对该变量的设置如何。

运行 MySQL 8.0.2 或更早版本的服务器无法识别用于 JSON 部分更新的日志事件。因此，当从运行 MySQL 8.0.3 或更高版本的服务器复制到此类服务器时，必须通过将此变量设置为''（空字符串）在源端禁用binlog_row_value_options。有关更多信息，请参阅此变量的描述。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-limit.html

MySQL8 中文参考（八十）（3）https://developer.aliyun.com/article/1565889