如果语句在源和副本上都产生了相同的错误(相同的错误代码),则会记录该错误,但复制将继续。
如果语句在源和副本上产生了不同的错误,则复制 SQL 线程将终止,副本会将其错误信息写入其错误日志,并等待数据库管理员决定如何处理该错误。这包括语句在源或副本上产生错误,但在两者上都没有产生错误的情况。要解决此问题,请手动连接到副本并确定问题的根源。 SHOW REPLICA STATUS
对此很有用。然后修复问题并运行 START REPLICA
。例如,您可能需要在重新启动副本之前创建不存在的表。
如果副本的错误日志中记录了临时错误,则您不一定需要执行引用的错误信息中建议的任何操作。临时错误应由客户端重试事务来处理。例如,如果复制 SQL 线程记录了与死锁相关的临时错误,则您无需在副本上手动重新启动事务,除非复制 SQL 线程随后终止并显示非临时错误信息。
如果此错误代码验证行为不可取,则可以使用 --replica-skip-errors
选项屏蔽(忽略)部分或所有错误。
对于 MyISAM
等非事务性存储引擎,可能存在只部分更新表并返回错误代码的语句。例如,这可能发生在多行插入中,其中一行违反了键约束,或者如果长更新语句在更新部分行后被终止。如果这在源上发生,副本预计语句的执行将导致相同的错误代码。如果没有,则复制 SQL 线程将停止,如前所述。
如果您在源和副本上使用不同存储引擎的表之间进行复制,请记住,相同的语句在对表的某个版本运行时可能会产生不同的错误,而在对另一个版本运行时则不会产生错误,或者可能会对表的某个版本产生错误,而对另一个版本则不会产生错误。例如,由于 MyISAM
忽略外键约束,因此在源上访问 InnoDB
表的 INSERT
或 UPDATE
语句可能会导致外键冲突,但相同语句在副本上的 MyISAM
版本上执行不会产生此错误,从而导致复制停止。
复制过滤器规则在进行任何权限或行格式检查之前首先应用,这使得可以过滤掉任何验证失败的事务;对于被过滤掉的事务,不会执行任何检查,因此不会引发任何错误。这意味着副本只能接受授予给定用户访问权限的数据库的那一部分(只要对数据库这部分的任何更新使用基于行的复制格式)。这在执行升级或迁移到使用入站复制用户没有访问权限的管理表的系统或应用程序时可能很有用。另请参见 第 19.2.5 节,“服务器如何评估复制过滤规则”.