复制与高可用
MySQL 传统复制由 Source 写入 Binary Log，Replica 通过 Receiver Thread 获取并写入 Relay Log，再由 Applier Thread 重放。复制默认异步，服务切换和连接路由需要额外组件或编排。
传统复制
| 能力 | 说明 |
|---|---|
| GTID | 使用 source_uuid:transaction_id 标识事务，简化位置和切换 |
| Row-Based Logging | 记录行变化，通常比 Statement 更适合可靠复制和 CDC |
| Parallel Apply | 多 Worker 并行应用，降低 Replica Lag |
| Semisynchronous | Source 等待至少一个 Replica 确认接收，仍需理解确认位置和降级行为 |
| Delayed Replication | 人为延迟应用，为误操作提供反应窗口 |
Seconds_Behind_Source 不能单独完整表达延迟，还应观察接收位置、应用队列、Worker 状态、GTID 差距和业务时间戳。
Group Replication
Group Replication 使用组成员服务、GTID 和事务冲突认证维护复制组，支持 Single-Primary 或 Multi-Primary Mode。
Secondary 应用事务仍可能存在积压，因此 Group Replication 不应简单描述为所有节点每时每刻完全同步。Consistency Level 可以在故障切换、读和写路径选择等待点，代价是延迟与可用性。
Multi-Primary 并不保证写吞吐线性扩展。冲突事务会在认证阶段失败，Auto-Increment、热点行和跨节点写入顺序都需要专门设计。
InnoDB Cluster
InnoDB Cluster 通常组合 Group Replication、MySQL Router 和 MySQL Shell：
| 组件 | 作用 |
|---|---|
| Group Replication | 数据复制、成员关系和 Primary 选举 |
| MySQL Router | 向应用提供读写入口并按拓扑路由 |
| MySQL Shell / AdminAPI | 创建、检查和管理 Cluster |
高可用仍需要奇数投票成员、跨故障域部署、旧主隔离、备份和演练。三个虚拟机若位于同一物理宿主或存储，不构成有效的故障域冗余。
读写分离
Replica 读取可能落后于 Source。需要 Read-After-Write 的请求可以固定 Primary、等待 GTID 应用或使用明确一致性策略。只按 SQL 是否为 SELECT 路由，会忽略事务、锁定读、临时表和会话状态。