企业官网建设流程全解析

1 MySQL 主从复制（异步）核心流程

整个复制过程可以拆解为 三个阶段，其中涉及 两个线程（从库 I/O 线程、从库 SQL 线程）和 一个主库侧线程（binlog dump 线程）。

第一阶段：主库记录 binlog

• 主库事务提交时，将数据变更按顺序写入本地的 二进制日志（binlog）。

第二阶段：从库 I/O Thread拉取并写入 relay log

1. 从库执行 START SLAVE 后，启动 I/O 线程。
2. I/O Thread连接到主库，并向主库发送请求，告知需要复制的 binlog 文件名和位置（或 GTID）。
3. 主库收到请求后，立即为该连接创建一个专用的 binlog dump Thread。
4. binlog dump Thread负责读取主库指定的 binlog 内容，并持续发送给从库的 I/O Thread。
5. 从库 I/O Thread接收数据，将其写入本地的 中继日志（relay log）。

第三阶段：从库 SQL Thread重放 relay log

• 从库的 SQL Thread 读取 relay log 中的事件，在从库上顺序执行，完成数据同步。执行位置会被记录，用于断点续传。

关键点说明

• binlog dump Thread的启动时机：它并不是常驻主库的，而是在从库 I/O Thread连接并发送请求后，由主库按需动态创建。每个从库连接对应一个独立的 binlog dump Thread。
• 默认异步：主库写入 binlog 后即返回客户端，不关心从库是否收到或应用。
• relay log 的作用：解耦网络接收和 SQL 重放，避免从库 I/O 慢阻塞 SQL 执行。

2 为什么要做MySQL主从复制

1）数据分布

可以做异地容灾，然后也可以提高用户体验。（假如北京和上海机房都有服务器，mysql安装在北京，为了提高效率，我们会在上海布置一台从服务器，然后让上海机房的服务器访问上海的从库）

2）负载均衡

可以布置多台从服务器，提高读效率

3）备份

我们可以专门在一台从服务器上实施备份

4）高可用性和故障切换

5）升级和测试

我们可以先找一台从数据库来升级服务（MySQL），不会影响主库

3 MySQL主从复制的简单配置

Docker–基础知识点–27–部署MySQL集群

问：主从复制会用到GTID吗？

不一定。GTID（全局事务标识符）是 MySQL 5.6 引入的一种可选的复制方式，传统的主从复制可以不依赖 GTID，只基于 binlog 文件名 + 位置（偏移量） 来定位。

• 如果不使用 GTID：从库 I/O 线程连接主库时，会明确指定要读取的 binlog 文件和位置（例如 mysql-bin.000123, 位置 456）。主库的 binlog dump 线程就从该位置开始发送事件。这种方式称为基于位置的复制，也是经典的主从复制方式。
• 如果启用 GTID：每个事务在主库上被提交时，会生成一个全局唯一的 GTID（格式如 server_uuid:transaction_id）。从库 I/O 线程连接主库时，不需要指定文件/位置，而是告知主库“我已经执行过的 GTID 集合”。主库的 binlog dump 线程会自动计算出从库缺失的事务，并发送这些 GTID 对应的事件。这种方式称为基于 GTID 的复制，它简化了故障切换和主从重建（无需人工找位点）。

总结：

• 主从复制过程可以不用 GTID，传统的基于位置的方式依然广泛使用。
• 但现代 MySQL 环境（尤其是集群、高可用架构）推荐使用 GTID，因为它让复制更自动、更可靠。启用 GTID 后，整个复制过程（从连接请求到 binlog 发送）都会基于 GTID 来协调。