01 主从复制基础
为什么需要主从复制
- 缓解单台数据库的读压力，为高可用和故障切换提供基础。
- 主从复制本身不等于自动故障切换，也不能替代备份。
基本概念
- 主库（Source/Master）：处理写入并产生 binlog。
- 从库（Replica/Slave）：获取并应用主库的变更。
- 常见架构：一主一从、一主多从，也可级联复制。
binlog 二进制日志
- 记录数据库变更事件，主要用于复制与时间点恢复。
- 常见格式：STATEMENT（SQL）、ROW（行变更）、MIXED（混合）。
- SELECT 等普通查询通常不作为数据变更写入 binlog。
02 主从复制工作原理
核心日志
- binlog：主库的二进制日志。
- relay log：从库接收并暂存的中继日志。
核心线程
- 主库 binlog dump 线程：向从库发送日志事件。
- 从库 I/O 线程：接收事件并写入 relay log。
- 从库 SQL/applier 线程：读取 relay log 并应用变更。
复制流程
- 主库提交事务并记录 binlog。
- 从库 I/O 线程连接主库并接收 binlog 事件。
- 从库将事件写入 relay log。
- 从库应用线程执行事件，更新从库数据。
复制特点
- MySQL 常见复制默认是异步的。
- 复制存在延迟，主库已提交的数据不一定立刻能从从库读到。
- 现代版本可支持并行应用，不要笼统认为从库只能串行回放。
03 复制模式与延迟
复制模式
- 异步复制：主库不等待从库确认，性能较好，但故障时可能丢失尚未复制的数据。
- 半同步复制：主库等待至少一个从库确认收到日志后再返回，确认不等于从库已执行完成。
- 增强半同步：可在提交阶段等待确认，具体行为取决于版本与配置。
主从延迟原因
- 主库写入量大、从库应用能力不足。
- 网络延迟、磁盘 I/O 或硬件性能差异。
- 大事务、锁等待、从库查询负载高。
延迟排查与优化
- 查看复制线程状态、延迟指标和错误信息。
- 检查网络、磁盘、CPU、慢查询与大事务。
- 适当提升从库资源、优化 SQL、考虑并行复制。
04 主从复制配置（MySQL 5.7 常见流程）
主库准备
- 配置唯一 server_id。
- 开启 log_bin（二进制日志），并重启或按版本要求使配置生效。
- 创建复制账号，仅授予 REPLICATION SLAVE 等必要权限。
- 记录 SHOW MASTER STATUS 的日志文件名与位置（传统 file/position 方式）。
从库准备
- 配置与其他节点不重复的 server_id。
- 确保已有一致的初始数据。
- 配置主库地址、复制账号及 binlog 文件/位置，或使用相应版本的 GTID 配置。
启动与验证
- 传统命令：START SLAVE；新版本常用 START REPLICA。
- 检查：SHOW SLAVE STATUS\G；新版本可用 SHOW REPLICA STATUS\G。
- 重点关注 I/O 与 SQL 线程状态、Last_IO_Error、Last_SQL_Error、延迟指标。
关键注意事项
- 初始化数据必须与复制起点匹配，否则容易报错或数据不一致。
- server_id 在复制拓扑中应唯一。
- 生产环境不要直接照搬示例密码，应限制复制账号来源并妥善保管凭据。
05 常见故障与排查
I/O 线程无法连接
- 检查主从网络、端口、防火墙与 DNS/地址。
- 检查复制账号、密码、来源主机限制和复制权限。
- 核对主库 binlog 是否开启、日志文件与复制位点是否有效。
SQL 应用线程报错
- 查看 Last_SQL_Error，确认具体失败事件。
- 检查主从数据是否存在差异、表结构是否一致。
- 不要随意跳过复制错误，先判断是否会造成数据不一致。
重新建立复制
- 先确认数据基线与复制位点/GTID 一致。
- 修复配置或重新初始化数据后，再重新启动复制。
- 修改复制源配置的具体命令随 MySQL 版本而异。
06 读写分离基础
基本原理
- 写请求通常路由到主库，读请求可分发到一个或多个从库。
- 底层依赖主从复制，读写分离负责请求路由。
优点与限制
- 优点：分摊读压力、提高读取扩展能力。
- 限制：复制延迟会导致读到旧数据，写压力仍主要由主库承担。
- 刚写后必须读到最新值的场景，可考虑读主库或设计一致性策略。
实现方式
- 应用层：业务代码分别连接主库和从库，简单直接但与代码耦合。
- 代理/中间件层：统一接入并路由 SQL，需要考虑中间件高可用与维护。
读写路由注意点
- 不能仅凭 SQL 是 SELECT 就断定一定可以走从库（事务、锁定读等场景需谨慎）。
- 从库也可能承担读请求之外的复制与维护负载。
- 读写分离不自动解决数据一致性、主库故障切换和备份问题。
07 MyCat 与中间件基础
中间件的作用
- 位于应用与 MySQL 之间，负责连接管理、SQL 路由及读负载分配。
- 常见方案/产品需按当前维护状态与业务环境选型。
MyCat 常见配置概念
- server.xml：用户、权限与逻辑库等接入配置。
- schema.xml：逻辑库、数据节点、后端主机组及读写节点关系。
- rule.xml：分库分表相关规则（基础读写分离通常不必深入）。
常见术语
- schema：逻辑库。
- dataNode：数据节点。
- dataHost：后端数据库主机组。
- writeHost / readHost：写节点 / 读节点。
理解
- 中间件按配置路由读写请求，底层仍需要 MySQL 复制。
- 中间件本身也要考虑高可用、连接数、监控和故障处理。
08 复习
高频问题
主从复制为什么需要 binlog 和 relay log？
- binlog：主库上的二进制日志，记录所有数据变更事件，是主从复制的数据源。
- relay log：从库本地的中继日志，用来暂存从主库拉过来的 binlog 事件，避免 SQL 线程回放慢时阻塞网络传输。
- 简单说：binlog 负责"记录变更"，relay log 负责"缓冲日志"。
I/O 线程与 SQL 线程分别做什么？
- 从库 I/O 线程：连接主库，拉取 binlog 事件，写入本地 relay log。
- 从库 SQL 线程：读取 relay log，回放其中的事件，把变更应用到从库数据。
- 主库侧还有一个 Binlog Dump 线程，负责把 binlog 推送给从库。
主从复制的完整流程是什么？
- 主库执行写操作，把变更写入 binlog。
- 从库 I/O 线程连接主库，主库 Dump 线程按位点或 GTID 推送 binlog。
- 从库 I/O 线程把收到的事件写入 relay log。
- 从库 SQL 线程读取 relay log 并重放，最终与主库数据一致。
- 从库持续上报已消费位点，主库继续推送新事件。
异步复制与半同步复制有什么区别？
| 对比项 | 异步复制 | 半同步复制 |
|---|---|---|
| 返回时机 | 主库写完 binlog 即返回 | 至少一个从库收到 binlog 后才返回 |
| 性能 | 最好 | 略有增加 |
| 数据安全 | 主库宕机可能丢数据 | 丢数据风险更低 |
| 适用场景 | 非核心读扩展 | 对一致性要求较高的写业务 |
主从延迟有哪些原因，如何排查？
常见原因
- 从库 SQL 线程单线程回放，跟不上主库并发写入。
- 大事务、批量 DDL/DML 阻塞回放。
- 从库读压力大，CPU、IO 被查询占用。
- 网络延迟或带宽不足。
- 主库写入量突增，binlog 产生过快。
- 未开启并行复制。
排查方法
- 从库执行 SHOW SLAVE STATUS\G，查看 Seconds_Behind_Master。
- 检查 Slave_IO_Running、Slave_SQL_Running 是否正常。
- 查看从库 CPU、IO、慢查询、锁等待。
- 检查是否有大事务、relay log 堆积、磁盘空间不足。
- 必要时开启并行复制、拆分大事务、把强一致性读切回主库。
主从复制失败时，先检查哪些状态与日志？
- SHOW SLAVE STATUS\G。
主从复制、读写分离、高可用和备份有什么区别？
- 主从复制：数据同步机制，保证从库和主库数据一致。
- 读写分离：流量路由策略，写走主库、读走从库。
- 高可用：主库故障时能快速切换，保证服务持续可用，通常还需要 MHA、MGR、Orchestrator 等组件。
- 备份：历史数据快照，用于误删恢复、归档和灾备，不能替代实时复制。
- 主从复制是数据同步基础，读写分离是读扩展手段，高可用解决故障切换，备份解决数据恢复，四者互补但不能互相替代。
实操检查清单
- 确认主从 server_id 不重复、binlog 已开启。
- 确认复制账号和网络连通性。
- 确认初始数据与复制起点匹配。
- 检查复制状态、错误字段和延迟指标。
- 通过写入主库、查询从库验证同步。