主从复制通过binlog实现数据异步同步，主库记录变更并写入binlog，从库I/O线程拉取binlog写入relay log，SQL线程重放操作保持数据一致；支持statement、row和mixed三种日志格式，适用于读写分离、高可用及数据分析场景。
主从复制的核心原理是利用 MySQL 的二进制日志（binlog）实现数据的异步同步。整个过程不需要人为干预，由数据库系统自动完成。
主从复制的基本流程
主从复制主要分为三个关键步骤，涉及主库和从库上的多个线程协作：
- 主库记录变更：当主服务器（Master）发生数据更改（如 INSERT、UPDATE、DELETE）时，这些操作会被记录到它的二进制日志（Binary Log）文件中。
- 从库拉取日志：从服务器（Slave）启动一个 I/O 线程，连接到主库并请求读取指定位置之后的 binlog 内容。主库会为这个连接启动一个 dump 线程，负责将 binlog 内容发送给从库的 I/O 线程。从库收到后，会将这些内容写入到自己的中继日志（Relay Log）文件中，并记录当前已读取的位置，以便下次继续同步。
- 从库重放操作：从库的 SQL 线程会持续监控中继日志。一旦发现有新的日志内容，它就会读取 Relay Log 中的事件，并在从库上重新执行这些操作，从而使从库的数据与主库保持一致。
核心组件：Binlog 日志格式
binlog 的记录方式决定了复制的精度和性能，主要有三种格式：
关于Objective
下载
本文档主要讲述的是关于Objective-C手动内存管理的规则；在ios开发中Objective-C 增加了一些新的东西，包括属性和垃圾回收。那么，我们在学习Objective-C之前，最好应该先了解，从前是什么样的，为什么Objective-C 要增加这些支持。有需要的朋友可以下载看看
- 基于语句（Statement-based）：记录的是原始的 SQL 语句。优点是日志量小，效率高。缺点是某些函数（如 NOW()）或非确定性操作可能导致主从数据不一致。
- 基于行（Row-based）：记录的是每一行数据的具体修改（修改前和修改后的值）。优点是数据一致性高，能准确还原所有变更。缺点是日志量大，尤其在批量更新时，可能占用更多磁盘和网络资源。
- 混合模式（Mixed）：MySQL 默认采用此模式。它会根据执行的 SQL 语句自动选择使用“基于语句”还是“基于行”的方式记录。例如，对于普通的 DML 操作，优先使用语句模式；而对于包含不确定函数的语句，则自动切换到行模式，以保证复制的可靠性。
主从复制的主要用途
这套机制在实际应用中非常有价值，主要用于以下几个方面：
- 读写分离：让主库专注于处理写请求，而大量的读请求则分发到一个或多个从库上执行。这能显著降低主库的负载，提升整体系统的并发处理能力。
- 数据备份与高可用：从库的数据是主库的实时副本。当主库发生硬件故障或需要维护时，可以快速将某个从库提升为主库，实现故障转移，保障业务连续性。
- 数据分析：可以将一个从库专门用于运行复杂的报表查询或数据分析任务，避免这些耗时操作影响主库的在线交易性能。
