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 STATUS\G，确认
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"
<h1>记录当前 GTID</h1><p>GTID_EXECUTED=$(mysql -Nse "SELECT @@global.gtid_executed;")
echo "$GTID_EXECUTED" > "${DUMP_FILE}.gtid"</p>GTID 和备份元数据的对齐是整个方案最易被跳过的环节，一旦漏掉，灾难恢复时可能花数小时定位为什么新从库始终连不上主库。
