讲讲MySQL主从复制｜手撕MySQL｜对线面试官

前言

作为《手撕MySQL》系列的第三篇文章，今天讲解使用 bin log实现主从复制的功能。主从复制也是MySQL集群实现高可用、数据库读写分离的基石。因为是系列文章，上一篇文章中（传送门）我们已经介绍了在MySQL中查看 bin log的相关状态以及文件信息，并且借助 bin log（二进制日志）实现数据恢复的案例。因此在这篇文章中如有涉及相关知识，将不再赘述。

重申一下，数据恢复和主从复制是bin log最重要的两个功能，也是面试的重点，一定要有所了解～

主从复制架构

一主一从/一主多从/级联

这里给出了基础的两种主从复制的架构图，左侧由一个主库向三个从库同步对数据库的变更操作（上一篇文章中我们提到过bin log只会记录变更数据库的操作）。而右侧则在这个基础之上，将同步到数据的从库继续作为后一个从库的“主库”同步数据库变更操作，但是这些操主从复制模式的基本原理都是一样的。为了便于学习，本文后面讲解的demo将基于一主一从的最简单模式。

主从复制原理

MySQL主从复制会有三个线程参与：

• master端的log dump线程： 当从结点连接到主结点之后，主节点会为每一个来自从结点的连接创建一个log dump线程与之通信，log dump线程负责读取master端的bin log数据文件（多个log dump线程之间会互斥访问bin log文件——加锁），将其发送给对应slave端的接收线程。
• slave端的I/O线程和SQL执行线程： slave端的两个线程中，I/O线程是负责连接主节点，并不断请求master端的新记录的bin log变更日志。I/O线程接收到log dump线程发送过来的bin log变更之后，将其保存在slave端本地的relay log文件中（异步缓冲），然后会由SQL线程读取relay log文件中的内容，并且转换成SQL用于在slave端执行，达到同步主库变更的效果（在讲bin log数据恢复的时候，我们明白了数据恢复的本质就是再次执行一遍原先的SQL语句，而bin log中会记录数据库变更操作/行数据）

主从复制演示

下面我会用自己本地的MySQL数据库作为从库，而自己云服务器的MySQL作为主节点，通过主从复制，同步云数据库中的数据。并且在开始下面两个步骤之前要确保主库和从库的server-id不同。

• 从库server-id设置为2，这个值可以通过修改mysql配置文件并重启的方式设置，也可以通过set global参数值的形式设置，具体可以Google～

• 主库server-id设置为1

配置master节点

我的云数据库是通过Docker镜像部署的，如果你还不太清楚容器化技术，这里也可以阅读我写过的一篇Docker入门文章（传送门），下面会涉及一些docker操作命令，但如果只是为了了解主从复制的流程，继续看下去也没有任何问题 。

先通过docker ps查看正在运行的docker容器，找到MySQL容器对应的ID

通过容器ID，进入MySQL的docker镜像（这里-it后面是你MySQL容器的）

然后在MySQL容器内部登录MySQL

首先确保master节点的bin log已经开启

接下来在master节点上创建test_copy用户，设置密码为123456，并设置REPLICATION SLAVE权限（这个账号是给slave节点请求master节点用的）

查看当前master节点的bin log数据文件的pos点（position点是位置的意思，可以简单理解成每执行一个数据库事务，就会从当前position开始执行，直到下一个position结束，下一次另一个事务就从前一个事务的结束position为起点开始记录，因此两个position之间就存储着一个事务的执行步骤，而数据恢复也好，主从复制也好，核心原理就是拿到两个pos点之间的数据文件转意成SQL事务，再执行一遍SQL事务）

为了方便就直接用数据库管理工具建立一张copy表，设立id和username两个字段，插入3条数据，我们再来看一下现在bin log数据文件的pos点果然向后推了，表示对数据库的变更被记录到了bin log数据文件中。

至此master节点的配置完成，创建好了给slave节点的用户，并且也准备了用于同步的数据。

配置slave节点

现在我们用本地的MySQL数据库作为从结点，执行下面的命令，通过上面我们在主结点注册好的testcopy用户去获取主节点bin log中的变更数据。其中masterhost是你的云数据库对应的服务器的IP地址：xx.xx.xx.xx。

执行start slave命令，从结点开始同步主节点变更数据。

最后在本地数据库（从数据库上查询得到copy数据库被成功同步下来！大功告成，如果遇到了问题，我再手撕MySQL系列第一篇文章就教大家在遇到MySQL启动相关问题时可以通过查询错误日志去看warning和error，找到原因），当然这只是一主一从进行数据同步的最简单的一个demo，还有通过全局事务ID代替pos点进行数据同步的方式，需要额外学习，本文就不多赘述。

结束语

本文讲解了使用bin log进行主从复制的基本原理，结合上一篇文章的数据恢复，二进制日志的两大功能已经全部讲解完成，相信在面试中如果遇到相关的知识点可以对答如流。