真正可用的备份节点必须满足：read_only=on、log_slave_updates=off、无应用连接或连接数极少、seconds_behind_master≤1；必须启用gtid；版本与主库兼容、配置一致；需独占硬件资源并预留足够磁盘与io余量。
备份节点不能只看“空闲”，得看它是否承担读流量
备份节点不是随便挑一台从库就行。如果它正在被业务系统用作读库，那它就不是纯粹的备份节点——一旦主库出事，你没法直接把它切为主库，因为它的数据可能滞后、连接池可能被打满、甚至还有未提交的临时表。
真正可用的备份节点，应该满足：
- read_only = ON（防止误写）
- log_slave_updates = OFF（不参与级联复制，减少干扰）
- 没有应用连接，或连接数长期稳定在个位数
- Seconds_Behind_Master 值持续为 0 或 ≤ 1
用 GTID 的从库才适合作为备份节点
靠 file + position 管理复制点的从库，一旦主库 binlog 被清理、或者人为跳过事件，就很难精准重搭。而启用 gtid_mode = ON 和 enforce_gtid_consistency = ON 后，你可以用 SET GLOBAL gtid_purged = '...' 快速对齐状态，故障恢复时更可控。
检查方式：SHOW VARIABLES LIKE 'gtid_mode';SHOW MASTER STATUS;（确认 Executed_Gtid_Set 非空）
没开 GTID 的从库，别当备份节点用——它只是个“临时副本”，不是“可接管副本”。
备份节点必须和主库版本兼容且配置一致
常见翻车点：主库是 MySQL 8.0.32，从库是 5.7.40。启动复制时报错 Unknown system variable 'gtid_mode'，根本连不上。
必须对齐的关键项：
- server-id 全局唯一（比如主库设 101，备份节点设 103）
- binlog_format = ROW（STATEMENT 在 NOW()、UUID() 场景下必然不一致）
- max_allowed_packet、wait_timeout 等参数差异过大，会导致大事务同步失败或连接中断
备份节点要预留资源余量，不能和读库共用硬件
一台物理机上既跑读从库又跑备份从库，CPU、IO、内存全挤在一起，主库一做全量备份，备份节点的 SQL 线程立刻卡住，Seconds_Behind_Master 直接飙到几百秒。
真实建议：
- 备份节点独占机器，或至少和读从库隔离在不同容器/VM 中
- 磁盘空间预留 ≥ 主库数据量的 1.5 倍（含中继日志、临时 dump 文件）
- 关闭 innodb_buffer_pool_size 自动调整，固定为合理值（比如总内存的 60%），避免被其他进程挤压
最易被忽略的是磁盘 IO 调度策略——备份节点若和主库共用同一块 SSD，且没配 ionice 或 cgroup 限速，dump 过程会拖垮整个集群响应。
