MySQL 高可用基石 - 复制监控与常见 HA 方案
MySQL 高可用基石 - 复制监控与常见 HA 方案
MySQL 复制核心原理
MySQL 复制允许数据从一个 MySQL 数据库服务器（称为主库 - Primary，旧称 Master）复制到一个或多个其他的 MySQL 服务器（称为从库 - Replica，旧称 Slave）。
复制的主要目的:
- 高可用性 (High Availability)：当主库发生故障时，可以将一个从库提升为新的主库，从而快速恢复服务。
- 读扩展 (Read Scalability)：可以将读密集型的查询分发到从库上执行，减轻主库的压力，提高整体读取性能。
- 备份 (Backups)：可以在从库上执行备份操作，避免对主库产生额外的负载和锁竞争。
- 地理分布 (Geographic Distribution)：可以将从库部署在不同地理位置，让用户就近访问数据，或作为异地灾备。
基本架构 (主从复制):
- 主库 (Primary/Master)：
- 接收所有写操作（INSERT, UPDATE, DELETE）。
- 将所有数据变更事件记录到其二进制日志 (Binary Log,
binlog) 中。
- 从库 (Replica/Slave)：
- 连接到主库。
- 拥有一个 I/O 线程 (I/O Thread)：该线程从主库请求并读取
binlog事件，然后将这些事件写入到从库本地的中继日志 (Relay Log,relay-log)。 - 拥有一个 SQL 线程 (SQL Thread)：该线程读取中继日志中的事件，并在从库上重放 (replay) 这些事件，从而使从库的数据与主库保持一致。
二进制日志格式 (Binlog Formats):
binlog_format 参数的设置对复制的可靠性和行为有重要影响：
- STATEMENT (SBR - 基于语句的复制)：(已不推荐用于生产) 直接记录执行的 SQL 语句。对于某些非确定性函数（如
UUID(),NOW()依赖于执行时间）或包含用户定义函数的语句，可能导致主从数据不一致。 - ROW (RBR - 基于行的复制)：强烈推荐使用。记录实际发生变更的数据行（通常是变更前后的行镜像，或仅变更后的镜像）。更安全，更能保证数据一致性，对绝大多数场景都适用。这是 MySQL 5.7.7 及之后版本的默认格式。
- MIXED (混合格式)：My