详细介绍：Mysql 主从复制。

角色 / 资料	作用
主服务器 Binary Log	记录主服务器的所有数据变更执行
从服务器 I/O 线程	拉取主服务器 Binary Log，写入本地 Relay Log
从服务器 Relay Log	存储从主服务器拉取的日志（临时中转）
从服务器 SQL 线程	解析 Relay Log，重放操作实现资料同步

1.2.1、MySQL 主从复制的核心工作过程

主服务器记录变更：Master（主服务器）执行增 / 删 / 改管理后，会把操作详情以 “事件” 形式写入自身的二进制日志（Binary Log）；
从服务器拉取日志：Slave（从服务器）启动 I/O 线程，连接 Master 并请求二进制日志，Master 通过 Dump 线程将日志发送给 Slave，Slave 将接收的日志存入本地中继日志（Relay Log）；
从服务器重放日志：Slave 的 SQL 线程读取中继日志，解析并重复执行日志中的执行，最终实现与 Master 的材料一致。
为什么复制？核心目的是 保证数据完整性与高可用性：Master 故障时，Slave 可作为备用服务器切换，避免内容丢失；同时支持读写分离（Master 写、Slave 读），减轻 Master 压力，提升系统性能。
谁复制谁？由 Slave（从服务器）主动复制 Master（主服务器）的数据，Master 仅负责记录日志和发送日志，不主动推送资料。
资料变更记录放在哪？主服务器的 二进制日志（Binary Log）是核心存储档案，所有内容变更操作都记录在此，是 Slave 同步的 “数据源”。

二，两日志、三线程、

2.1、两日志（同步的数据载体，核心作用与关联）

1. 二进制日志（Binary Log）

它位于主服务器（Master），是主从同步的 “数据源核心”—— 主服务器执行任何增、删、改数据操作后，都会把操作的详细信息（比如执行的 SQL 语句、操作时间、日志位置）以 “事件” 的形式记录到这份日志里，没有它，从服务器就没有可同步的 “数据依据”。

2. 中继日志（Relay Log）

它位于从服务器（Slave），是临时的 “日志中转站”—— 从服务器不会直接读取主服务器的二进制日志，而是通过专属线程把日志拉取到本地后，先存入这份中继日志，避免直接操作原日志导致的冲突或损坏，后续再由另一个线程从这里读取日志进行材料重放。

2.2、三线程（同步的执行主体，分工与协作）

1. Dump 线程（主服务器侧）

它是主服务器专门对接从服务器的 “日志发送线程”—— 当从服务器发起日志请求时，它会主动读取主服务器二进制日志中 “未同步的部分”，接着把这些日志数据准确发送给从服务器，全程只负责日志读取和传输，不参与信息操作。

2. I/O 线程（从服务器侧）

它是从服务器的 “日志拉取线程”—— 会主动连接主服务器的 Dump 线程，发起日志同步请求，接收主服务器发送的二进制日志数据，再把这些信息完整写入到从服务器本地的中继日志中，相当于 “搬运工”，只负责日志的传输和存储，不解析、不执行。

3. SQL 线程（从服务器侧）

它是从服务器的 “数据重放线程”—— 会持续读取中继日志中的 “事件”，逐一解析这些事件对应的操作（比如当初主服务器执行的增删改 SQL），接着在从服务器上重复执行这些管理，最终让从服务器的资料和主服务器保持一致，相当于 “执行者”，只负责日志解析和数据同步。

2.3、日志与线程的联动逻辑

主服务器执行数据变更→写入二进制日志→从服务器 I/O 线程连接主服务器 Dump 线程→Dump 线程发送二进制日志→I/O 线程将日志写入中继日志→SQL 线程读取中继日志并重放执行→数据同步结束。

三，MySQL有几种同步方式：三种

MySQL 核心的三种同步方式（按数据一致性、性能优先级分类），具体说明如下：

3.1、三种核心同步方式（含适用场景）

3.1.1、异步复制（MySQL 默认同步方式）

核心原理是主服务器（Master）执行完增删改数据操作后，直接向客户端返回成功结果，完全不等待从服务器（Slave）的任何确认 —— 既不用等从服务器接收日志，也不用等从服务器重放数据。它的优势是性能最高，主服务器无需额外等待，能快捷响应写请求，但数据一致性相对较低：如果主服务器突然故障，可能存在部分已返回给客户端的操作，还没来得及同步到从服务器，导致少量数据丢失。此种方式适合多数互联网场景（比如电商商品展示、博客发布），优先保证写入性能，对少量数据丢失有容忍度。

3.1.2、半同步复制（Semi-Sync）

它是异步复制的优化版，核心逻辑是主服务器执行完数据操作后，不会立刻返回结果，而是需要等待至少 1 个从服务器确认 “已接收二进制日志并写入本地中继日志”，才会向客户端返回成功。相比异步复制，它的数据一致性更高 —— 能确保已返回给客户端的操作，至少有一个从服务器拿到了日志，即便主服务器故障，也能从这个从服务器恢复数据，不会丢失已确认的操作；但性能会略受影响，主服务器得等待从服务器的确认响应，不过影响程度可控。适合对资料一致性有一定要求的场景（比如支付记录、订单信息），需要兼顾可靠性和性能，无法接受关键数据丢失。

3.1.3、全同步复制

说，只有所有从服务器的数据都和主服务器完全一致，主服务器才会告知客户端处理成功，几乎不会出现数据丢失的情况，但性能损耗也最大 —— 主服务器的响应速度完全依赖所有从服务器的同步效率，从服务器越多、网络越慢，主服务器的写入延迟就越明显。这种方式仅适用于对数据一致性要求极高的核心场景（比如核心金融交易、医疗数据记录），允许牺牲性能来换取绝对的数据安全，不能接受任何材料不一致。就是这是数据一致性最高的同步方式，核心规则是主服务器执行完数据执行后，必须等待所有从服务器都确认 “已搞定日志重放，数据同步完成”，才能向客户端返回成功。也就

主服务器等待从服务器确认的 “阶段” 不同：异步不等待、半同步等 “日志接收”、全同步等 “素材同步完成”，由此决定了一致性和性能的取舍。就是三种方式的核心区别，本质