MySQL主从结构数据导入同步问题及解决方案咨询

问题1：大量已有备份文件导入后同步至从库的方法 #

除了手动删除备份中的SQL_LOG_BIN相关语句，还有两种高效的批量处理方式：

• 实时文本过滤（无需修改原文件）：用sed工具在导入时过滤掉禁用binlog的语句，避免修改原备份文件。单文件导入示例：

  sed '/SET @MYSQLDUMP_TEMP_LOG_BIN/d; /SET @@SESSION.SQL_LOG_BIN= 0;/d; /SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;/d' db.sql | mysql -u USER -p'PASS' db
  

  批量处理多个备份文件的shell循环：

  for sql_file in /path/to/backups/*.sql; do
    sed '/SET @MYSQLDUMP_TEMP_LOG_BIN/d; /SET @@SESSION.SQL_LOG_BIN= 0;/d; /SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;/d' "$sql_file" | mysql -u USER -p'PASS' db
  done
  

• 客户端参数强制覆盖（仅应急场景）：通过mysql客户端的--init-command提前设置会话sql_log_bin=1，但此方法可能被备份内的SET语句覆盖，可靠性不如文本过滤，示例：

  mysql -u USER -p'PASS' --init-command="SET @@SESSION.SQL_LOG_BIN=1;" db < db.sql
  

问题2：新导出备份避免同步问题的方法 #

当前导出脚本中，mysqldump自动生成禁用binlog的语句，是因为启用了GTID（默认--gtid-purged=AUTO），且mysqldump默认会临时关闭会话的binlog记录。修改脚本添加两个关键参数即可解决：

• --skip-disable-log-bin：禁止生成SET @@SESSION.SQL_LOG_BIN=0相关语句，确保导入主库的操作会被记录到binlog，同步至从库。
• --gtid-purged=OFF：避免写入原环境的GTID_PURGED信息，防止干扰新主从结构的GTID逻辑。

同时，脚本中原有的STOP SLAVE和START SLAVE是多余的——如果在主库导出，--single-transaction已通过快照保证数据一致性；如果在从库导出，只要从库只读且延迟正常，无需停止复制。修改后的脚本：

MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"

mysqldump ${MYSQL_CONN} --single-transaction --quick --skip-disable-log-bin --gtid-purged=OFF ${DB_NAME} 2> /dev/null > ${OUTPUT_PATH}/db.sql

问题3：不同环境GTID_PURGED的冲突问题及解决 #

会引发严重问题：GTID是全局唯一的事务标识，不同主从结构的GTID集合可能存在重叠（如server_uuid重复、GTID区间重叠），导入带有原环境GTID_PURGED的备份后：

• 若新环境已有相同GTID的事务，会触发“GTID already executed”错误，导致同步中断。
• 若新环境后续生成的GTID与原环境重叠，会导致从库跳过对应事务，引发数据不一致。

解决方法：

1. 导出阶段规避：在mysqldump时添加--gtid-purged=OFF（如问题2的修改），直接排除原环境的GTID信息。
2. 导入前清理：对已有备份，用sed过滤掉SET @@GLOBAL.GTID_PURGED相关行：

   sed '/SET @@GLOBAL.GTID_PURGED/d' db.sql | mysql -u USER -p'PASS' db
   

3. 新主从结构重置GTID：如果是全新搭建的主从，导入备份后可在主库执行RESET MASTER;重置GTID集合，再重新配置从库同步。

内容的提问来源于stack exchange，提问作者N_Z