mysql主从复制+定时逻辑备份可同时解决服务连续性与数据安全性问题：复制保障故障秒级切换，备份防误删、DDL事故及binlog purge，二者结合覆盖高可用与可恢复双重需求。
MySQL 主从复制 + 定时逻辑备份能解决什么问题
单靠主从复制不能防误删、防 DDL 事故、防 binlog 被意外 purge；单靠 mysqldump 或 mydumper 备份又无法应对主库宕机时的秒级切换。二者结合，才能覆盖「故障切换」和「数据可恢复」两个维度——复制保障服务连续性，备份兜底数据安全性。
主从复制必须启用 GTID 和半同步
没有 GTID，failover 时找位点易出错；不开启半同步（rpl_semi_sync_master_enabled=ON），主库 crash 后可能丢失已提交事务。这是很多线上环境忽略的关键配置。
实操建议：
- 主库和从库都设
gtid_mode=ON、enforce_gtid_consistency=ON - 安装半同步插件：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'（从库对应装semisync_slave） - 确认状态：
SHOW VARIABLES LIKE '%semi%';和SHOW STATUS LIKE 'Rpl_semi_sync%';都应返回ON - 避免把
sync_binlog=1和innodb_flush_log_at_trx_commit=1同时关闭，否则半同步失去意义
逻辑备份必须包含 –set-gtid-purged=OFF 或 –skip-gtids
用 mysqldump 做从库备份时，若导出文件含 SET @@GLOBAL.GTID_PURGED，恢复到新实例会因 GTID 冲突导致复制中断。常见错误现象是 Slave_SQL_Running_State: Waiting for dependent transaction to commit 或直接报错 Could not execute Write_rows Event on table... Duplicate entry for key 'PRIMARY'。
正确做法：
- 备份命令加
--set-gtid-purged=OFF（MySQL 5.7.6+）或--skip-gtids（MySQL 5.7.9+） - 不要在备份脚本里写
--master-data=2（它会强制写 GTID_PURGED） - 备份后校验：打开 dump 文件，确认开头没有
SET @@GLOBAL.GTID_PURGED行 - 若用
mydumper，加参数--no-locks --skip-tz-utc --gtid是安全的，但恢复时仍需用myloader --disable-binlog
备份与复制状态需联动监控
只监控 Seconds_Behind_Master 不够——它可能为 0，但实际 SQL 线程已 stop；只监控备份文件时间戳也不行——文件存在不代表内容完整。必须交叉验证。
关键检查项：
- 每 5 分钟执行：
SHOW SLAVE STATUSG，确认Slave_IO_Running: Yes、Slave_SQL_Running: Yes、Retrieved_Gtid_Set和Executed_Gtid_Set差值小于阈值（如 10） - 备份完成后立即记录
select @@global.gtid_executed;，并存入元数据库，用于后续恢复时对齐 GTID - 用
mysqlbinlog --base64-output=DECODE-ROWS -v抽样检查最近 binlog 是否可解析，防止日志损坏 - 定期用
mysqlcheck --all-databases --check扫描表一致性，避免备份时遇到坏页没报错
#!/bin/bash # 示例：带 GTID 校验的备份脚本片段 DUMP_FILE="/backup/mysql_$(date +%Y%m%d_%H%M%S).sql" mysqldump --all-databases --single-transaction --routines --triggers --set-gtid-purged=OFF --skip-lock-tables > "$DUMP_FILE" 记录当前 GTID
GTID_EXECUTED=$(mysql -Nse "SELECT @@global.gtid_executed;") echo "$GTID_EXECUTED" > "${DUMP_FILE}.gtid"
GTID 和备份元数据的对齐是整个方案最易被跳过的环节，一旦漏掉，灾难恢复时可能花数小时定位为什么新从库始终连不上主库。