主从复制SHOW SLAVE STATUS显示Connecting的常见原因是网络通但权限或配置未对齐：主库需开启binlog且server_id全局唯一；从库CHANGE MASTER TO中MASTER_HOST不能为localhost或127.0.0.1，须填真实IP或域名。
主从复制配不起来，SHOW SLAVE STATUS 一直显示 Connecting
常见原因是网络通但权限或配置没对齐。主库必须开 binlog，且 server_id 要全局唯一；从库的 CHANGE MASTER TO 中 MASTER_HOST 不能写 localhost 或 127.0.0.1（容器或跨主机时尤其容易错），得填可路由的真实 IP 或域名。
实操建议：
- 主库检查：
SELECT @@log_bin, @@server_id;，确保返回ON和非零整数 - 从库执行前先停掉复制：
STOP SLAVE;，改完配置再START SLAVE; - 用
mysql -h 主库IP -u repl_user -p在从库机器上手动连一次，验证账号、网络、防火墙三关 - 如果主库开了
require_secure_transport=ON，从库的CHANGE MASTER TO必须加MASTER_SSL=1参数
故障切换后业务连不上新主库，ERROR 2003 (HY000) 持续报错
自动切换本身不等于服务自动重连。MySQL 客户端不会感知主从角色变化，应用层仍连着旧地址——除非你用了中间件或代理层做流量调度。
实操建议：
- 别依赖 DNS 切换：TTL 延迟、客户端缓存、glibc 的
getaddrinfo行为都不可控 - 推荐用
ProxySQL或MaxScale做读写分离+故障感知，它们能监听SHOW SLAVE STATUS变化并自动踢掉失效节点 - 若用 VIP 方案（如 keepalived），确保 ARP 刷新及时，且从库机器禁用
arp_ignore和arp_announce冲突配置 - 应用连接串里不要硬编码 IP，至少用 host 文件或内网 DNS 名，并配合连接池的
validationQuery（如SELECT 1）快速剔除坏连接
semi-sync 开了但复制延迟还是高，甚至退化成异步
半同步不是银弹。只要一个从库响应超时（默认 rpl_semi_sync_master_timeout=10000，单位毫秒），主库就自动切回异步模式，且不会告警——你得自己监控 Rpl_semi_sync_master_status 和 Rpl_semi_sync_master_no_tx 这两个状态变量。
实操建议：
- 调低超时值（比如设成
500）让退化更“果断”，避免长延迟掩盖问题 - 确认从库的
sync_binlog=1和innodb_flush_log_at_trx_commit=1已开，否则半同步意义不大 - 压测时观察
Seconds_Behind_Master是否持续 > 0，大于 0 就说明从库 IO 或 SQL 线程跟不上，要查SHOW PROCESSLIST里卡在哪一步 - 5.7+ 版本注意：
semisync_source和semisync_replica插件名已变，加载命令写错会导致插件根本没生效
用 MHA 自动切换，但 master_ip_failover 脚本总失败
MHA 的故障转移逻辑全靠脚本驱动，而生产环境里最常见的失败点是权限和路径：脚本要用 root 执行 SSH，但 MySQL 用户没 sudo 权限；或者 VIP 绑定命令（如 ip addr add）在 systemd-networkd 管理的系统上不生效。
实操建议：
- 脚本开头加
set -e和日志重定向，不然失败静默，只能看/var/log/masterha/app1/manager.log - SSH 免密必须用 MHA 管理用户（如
mhauser）而非 root，且该用户需有sudo NOPASSWD:/sbin/ip这类精确授权 - 切换前务必确认从库
read_only=0已生效（MHA 不会帮你改），否则提升后写不了 - 阿里云/腾讯云等环境禁用
ip addr，改用云平台 API 绑定 EIP，脚本里得调用curl+ 签名认证
真正难的不是配通复制或跑起 MHA，而是让每次故障切换后，应用连接、监控指标、备份任务、慢日志收集这些周边系统全部无缝跟上新主库的 identity。少一个环节，就多一分半夜被叫醒的风险。
