mysql迁移时使用复制架构进行数据同步与高可用

mysql主从复制配置前必须检查的5个点：server_id全局唯一且非零；主库binlog_format=ROW；主库log-bin已启用且路径可写；从库relay_log路径有写权限且磁盘空间充足；主从时区一致。

MySQL主从复制配置前必须检查的5个点

不校验这些，同步延迟或中断几乎必然发生。

• server_id 必须全局唯一，且不能为 0 或空字符串；主从若重复，从库启动 IO_THREAD 会静默失败
• 主库必须开启 binlog_format = ROW（尤其涉及 jsON、生成列、时间戳默认值时，STATEMENT 模式会丢数据或报错）
• 主库 my.cnf 中确认已启用 log-bin，且路径可写；常见错误是只写了 log-bin 没给文件名，导致实际未启用
• 从库 relay_log 路径需有写权限，且磁盘剩余空间 ≥ 主库日志峰值日增长量 × 2，否则 SQL_THREAD 会卡住
• 主从时区必须一致：select @@time_zone; 应返回相同结果；否则 timestamp 类型字段在复制中会偏移

mysqldump + binlog position 同步的实操要点

这是迁移初期最可控的方式，但位置定位稍有偏差就会导致从库数据不一致。

• 主库执行 FLUSH tableS WITH READ LOCK; 后，立刻运行 SHOW MASTER STATUS; 记下 File 和 Position —— 这两个值必须和后续 mysqldump 的 --master-data=2 输出严格对应
• mysqldump 命令必须加 --single-transaction --skip-lock-tables（InnoDB 表），否则锁表时间过长；但注意：该组合对非事务表（如 MyISAM）仍会锁表
• 恢复到从库前，先停掉 slave：STOP SLAVE;，再 source dump 文件；否则可能因 GTID 冲突或主键重复中断
• 导入完成后，用 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=198765432; 精确指定起点，不要依赖 dump 文件里的注释行（它可能被编辑器意外截断）

GTID 模式下常见的同步中断原因与修复

启用 gtid_mode=ON 后，传统 position 方式失效，错误处理逻辑完全不同。

• 从库报错 Could not execute Write_rows_v1 Event on table xxx; Duplicate entry '123' for key 'PRIMARY'，说明主库有重复写入，但从库已存在该记录 —— 此时不能跳过事务（SET GLOBAL sql_slave_skip_counter = 1 无效），必须用 SET GTID_NEXT='xxx-yyy-zzz:12345'; BEGIN; COMMIT; 注入空事务绕过
• 主库执行了 DROP database 后又重建同名库，从库可能因 GTID 已执行过而拒绝重建语句；需确认 SELECT * FROM mysql.gtid_executed WHERE source_uuid = 'xxx' AND interval_start = 12345; 是否覆盖该事务
• 切换主库后，新主库的 gtid_purged 若不包含旧主库已执行的部分，从库会报 Cannot replicate because the master purged required binary logs；此时需用 RESET MASTER; 清空新主库 GTID 集合，再手动 SET GTID_PURGED 补全

半同步复制（semisync）开启后性能掉得厉害怎么办

不是所有场景都适合开半同步，它本质是以延迟换一致性。

• 确认插件已加载：SELECT plugin_name, plugin_status FROM information_schema.plugins WHERE plugin_name LIKE '%semisync%'; —— 若状态为 DISABLED，需在 my.cnf 加 plugin_load_add = 'semisync_master.so;semisync_slave.so'
• 主库设置 rpl_semi_sync_master_timeout = 1000000（单位微秒，即 1 秒），避免单个从库响应慢拖垮全部写入；超时后自动退化为异步，不影响可用性
• 从库仅需启用 rpl_semi_sync_slave_enabled = ON，无需设超时；但必须确保网络抖动时，主库能及时感知从库离线（靠 rpl_semi_sync_master_wait_for_slave_count 控制等待几个从库响应）
• 监控关键指标：SHOW STATUS LIKE 'Rpl_semi_sync%'; 中 Rpl_semi_sync_master_yes_tx / Rpl_semi_sync_master_no_tx 比值持续低于 0.9，说明半同步实效性差，建议关掉或换为 MGR

-- 检查半同步当前状态的常用命令 SHOW VARIABLES LIKE 'rpl_semi_sync%'; SHOW STATUS LIKE 'Rpl_semi_sync%'; SELECT * FROM performance_schema.replication_connection_statusG

GTID 切换、半同步超时阈值、binlog 格式选择——这些不是“配完就完”的开关，而是要随业务写负载、网络质量、故障恢复预期动态调整的参数。漏掉任意一个细节，都可能让高可用变成高不可用。