MySQL 高可用基石 - 复制监控与常见 HA 方案

---

MySQL 复制核心原理

MySQL 复制允许数据从一个 MySQL 数据库服务器（称为主库 - Primary，旧称 Master）复制到一个或多个其他的 MySQL 服务器（称为从库 - Replica，旧称 Slave）。

复制的主要目的:

• 高可用性 (High Availability)：当主库发生故障时，可以将一个从库提升为新的主库，从而快速恢复服务。
• 读扩展 (Read Scalability)：可以将读密集型的查询分发到从库上执行，减轻主库的压力，提高整体读取性能。
• 备份 (Backups)：可以在从库上执行备份操作，避免对主库产生额外的负载和锁竞争。
• 地理分布 (Geographic Distribution)：可以将从库部署在不同地理位置，让用户就近访问数据，或作为异地灾备。

基本架构 (主从复制):

1. 主库 (Primary/Master)：
   • 接收所有写操作（INSERT, UPDATE, DELETE）。
   • 将所有数据变更事件记录到其二进制日志 (Binary Log, binlog) 中。
2. 从库 (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