MySQL--基础知识点--83--主从复制

1 MySQL 主从复制异步核心流程整个复制过程可以拆解为 三个阶段其中涉及 两个线程从库 I/O 线程、从库 SQL 线程和 一个主库侧线程binlog dump 线程。第一阶段主库记录 binlog主库事务提交时将数据变更按顺序写入本地的 二进制日志binlog。第二阶段从库 I/O Thread拉取并写入 relay log从库执行 START SLAVE 后启动 I/O 线程。I/O Thread连接到主库并向主库发送请求告知需要复制的 binlog 文件名和位置或 GTID。主库收到请求后立即为该连接创建一个专用的 binlog dump Thread。binlog dump Thread负责读取主库指定的 binlog 内容并持续发送给从库的 I/O Thread。从库 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 来协调。