主从复制解决什么问题，为什么不是所有场景都适用
主从复制本质是单向数据同步，适用于读多写少、需要灾备或报表分离的场景。它不提供自动故障转移，主库宕机后必须人工介入切换，业务会中断。
常见错误现象：
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 是否连续。
