主从复制解决读多写少、灾备和报表分离问题，但因无自动故障转移、延迟高、易数据不一致而不适用于强一致性或高可用要求场景。
主从复制解决什么问题，为什么不是所有场景都适用
主从复制本质是单向数据同步，适用于读多写少、需要灾备或报表分离的场景。它不提供自动故障转移，主库宕机后必须人工介入切换，业务会中断。
常见错误现象：Seconds_Behind_Master 持续增长、从库IO_THREAD或SQL_THREAD为NO、主从数据不一致但无报错。
- 延迟受网络、从库硬件、大事务、未启用
binlog_row_image=FULL影响极大 - 从库开启
read_only=ON仍可能被误操作写入，需配合super_read_only=ON（mysql 5.7+） - GTID模式下切换更可靠，但要求所有节点
gtid_mode=ON且enforce_gtid_consistency=ON，旧版本升级需谨慎
MySQL Group Replication（MGR）和InnoDB Cluster的实际约束
MGR 是 MySQL 官方提供的基于 Paxos 的多主/单主集群方案，InnoDB Cluster 是其上层封装。它能自动选主、检测脑裂、提供高可用，但对环境要求苛刻。
典型报错：Error 3092 (HY000): The server is not configured properly to be an active member of the group，常因bind_address、group_replication_ip_allowlist或防火墙导致。
- 必须使用
ROW格式二进制日志，且binlog_checksum=NONE（MySQL 8.0.20+ 可设为CRC32） - 所有节点时钟必须同步（
ntpd或chronyd），偏差超 5 秒可能触发成员驱逐 - 单主模式下写请求只能发往 primary 节点，应用层需识别并路由；多主模式禁止在不同节点并发更新同一行，否则事务会回滚
ProxySQL 或 MaxScale 做中间件时的关键配置点
这类中间件不解决数据一致性，只负责流量分发与故障感知。用错配置反而放大风险，比如把写请求轮询到从库。
真实踩坑场景：ProxySQL 的 mysql_replication_hostgroups 表未正确标记主从角色，或健康检查语句返回值未按约定处理（如用select 1而非SELECT @@read_only）。
- 必须开启
monitor模块，并配置monitor_username有REPLICATION CLIENT权限 - 读写分离规则优先级高于 hostgroup 权重，
match_digest匹配INSERT/UPDATE/delete要写全，避免/*+ READ_FROM_SLAVE */类 hint 被忽略 - MaxScale 的
master_recovery行为默认不自动恢复旧主为从，需显式配置auto_rejoin=true并确认server_id不冲突
什么时候该放弃集群，老老实实用单实例+备份
中小业务日均写入低于 500 QPS、峰值连接数、RTO 要求在分钟级，强依赖集群反而增加运维复杂度和故障面。
例如 laravel 应用开启DB::transaction()后跨多个从库查询，结果不可预测；又如 wordpress 后台更新插件时触发大量ALTER table，在 MGR 中直接失败并卡住整个组。
- 备份策略比集群更重要：每天
mysqldump --single-transaction --routines+xtrabackup增量归档，比三节点 MGR 更快恢复 - 云厂商 RDS 已内置主从+代理+自动备份，自建集群除非有定制审计、合规或跨机房容灾硬需求，否则性价比极低
- 真正难的是状态收敛——比如订单表和库存表不在同一库，集群无法保证跨库事务原子性，最终还得靠应用层幂等和补偿
实际部署时，SHOW PROCESSLIST里出现大量Waiting for semi-sync ACK from slave，或者performance_schema.replication_applier_status_by_coordinator中APPLYING_EVENT卡住，说明同步链路已出问题。这时候看集群拓扑不如先查 binlog position 和 relay log 是否连续。