主库记录数据变更并写入二进制日志，从库通过IO和SQL线程读取并重放日志实现同步。1. 主库负责写操作并生成Binary Log；2. 从库的IO线程拉取日志写入Relay Log；3. SQL线程执行中继日志更新数据；4. 用于备份、读写分离和高可用；5. 存在异步延迟、单点写风险，需设read_only。
MySQL主从关系是一种常见的数据库架构模式，主要用于数据备份、读写分离和提升系统可用性。简单来说，主从关系指的是一个数据库服务器（主库）负责接收写操作，而一个或多个其他服务器（从库）通过复制主库的数据来保持同步，通常用于处理读请求。
主库（Master）的作用
主库是整个主从结构中的核心节点，所有数据的增删改（INSERT、UPDATE、DELETE）操作都发生在主库上。主库会将这些操作记录在一种叫二进制日志（Binary Log）的文件中，用于后续传递给从库。
关键点：
- 主库开启 Binary Log 是主从复制的前提。
- 主库记录的是SQL语句或行数据变更（取决于日志格式）。
- 主库不强制要求只写，但为了结构清晰，通常建议主库主要处理写操作。
从库（Slave）的工作机制
从库并不直接接收应用的写请求，而是通过两个线程来实现与主库的数据同步：
- IO线程：连接主库，读取主库的 Binary Log 内容，并将其写入本地的中继日志（Relay Log）。
- SQL线程：读取中继日志中的事件，按顺序执行，从而实现数据更新。
这样，从库就能逐步追上主库的数据状态，达到数据一致的目的。
主从复制的常见用途
这种架构不是为了提高写性能，而是为了解决以下问题：
- 数据冗余与备份：从库是主库的实时副本，可作为灾难恢复的基础。
- 读写分离：将读请求分发到从库，减轻主库压力，提高整体并发能力。
- 高可用支持：当主库故障时，可手动或自动切换到从库继续服务（需配合其他工具如MHA等）。
需要注意的问题
虽然主从复制带来很多好处，但也存在一些限制和风险：
- 异步复制：默认情况下，MySQL主从是异步的，意味着主库不等待从库确认就返回成功，可能存在数据延迟或丢失。
- 延迟（Delay）：网络、硬件性能或大事务可能导致从库落后于主库。
- 单点写入：如果从库误操作执行了写入，可能破坏数据一致性，因此通常建议从库设置为只读（read_only=1）。
基本上就这些。理解主从关系的关键是搞清数据流向：主库记录变更 → 从库拉取并重放 → 实现数据同步。这套机制是构建稳定、可扩展MySQL系统的基础。
