16.4.1.37 复制和变量
使用STATEMENT模式时，系统变量不能正确复制，但以下变量与会话范围一起使用时除外：
当使用MIXED模式时，上一列 table 中的变量与会话作用域一起使用时，会导致从基于语句的日志记录切换到基于行的日志记录。参见第 5.4.4.3 节“混合二进制日志记录格式”。
sql_mode也被复制，但NO_DIR_IN_CREATE模式除外；副本始终保留自己的NO_DIR_IN_CREATE值，而不管源上对其进行的更改如何。所有复制格式都是如此。
但是，当mysqlbinlog解析SET @@sql_mode = mode语句时，包括NO_DIR_IN_CREATE在内的完整* mode *值将传递到接收服务器。因此，在使用STATEMENT模式时，复制这样的语句可能并不安全。
不管日志记录模式如何，都不会复制default_storage_engine和storage_engine系统变量。这旨在促进不同存储引擎之间的复制。
read_only系统变量未复制。此外，启用此变量对临时 table，table 锁定和不同 MySQL 版本中的SET PASSWORD语句有不同的影响。
max_heap_table_size系统变量未复制。尝试在源文件的MEMORYtable 上执行INSERT语句时，如果不对副本数据库执行此操作，而在副本服务器上执行此操作，则最终导致副本上的 Table is full error，从而导致该 table 的完全错误，从而允许该变量的大小大于副本服务器上的对应变量。复制品。有关更多信息，请参见第 16.4.1.20 节“复制和内存 table”。
在基于语句的复制中，会话变量在更新 table 的语句中使用时无法正确复制。例如，以下语句序列将不会在源和副本上插入相同的数据：
SET max_join_size=1000;
INSERT INTO mytable VALUES(@@max_join_size);
这不适用于通用序列：
SET time_zone=...;
INSERT INTO mytable VALUES(CONVERT_TZ(..., ..., @@time_zone));
使用基于行的复制时，会话变量的复制不是问题，在这种情况下，会话变量始终被安全地复制。参见第 16.2.1 节“复制格式”。
以下会话变量将被写入二进制日志，并且在解析二进制日志时，副本将使用以下会话变量，而与日志记录格式无关：
Important
即使将与字符集和归类相关的会话变量写入二进制日志，也不支持不同字符集之间的复制。
为了帮助减少可能的混乱，我们建议您始终对源和副本上的lower_case_table_names系统变量使用相同的设置，尤其是在具有区分大小写的文件系统的平台上运行 MySQL 时。
