MySQL-主从复制：概述、原理、同步数据一致性问题、搭建流程 ...

主从复制

1. 主从复制概述

1.1 怎样提升数据库并发能力

一样平常应用对数据库而言都是“读多写少”，也就说对数据库读取数据的压力比力大，有一个思路就是采用数据库集群的方案，做主从架构、进行读写分离，这样同样可以提升数据库的并发处置惩罚能力。但并不是全部的应用都需要对数据库进行主从架构的设置，毕竟设置架构自己是有本钱的。
如果我们的目的在于提升数据库高并发访问的服从，那么首先考虑的是怎样优化SQL和索引，这种方式简单有用；其次才是采用缓存的策略，比如使用 Redis将热门数据保存在内存数据库中，提升读取的服从；最后才是对数据库采用主从架构，进行读写分离。
1.2 主从复制的作用

第1个作用：读写分离。
第2个作用就是数据备份。
第3个作用是具有高可用性。
2. 主从复制的原理

2.1 原理分析

三个线程
实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中，会基于3 个线程来操纵，一个主库线程，两个从库线程。
二进制日志转储线程（Binlog dump thread）是一个主库线程。当从库线程连接的时间， 主库可以将二进制日志发送给从库，当主库读取变乱（Event）的时间，会在 Binlog 上加锁，读取完成之后，再将锁释放掉。
从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到当地的中继日志 （Relay log）。
从库 SQL 线程会读取从库中的中继日志，并且实行日志中的变乱，将从库中的数据与主库保持同步。
复制三步骤
步骤1：Master将写操纵记录到二进制日志（binlog）。
步骤2：Slave将Master的binary log events拷贝到它的中继日志（relay log）；
步骤3：Slave重做中继日志中的变乱，将改变应用到自己的数据库中。 MySQL复制是异步的且串行化的，而且重启后从接入点开始复制。
复制的问题
复制的最大问题：延时
2.2 复制的基本原则

• 每个Slave只有一个Master
  
• 每个Slave只能有一个唯一的服务器ID
  
• 每个Master可以有多个Slave
  

3. 同步数据一致性问题

主从同步的要求：

• 读库和写库的数据一致(最终一致)；
  
• 写数据必须写到写库；
  
• 读数据必须到读库(不一定)；
  

3.1 理解主从耽误问题

进行主从同步的内容是二进制日志，它是一个文件，在进行网络传输的过程中就一定会存在主从耽误（比如 500ms），这样就大概造成用户在从库上读取的数据不是最新的数据，也就是主从同步中的数据不一致性问题。
3.2 主从耽误问题缘故原由

在网络正常的时间，日志从主库传给从库所需的时间是很短的，即T2-T1的值是非常小的。即，网络正常环境下，主备耽误的重要泉源是备库接收完binlog和实行完这个变乱之间的时间差。
主备耽误最直接的表现是，从库消费中继日志（relay log）的速率，比主库生产binlog的速率要慢。造成缘故原由：
1、从库的机器性能比主库要差
2、从库的压力大
3、大变乱的实行
3.3 怎样减少主从耽误

若想要减少主从耽误的时间，可以采取下面的办法：

• 降低多线程大变乱并发的概率，优化业务逻辑
  
• 优化SQL，避免慢SQL，减少批量操纵，建议写脚本以update-sleep这样的情势完成。
  
• 进步从库机器的配置，减少主库写binlog和从库读binlog的服从差。
  
• 尽量采用短的链路，也就是主库和从库服务器的距离尽量要短，提升端口带宽，减少binlog传输的网络延时。
  
• 及时性要求的业务读强制走主库，从库只做灾备，备份。
  

3.4 怎样办理一致性问题

读写分离环境下，办理主从同步中数据不一致的问题， 就是办理主从之间 数据复制方式 的问题，如果按照数据一致性 从弱到强 来进行分别，有以下 3 种复制方式。
方法 1：异步复制
​ MVSQL默认的复制方式，在异步复制的方式中主库在实行完变乱操纵以后，会立刻给客户端返回。他不需要关心从库是否完成该变乱的实行。
​ 这种方式会导致一个问题，那就是当主库出现故障时，主库虽然变乱实行完了但是大概还没来得及把数据同步给从库，就挂了。那么当从库升级为主库之后，他会丢失了这次变乱的变更内容。
方法 2：半同步复制
​ 半同步复制是介于全同步复制和异步复制之间的一种方案。他再实行完一个变乱之后，也不会立刻给客户端反馈，但是也不会等全部从库都完成变乱，而是等此中一个从库完成接收到变乱之后，再反馈给客户端。
在半同步复制这个方案中，会在变乱提交的2阶段都完成之后，等候从库接收到binlog，然后再返回乐成。
方法 3：组复制
​ 首先我们将多个节点共同构成一个复制组，在实行读写（RW）变乱的时间，需要通过一致性协议层（Consensus 层）的同意，也就是读写变乱想要进行提交，必须要经过组里“大多数人”（对应 Node 节点）的同意，大多数指的是同意的节点数量需要大于 （N/2+1），这样才可以进行提交，而不是原发起方一个说了算。而针对只读（RO）变乱则不需要经过组内同意，直接 COMMIT 即可。
方法 4：全同步复制
​ 全同步复制的这个方式中，当主库实行完一个变乱之后，他会等候全部的从库完成数据复制之后，才会给客户端反馈。这种方式安全性可以保障了，但是性能很差。如果从库比力多的话，会导致整个过程更加长。
4、主从复制-搭建流程

4.1 环境准备

一主一从，默认安装好了MySQL了，需要安装，可以参考
节点ip数据库角色节点1192.168.3.131Mysql主j节点节点2192.168.3.137Mysql从节点 4.2 主节点配置

主节点需要做的工作就是创建用户并赋予权限，然后开启binlog日志。
首先创建给从节点登录用的账号和密码，如下

1. #查看主节点的登录名账号,没有用于从节点登录的账号密码
2. select Host,User from user;
3. create user 'slave01'@'192.168.3.137' identified by '123456';
4. select Host,User from user;

复制代码

授予从节点登录主节点验证的权限
由于MySQL的版本问题，我这个是8.0版本的，在授权语句背面加上identified by '123456'会报错，所以，我此处，没加

1. grant replication slave on *.* to 'slave01'@'192.168.157.137';

复制代码

显示确认一下授予权限的环境

1. show grants for 'slave01'@'192.168.3.137';

复制代码

修改mysql配置文件

1. vim /etc/my.cnf

复制代码

1. #主从复制配置
2. log-bin=mysql-bin
3. server-id=131        #和从节点不一样即可

复制代码

4.3 从节点配置

从服务器需要做的工作就是配置同步日志，指定主节点的ip，端口，用户，密码等，然后启动从节点
修改mysql配置文件

1. #主从复制配置
2. log-bin=mysql-bin
3. server-id=137

复制代码

重启从节点mysql

先在主节点mysql上查看master信息

1. show master status;

复制代码

在从节点的MySQL上指定主节点信息

1. change master to master_host='192.168.3.131',master_user='slave01',master_password='123456',master_log_file='master-a-bin.000001',master_log_pos=156;

复制代码

• master_host 是主节点ip
  
• master_user 和 master_password 是主节点创建给从节点的账号和密码
  
• master_log_file 和master_log_pos 根据上一步查询出来的File和Position值自行更换。
  

启动从节点

1. start slave;

复制代码

最终这两个参数都是yes就搭建完成了，但是也要注意是否有报错信息
判断是否乐成重要看 Slave_IO_Running 和 Slave_SQL_Running 是否都为YES。

上面的两个yes，笔者也走过许多弯路，才走到的，并不是一下子就乐成的，下面我归纳一下，我搭建过程中遇到的问题
4.4 遇到报错办理

环境1：Slave_IO_Running为No
由于有些同砚为了方便，服务器都是克隆的，所以就会造成安装目次auto.cnf文件里对比server-uuid是一样的，可以自行排查一下
办理办法:
首先安装目次auto.cnf文件里对比server-uuid 是否一样，如果一样修改了不一样就行，大概删了文件重启mysql服务。

1. cat /var/lib/mysql/auto.cnf

复制代码

保持server-uuid不一样即可
环境2：Slave_IO_Running为Connecting
发生Slave_IO_Running为Connecting的环境许多，各人可以参考这篇文章：花开城南,这篇文章基本归纳了出现Connecting的环境，但是，我的遇到问题还不是这内里的

查看报错信息

发现是密码的认证方式有问题，上网查了一下，该博主 周杰伦的稻香的办理方法可以，我采用的是第一种方法，但是每次重启服务器大概MySQL服务，都需要现在从服务器节点的MySQL上，登录一下主节点的MySQL，请求服务器公钥

1. mysql -u slave01 -p -h 192.168.3.131 -P3306 --get-server-public-key

复制代码

​ 在这种环境下，服务器将RSA公钥发送给客户端，后者使用它来加密密码并将结果返回给服务器。插件使用服务器端的RSA私钥解密密码，并根据密码是否精确来接受或拒绝连接。

• 主从节点都重新制止主从复制，清空之前的主从复制配置信息
  
• 在从库配置change masrer to并且start slave，复制可以正常启动：
  

1. #主从节点都停止主从复制，在两个MySQL客户端中分别执行
2. #清空之前的主从复制配置信息
3. stop slave;
4. reset master;
6. #从新配置主从复制
7. change master to master_host='192.168.3.131',master_user='slave01',master_password='123456',master_log_file='master-a-bin.000001',master_log_pos=156;

复制代码

环境3：Slave_IO_Running为Connecting，报错：could not find first log file name in binary log index file

办理方法：

1. stop slave;
2. reset slave;
3. start slave;

复制代码

环境4：主从服务器的MySQL的master状态不一致
重启过，配置信息会发生变革

因为之前已经创建过主节点服务器，需停掉之前的配置 再重新配置

1. stop slave;
2. reset master;

复制代码

需要重新指定主节点服务器信息

1. change master to master_host='192.168.3.131',master_user='slave01',master_password='123456',master_log_file='master-a-bin.000002',master_log_pos=156;

复制代码

主节点数据库备份操纵
使用mysqldump命令，将test数据库备份下来

1. mysqldump -uroot -p'123456' -B test > /backup/mysql_bak.$(date +%F).sql.gz

复制代码

长途发送到从节点上

1. scp /backup/mysql_bak.2024-04-01.sql.gz 192.168.3.137:/backup/

复制代码

从库数据库还原操纵
先创建数据库，否则没有数据库名，会报错

1. mysqldump -uroot -p'123456' -B test < /backup/mysql_bak.$(date +%F).sql.gz

复制代码

从库已备份到主库的数据库
4.5 主从复制测试

在主节点创建数据库，名称为配置文件里需要同步的数据库名称，比方

1. create database db_test;

复制代码

查看从节点，已经同步

创建一个表

1. CREATE TABLE `departments` (
2.   `department_id` int NOT NULL DEFAULT '0',
3.   `department_name` varchar(30) NOT NULL,
4.   `manager_id` int DEFAULT NULL,
5.   `location_id` int DEFAULT NULL,
6.   PRIMARY KEY (`department_id`),
7.   UNIQUE KEY `dept_id_pk` (`department_id`),
8.   KEY `dept_loc_fk` (`location_id`),
9.   KEY `dept_mgr_fk` (`manager_id`)
10. )

复制代码

可以看到，从节点也已经同步。

插入数据

1. INSERT INTO `departments` VALUES ('10', 'Administration', '200', '1700');

复制代码

可以看到，数据也已经同步。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。