MySQL主从复制 读写分离应用场景及原理测试全面分析_mysql主从宕机测试

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

唯一的好处是主mysql的数据不仅仅是一份，起到了备份的作用以及防备主宕机的后续保障。

1.1.4、MySQL主从复制的原理

按图中流程首先用户通过互联网访问到web，新建了一个用户操作，这个操作发送到数据库，数据库执行insert into table userxxx 插入数据。同时将此insert into table userxxx操作记录存入到自己的binlog日志当中，slave端启动IO线程对master发送请求（请求内容：master的二进制文件以及二进制的POS节点位置）。 master收到slave请求后根据slave请求的信息，读取指定的binlog日志以及从哪个节点开始的日志信息返回给slave的IO线程，IO线程收到master返回的信息后将binlog日志信息以及POS节点信息依次写入到relay log日志也就是中继日志当中，再此同时也将master返回的binlog日志名称以及pos节点位置存放在master-info文件当中。此时SQL线程依次读取relay log日志并将读取内容解析成sql语句进行执行操作，从而实现从主数据一致。

为了简明过程如下：

1. master将sql执行的操作存入到binlog二进制日志当中
2. slave启动IO线程向master服务器进行请求（binlog日志/pos节点）
3. master对slave的请求的binlog/pos节点进行响应
4. slave收到响应后将信息存入到中继日志当中，并且将master的binlog/pos存入到master-info文件当中
5. SQL线程读取中继日志内容进行解析SQL操作写入到数据库

master-info文件作用
master-info（该文件存在slave端）文件中，以便在下一次读取的时候能够清楚的告诉master，我需要从哪个binlog文件的哪个pos节点位置开始，请把此节点以后的日志内容发给我
master-info文件在mysql目录下存在如下：

mysql dump Thread
当slave向master发送请求后，master会为每一个IO线程创建一个dump Thread线程用来发送二进制日志到slave/IO线程。最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。

Mysql dump Thread线程与IO线程

主库收到从库发送的注册指令后会获取到从库的server-id，report-host，report-user，report-password，prot等相关的数据，最终这些数据会存放到slave_list变量中，如果slave-list这个表中已经存在slave-server-id的信息则会删除掉这个信息，在将新的加入。（不能有相同的server-id出现，否则会直接删除）

master收到slave IO发送的请求后，获取slave发送的binlog相关信息，server-id，名称，POS，binlog大小等等，检查是否已经存在与该从库关联的binlog dump线程，例如，slave IO线程出了问题，此时master的binlog dump线程一直等待主库写入数据操作. 如果这时从库io线程重连到主库，就会发现主库已经存在与该从库对应的dump线程。所以主库在处理从库binlog dump请求时，先检查是否已经存在dump线程。

binlog dump内部调用的是多个while嵌套循环，依次等待并读取binlog文件中的event，随后将event发送到从库，如果此时从库envet已经在使用，则忽略该event，当读到新的binlog时如果event都已经发送完成，则 binlogdump线程会等待binlog更新事件。

IO线程请求拉取binlog的命令发送完成之后，io线程在一个while循环中，不断调用read_event(mysql, mi, &suppress_warnings) 来读取主库发送的binlog数据，并写入到relay log文件中。

IO线程以及master的log dump线程都使用循环的方式一个在等待主master写入数据并发送广播传输，当主库发送二进制日志后通过循环方式不断并写入到relay log文件当中。

1.2、MySQL主从复制配置相关

1.2.1、测试环境

主MySQL	192.168.1.8
从MySQL	192.168.1.9
MySQL	version：5.7

1.2.2、MySQL的部署

MySQL部署略过建议下载oneinstall一键下载工具部署mysql，非常好用！

1.2.3、MySQL主从复制的基本流程

1. 首先确定配置master 和 slave其中mysql主配置文件的 ‘server-id’
2. 创建一个用于slave和master通信的用户账号
3. 查看matser的状态，show matser status;需要记录：File的名称以及Postsion的数字
4. 主mysql数据给从数据授权之后需要通过从数据库进行连接操作，连接的时候需要matser的file名称以及postsion这两个数据
5. 从mysql数据库连接成功后，启动同步操作：start slave;
6. 最后检查连接的状态：（show slave status；）

1.2.4、MySQL主从复制实现

主从复制实现还是非常简单的，按照2.1.3的说明一步步部署就可以了，过程如下：

1.2.4.1、Master与slave binlog日志开启

第一步确定master和slave的mysql开启了binlog二进制文件的操作，可以通过以下命令查看：

MySQL [(none)]> show variables like ‘log_bin’;
±--------------±------+
| Variable_name | Value |
±--------------±------+
| log_bin | ON |
±--------------±------+
1 row in set (0.01 sec)

确定log_bin为on的状态，mysql二进制日志mysql-bin.000001,mysql-bin.000002 这样的方式出现，通常出现在mysql目录下。mysql二进制日志中记录了mysql中sql语句执行的所有日志操作. 有一款mysql的工具是通过mysql二进制日志中的内容从而进行数据库的恢复操作. 如果mysql重启一次就会产生新的mysql-bin二进制日志。

1.2.4.2、确认matser与slave serverid不一致

server_id是不可以重复的，server_id 在每一个正在同步中的slave在master上都会对应一个matser线程，这个线程是通过slave的serverid来标识的，如果存在两台从服务器的serverid一致，只能一个链接成功，因为slave在master端最多只有一个线程，通过serverid来标识slave是哪台，如果发现slave两台id都一致，则会导致另外一台不同步的问题. 以下方式配置server id；

master:

[root@master ~]# vi /etc/my.cnf
[root@master ~]# cat /etc/my.cnf | grep server-id
server-id = 1 这是配置文件中matser的id号
[root@master ~]#

slave：

[root@slave ~]# vi /etc/my.cnf
[root@slave ~]# cat /etc/my.cnf | grep server-id
server-id = 2 这是配置文件中slave的id号
[root@slave ~]#

配置matser 和 slave serverid后进行重启mysql操作使其生效！

1.2.4.3、创建一个用于slave和master通信的用户账号

mstser数据库操作：

MySQL [(none)]> grant replication slave on . to ‘myslave’@‘192.168.1.9’ identified by ‘pwd123’;
Query OK, 0 rows affected, 1 warning (0.01 sec)

MySQL [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

MySQL [(none)]>

这条sql是授权1.9这台主机，也就是slave，通过myslave这个用户，通过密码pwd123来链接主mysql的操作

1.2.4.4、查看master正在使用的二进制以及位置编号

MySQL [(none)]> show master status;
±-----------------±---------±-------------±-----------------±------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
±-----------------±---------±-------------±-----------------±------------------+
| mysql-bin.000007 | 602 | | | |
±-----------------±---------±-------------±-------