面试中的MySQL主从复制|手撕MySQL|对线面试官

关注微信公众号【程序员白泽】,进入白泽的知识分享星球🌍

前言

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

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

主从复制架构

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

image-20220306182608427

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

主从复制原理

image-20220306191346779

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~

image-20220306232631739

  • 主库server-id设置为1

image-20220306232834013

配置master节点

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

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

image-20220306193556361

通过容器ID,进入MySQL的docker镜像(这里-it后面是你MySQL容器的)

image-20220306193416832

然后在MySQL容器内部登录MySQL

image-20220306193727515

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

image-20220306194214603

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

image-20220306194416370

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

image-20220306231135364

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

image-20220306231306203

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

image-20220306195845414

配置slave节点

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

image-20220306231545682

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

image-20220306232105690

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

image-20220306233011287

结束语

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

我是白泽,一名热衷于知识分享的程序员/学生党,关注微信公众号【程序员白泽】,我会同步我的博客文章,回复简历,也可以获得我正在使用的简历模板,建立了一个春秋招备战/内推/闲聊群,欢迎交流。

image-20220307092954839