MySQL主从复制与读写分离

简介

在企业应用中，成熟的业务通常数据量都比较大单台Mysql在安全性、高可用性和高并发方面都无法满足实际的需求配置多台主从数据库服务器以实现读写分离

什么是读写分离

读写分离，基本的原理是让主数据库处理事务性增、改、删操作( INSERT、UPDATE、DELETE) ，而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

为什么要读写分离

因为数据库的“写”（写10000条数据可能要3分钟）操作是比较耗时的。

但是数据库的“读”（读10000条数据可能只要5秒钟）；

所以读写分离，解决的是，数据库的写入，影响了查询的效率。

什么时候要读写分离

数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用。利用数据库主从同步，再通过读写分离可以分担数据库压力，提高性能。

读写分离原理

读写分离就是只在主服务器上写，只在从服务器上读。

基本的原理是让主数据库处理事务性查询，而从数据库处理 select 查询。

数据库复制被用来把主数据库上事务性查询导致的变更同步到集群中的从数据库。

主从复制与读写分离

在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。

因此，通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。有点类似于rsync（文件同步工具），但是不同的是rsync是对磁盘文件做备份，而mysql主从复制是对数据库中的数据、语句做备份。

mysql支持的复制类型

（1） STATEMENT：基于语句的复制。在服务器上执行sql语句，在从服务器上执行同样的语句，mysql默认采用基于语句的复制（5.7版本之前），执行效率高。高并发的情况可能会出现执行顺序的误差，事务的死锁。

（2）ROW：基于行的复制。把改变的内容复制过去，而不是把命令在从服务器上执行一遍。精确，但效率低，保存的文件会更大。（5.7版本之后默认采用ROW模式）

（3）MIXED：混合类型的复制。默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。更智能，所以大部分情况下使用MIXED。

主从复制的工作过程*

Master节点需要开启二进制日志，Slave节点需要开启中继日志。

（1）Master 节点将数据的改变记录成二进制日志（bin log） ，当Master上的数据发生改变时（增删改），则将其改变写入二进制日志中。

（2）Slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O线程请求Master的二进制事件。（请求二进制数据）

（3）同时Master 节点为每个I/O线程启动一个dump线程，用于通知和向其发送二进制事件，I/O线程接收到bin-log内容后，将内容保存至slave节点本地的中继日志（Relay log）中，Slave节点将启动SQL线程从中继日志中读取二进制事件，在本地重放，即解析成sql 语句逐一执行，使得其数据和Master节点的保持一致。最后I/O线程和SQL线程将进入睡眠状态，等待下一次被唤醒。

注意：

中继日志通常会位于 OS 缓存中，所以中继日志的开销很小。
复制过程有一个很重要的限制，即复制在 Slave上是串行化的，也就是说 Master上的并行更新操作不能在 Slave上并行操作。
半同步复制，会多一个ack确认线程（ack collector thread），专门用于接收slave 的反馈信息（收集slave节点返回的ack信息）。

数据库主从数据不一致解决方案

方法一：忽略错误后，继续同步

该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况。

方式二：重新做主从，完全同步

该方法适用于主从库数据相差较大，或者要求数据完全统一的情况

mysql从服务器挂了恢复后怎么保证数据同步？

物理方法： rsync 磁盘文件同步。使用文件恢复，主节点需要停服务。
主从复制： 将从节点原有库删除，通过偏移量，重新做一次主从复制。

半同步复制什么情况下会降为异步复制？什么时候又会恢复同步复制？

当半同步复制发生超时（由rpl_semi_sync_master_timeout 参数控制，默认为10000ms，即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。
当malster dump 线程发送完一个事务的所有事件之后，如果在rpl_ semi_sync_master_ timeout 内，收到了从库的响应，则主从又重新恢复为半同步复制。

MySQL主从复制延迟原因和优化方法

主从复制延迟原因：
master服务器高并发，形成大量事务。
网络延迟。
主从硬件设备导致（cpu主频、内存IO、硬盘IO）。
是同步复制，而不是异步复制。

优化方法：

从库优化Mysql参数。比如增大innodb_buffer_pool_size，让更多操作在Mysql内存中完成，减少磁盘操作。
从库使用高性能主机。包括cpu强悍、内存加大。避免使用虚拟云主机，使用物理主机，这样提升了I/O方面性。
从库使用SSD磁盘。
网络优化，避免跨机房实现同步。

MySQL主从复制的几个同步模式

1、异步复制（Asynchronous replication）

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

2、全同步复制（Fully synchronous replication）

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

3、半同步复制（Semisynchronous replication）

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

主从复制案例演示（异步复制）

实验环境

Master 服务器：192.168.68.101，mysql5.7

Slave1 服务器：192.168.68.111，mysql5.7

Slave2 服务器：192.168.68.112，mysql5.7

兄弟们上面手误master是192.168.68.101.

主从服务器时间同步。
配置主服务器，修改其配置文件，在主数据库中创建一个同步账号授权给从数据库使用。
配置从数据库，修改其配置文件，在从数据库中配置同步。
验证能否同步成功。
关闭防火墙和selinux
```
systemctl stop firewalld
setenforce 0
```
MYSQL主从服务器时间同步

时间同步：
- 每台mysql服务器需要设置时间同步，以免数据同步时产生错乱。
- 如果不通外网，则使用ntp服务。如果通外网，可以使用网络时钟源。
（1）主服务器使用本地时钟源

#安装时间同步工具（本地设置时钟源）
 yum install -y ntp
 
 #修改ntp配置文件，在末尾加入
 vim /etc/ntp.conf
 server 127.127.68.0              #设置本地时钟源，注意修改网段（136是网段）
 fudge 127.127.68.0 stratum 8     #设置时间层级为8（限制在15以内）
 
 #开启ntpd
 systemctl start ntpd

（2）两台从服务器同步主服务器的时间。

#安装时间同步工具
 yum install -y ntp
 #开启ntpd
 systemctl start ntpd
 
 #和主服务器进行时间同步
 /usr/sbin/ntpdate 192.168.68.101
 
 #设置定时任务，每30分钟同步一次
 crontab -e  
 */30 * * * * /usr/sbin/ntpdate 192.168.68.101

主服务器的mysql配置

修改配置文件，创建一个同步账号授权给从数据库使用。

 vim /etc/my.cnf
 [mysqld]
 ......
 server-id = 1               #指定服务ID号，master和两台slave都要不同
 log-bin=mysql-bin           #添加，主服务器开启二进制日志
 binlog_format = MIXED       #指定二进制日志(binlog)的记录格式为MIXED
 log-slave-updates=true      #添加，允许slave从master复制数据时可以写入到自己的二进制日志
 expire_logs_days = 7        #设置二进制日志文件过期时间，默认值为0，表示logs不过期
 max_binlog_size = 500M      #设置二进制日志限制大小，如果超出给定值，日志就会发生滚动，默认值是1GB
 
 #重启服务
 systemctl restart mysqld
 
 mysql -u root -pabc123
 #给从服务器授权
 grant replication slave on *.* to 'myslave'@'192.168.68.%' identified by 'abc123';  
 flush privileges;               #刷新权限
 
 show master status;     #查看主服务器状态
 
 #File 列显示日志名，Position 列显示偏移量

从服务器的mysql配置

#修改配置文件
 vim /etc/my.cnf
 [mysqld]
 ......
 server-id = 2            #修改，注意id与Master的不同，两个Slave的id也要不同
 relay-log=relay-log-bin  #添加，开启中继日志，从主服务器上同步日志文件记录到本地
 relay-log-index=slave-relay-bin.index   #添加，定义中继日志索引文件的位置和名称，一般和relay-log在同一目录
 relay_log_recovery = 1                  #选配项
 #当 slave 从库宕机后，假如 relay-log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay-log，并且重新从 master 上获取日志，这样就保证了 relay-log 的完整性。默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时， 可在 slave 从库上开启该功能，建议开启。
 ​
 #重启服务
 systemctl restart mysqld     
 ​
 #登录数据库，进行同步设置
 mysql -u root -p
 change master to master_host='192.168.68.101',master_user='myslave',master_password='abc123',master_log_file='mysql-bin.000001',master_log_pos=603;     
 #配置同步，注意 master_log_file 和 master_log_pos 的值要与Master查询的一致
 ​
 start slave;                #启动同步，如有报错执行 reset slave;
 ​
 show slave status\G         #查看 Slave 状态
 ##确保 IO 和 SQL 线程都是 Yes，代表同步正常。
 Slave_IO_Running: Yes               #负责与主机的IO通信
 Slave_SQL_Running: Yes              #负责自己的slave mysql进程

　　server1：

server2:

一般 "Slave_IO_Running: No" 的可能原因：

网络不通
my.cnf配置有问题（server-id重复）
密码、file文件名、pos偏移量不对
防火墙没有关闭

验证主从复制效果

主服务器上创建新的数据库，执行 create database tt;

去从服务器上查看是否同步成功，执行 show databases;

主从复制案例演示（半同步复制）

实验环境

Master 服务器：192.168.68.101，mysql5.7

Slave1 服务器：192.168.68.111，mysql5.7

Slave2 服务器：192.168.68.112，mysql5.7

实验操作：

 -------1、所有服务器关闭防火墙------
 systemctl disable --now firewalld
 setenforce 0
 
 
 -------2、主数据库配置---------
 vim /etc/my.cnf             #在 [mysqld] 区域添加下面内容
 ......
 plugin-load=rpl_semi_sync_master=semisync_master.so     #加载mysql半同步复制的插件
 rpl_semi_sync_master_enabled=ON         #或者设置为"1"，即开启半同步复制功能
 rpl-semi-sync-master-timeout=1000       #超时时间为1000ms，即1s
 
 systemctl restart mysqld
 
 
 -------3、从数据库配置-----------
 vim /etc/my.cnf 
 ......
 plugin-load=rpl_semi_sync_slave=semisync_slave.so
 rpl_semi_sync_slave_enabled=ON
 
 systemctl restart mysqld
 
 
 -------4、查看半同步是否在运行---------------
 #主数据库执行
 show status like 'Rpl_semi_sync_master_status';
 show variables like 'rpl_semi_sync_master_timeout';
 
 #从数据库执行（此时可能还是OFF状态，需要在下一步重启IO线程后，从库半同步状态才会为ON）
 show status like 'Rpl_semi_sync_slave_status';
 
 #重启从数据库上的IO线程
 STOP SLAVE IO_THREAD;
 START SLAVE IO_THREAD;
 
 #在主库查询半同步状态
 show status like '%Rpl_semi%';  
 
 
 参数说明：
 Rpl_semi_sync_master_clients                    #半同步复制客户端的个数
 Rpl_semi_sync_master_net_avg_wait_time          #平均等待时间（默认毫秒）
 Rpl_semi_sync_master_net_wait_time              #总共等待时间
 Rpl_semi_sync_master_net_waits                  #等待次数
 Rpl_semi_sync_master_no_times                   #关闭半同步复制的次数
 Rpl_semi_sync_master_no_tx                      #表示没有成功接收slave提交的次数
 Rpl_semi_sync_master_status                     #表示当前是异步模式还是半同步模式，on为半同步
 Rpl_semi_sync_master_timefunc_failures          #调用时间函数失败的次数
 Rpl_semi_sync_master_tx_avg_wait_time           #事物的平均传输时间
 Rpl_semi_sync_master_tx_wait_time               #事物的总共传输时间
 Rpl_semi_sync_master_tx_waits                   #事物等待次数
 Rpl_semi_sync_master_wait_pos_backtraverse      #可以理解为"后来的先到了，而先来的还没有到的次数"
 Rpl_semi_sync_master_wait_sessions              #当前有多少个session因为slave的回复而造成等待
 Rpl_semi_sync_master_yes_tx                     #成功接受到slave事物回复的次数
 
 当半同步复制发生超时（由rpl_semi_sync_master_timeout参数控制，默认为10000ms，即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。
 当 master dump 线程发送完一个事务的所有事件之后，如果在 rpl_semi_sync_master_timeout 内，收到了从库的响应， 则主从又重新恢复为半同步复制。

注意：

1）在一主多从的架构中，如果要开启半同步复制，并不要求所有的从都是半同步复制。

2）MySQL 5.7极大的提升了半同步复制的性能。

5.6 版本的半同步复制，dump thread 承担了两份不同且又十分频繁的任务：传送binlog 给 slave ，还需要等待 slave 反馈信息，而且这两个任务是串行的，dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的系统吞吐量(TPS)。
5.7 版本的半同步复制中，独立出一个 ack collector thread ，专门用于接收 slave 的反馈信息。这样 master 上有两个线程独立工作，可以同时发送 binlog 到 slave ，和接收 slave 的反馈。

半同步复制什么情况下会降为异步复制？什么时候又会恢复同步复制？

当半同步复制发生超时（由rpl_semi_sync_master_timeout 参数控制，默认为10000ms，即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。

当malster dump 线程发送完一个事务的所有事件之后，如果在rpl_ semi_sync_master_ timeout 内，收到了从库的响应，则主从又重新恢复为半同步复制。

六、读写分离概念

6.1 MySQL读写分离原理

读写分离就是只在主服务器上写，只在从服务器上读。
基本的原理是让主数据库处理事务性操作，而从数据库处理select查询。
数据库复制被用来把主数据库上事务性操作导致的变更，同步到集群中的从数据库。

6.2 目前较为常见的MysQL读写分离分为以下两种

1）基于程序代码内部实现

在代码中根据select、insert进行路由分类，这类方法也是目前生产环境应用最广泛的。

优点是性能较好，因为在程序代码中实现，不需要增加额外的设备为硬件开支；缺点是需要开发人员来实现，运维人员无从下手。

但是并不是所有的应用都适合在程序代码中实现读写分离，像一些大型复杂的Java应用，如果在程序代码中实现读写分离对代码改动就较大。

2）基于中间代理层实现

代理一般位于客户端和服务器之间，代理服务器接到客户端请求后通过判断后转发到后端数据库，有以下代表性程序。

（1）MySQL-Proxy。MySQL-Proxy为MysQL开源项目，通过其自带的1ua脚本进行sQL判断。

（2）Atlas。是由奇虎360的Web平台部基础架构团队开发维护的一个基于MysQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用atlas运行的mysql业务，每天承载的读写请求数达几干保条。支持事物以及存储过程。

（3）Amoeba。由陈思儒开发，作者曾就职于阿里巴巴。该程序由Java语言进行开发，阿里巴巴将其用于生产环境。但是它不支持事务和存储过程。

（4）Mycat。是一款流行的基于Java语言编写的数据库中间件，是一个实现了MySq1协议的服务器，其核心功能是分库分表。配合数据库的主从模式还可以实现读写分离。

由于使用MysQLProxy需要写大量的ua脚本，这些Lua并不是现成的，而是需要自己去写。这对于并不熟悉MysQLProxy 内置变量和MySQL Protocol的人来说是非常困难的。

Amoeba是一个非常容易使用、可移植性非常强的软件。因此它在生产环境中被广泛应用于数据库的代理层。

读写分离案例（使用Amoeba）

1）安装 Java 环境

 #因为 Amoeba 基于是 jdk1.5 开发的，所以官方推荐使用 jdk1.5 或 1.6 版本，高版本不建议使用。
 
 #先将jdk的二进制文件上传到/opt/目录下，之后复制到/usr/local/目录下
 [root@Amo ~]# cd /opt/
 [root@Amo opt]# cp jdk-6u14-linux-x64.bin /usr/local/
 [root@Amo opt]# cd /usr/local/
 [root@Amo local]# chmod +x jdk-6u14-linux-x64.bin     #为二进制文件增加执行权限
 [root@Amo local]# ./jdk-6u14-linux-x64.bin
 ##按yes，按enter
 
 [root@Amo local]# mv jdk1.6.0_14/ /usr/local/jdk1.6     #将jdk目录重命名
 
 #添加环境变量
 [root@Amo local]# vim /etc/profile
 export JAVA_HOME=/usr/local/jdk1.6
 export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
 export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
 export AMOEBA_HOME=/usr/local/amoeba
 export PATH=$PATH:$AMOEBA_HOME/bin
 
 [root@Amo local]# source /etc/profile     #刷新文件，使立即生效
 [root@Amo local]# java -version           #查看jdk版本

2）安装 Amoeba软件

 -------1、安装 Amoeba软件---------
 #创建Amoeba的解压目录
 [root@Amo ~]# mkdir /usr/local/amoeba/
 #将Amoeba安装包上传到/opt/目录，解压安装包
 [root@Amo opt]# cd /opt/
 [root@Amo opt]# tar zxvf amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/
 #增加目录权限
 [root@Amo opt]# chmod -R 755 /usr/local/amoeba/
 #开启Amoeba
 [root@Amo opt]# /usr/local/amoeba/bin/amoeba      #如显示amoeba start|stop说明安装成功
 
 
 -------2、配置 Amoeba读写分离，两个 Slave 读负载均衡----------
 
 #先在Master、Slave1、Slave2 的mysql上开放权限给 Amoeba 访问。注意：这里授权的用户名和密码，会在下一步写入数据库配置文件。
 grant all on *.* to yuji@'192.168.68.%' identified by '123123';
 
 #再回到amoeba服务器配置amoeba服务：
 [root@Amo opt]# cd /usr/local/amoeba/conf/
 
 #备份配置文件，修改amoeba配置文件
 [root@Amo conf]# cp amoeba.xml amoeba.xml.bak
 [root@Amo conf]# vim amoeba.xml
 --30行--
 <property name="user">amoeba</property>     #30行和32行，授权客户端用于登录amoeba的账号和密码
 --32行-- 
 <property name="password">123456</property>
 
 --115行--
 <property name="defaultPool">master</property>  #设置默认服务器池
 --117-去掉注释-
 <property name="writePool">master</property>   #定义写的服务器池名称
 <property name="readPool">slaves</property>    #定义读的服务器池名称
 
 
 #备份数据库配置文件，之后修改数据库配置文件dbServers.xml
 [root@Amo conf]# cp dbServers.xml dbServers.xml.bak
 [root@Amo conf]# vim dbServers.xml  
 --23行--注释掉  作用：默认进入test库，注释掉以防mysql中没有test库时，会报错
 <!-- <property name="schema">test</property> -->
 
 ##26-30行，此用户就是之前在3台主从服务器上授权的用户，授权amoeba服务器用来登录mysql数据库的用户和密码。
 --26行--修改
 <property name="user">yuji</property>  
 --28-30行--去掉注释
 <property name="password">123123</property>
 
 --45行--修改，设置主服务器的名称master和地址
 <dbServer name="master"  parent="abstractServer">
 --48行--修改，设置主服务器的地址
 <property name="ipAddress">192.168.68.101</property>
 
 --52行--修改，设置从服务器1的名称slave1
 <dbServer name="slave1"  parent="abstractServer">
 --55行--修改，设置从服务器1的地址
 <property name="ipAddress">192.168.68.111</property>
 --58行--复制上面6行粘贴，设置从服务器2的名称slave2和地址
 <dbServer name="slave2"  parent="abstractServer">
 <property name="ipAddress">192.168.68.112</property>
 
 --65行--修改
 <dbServer name="slaves" virtual="true">
 --71行--修改
 <property name="poolNames">slave1,slave2</property>
 
 
 [root@Amo conf]# /usr/local/amoeba/bin/amoeba start &  #后台启动Amoeba软件，按ctrl+c 返回
 [root@Amo conf]# netstat -anpt | grep java            #查看8066端口是否开启，默认端口为TCP 8066

先在Master、Slave1、Slave2 的mysql上开放权限给 Amoeba 访问：

grant all on . to yuji@'192.168.68.%' identified by '123123';

再回到amoeba服务器配置amoeba服务：

修改amoeba的配置文件amoeba.xml

修改数据库配置文件dbServers.xml

后台启动Amoeba软件，并查看端口是否已开启：

7.2 客户端安装mariadb数据库

客户端：192.168.68.100

 [root@yuji ~]# yum install -y mariadb-server mariadb   #安装mariadb数据库
 [root@yuji ~]# systemctl start mariadb.service         #启动mariadb
 
 
 #客户端通过amoeba服务器登录数据库，之后向库中写入数据：
 mysql -u amoeba -p123456 -h 192.168.68.101 -P8066        
 use yuji666;
 create table class(id int,name char(10));
 #通过amoeba服务器代理访问mysql ，再通过客户端连接mysql后写入的数据只有主服务会记录，然后同步给从--从服务器

查看master服务器：

查看slave服务器：

7.3 测试读写分离

 //在两台slave服务器上，关闭同步：
 stop slave;                 #关闭同步
 use yuji666;
 
 //在slave1上写入数据：
 insert into class values('1','zhangsan');
 
 //在slave2上写入数据：
 insert into class values('2','lisi');
 
 //在master服务器上写入数据：
 insert into class values('3','wangwu');
 
 //在客户端上查看数据：
 use yuji666;
 select * from class;        
 #客户端会分别向slave1和slave2读取数据（轮询），显示的只有在两个从服务器上添加的数据，没有在主服务器上添加的数据。说明读写是分离的，只从slave中读取数据。
 
 insert into class values('4','qianqi',);    //客户端插入数据，只有主服务器上有此数据
 
 //在两个从服务器上执行 start slave; 即可实现同步主服务器中添加的数据
 start slave;             #开启同步
 select * from class;

slave1关闭同步，之后向class表中插入数据：

在master服务器上写入数据：

在客户端上查看数据：

slave服务器开启同步，即可同步主服务器中添加的数据：

重点总结：

1、主从复制的工作过程

Master节点需要开启二进制日志，Slave节点需要开启中继日志。

（1）Master 节点将数据的改变记录成二进制日志（bin log） ，当Master上的数据发生改变时（增删改），则将其改变写入二进制日志中。

（3）同时Master 节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至slave节点本地的中继日志（Relay log）中，，Slave节点将启动SQL线程从中继日志中读取二进制事件，在本地重放，即解析成sql 语句逐一执行，使得其数据和Master节点的保持一致。最后I/O线程和SQL线程将进入睡眠状态，等待下一次被唤醒。

注意：

中继日志通常会位于 OS 缓存中，所以中继日志的开销很小。
复制过程有一个很重要的限制，即复制在 Slave上是串行化的，也就是说 Master上的并行更新操作不能在 Slave上并行操作。
半同步复制，会多一个ack确认线程（ack collector thread），专门用于接收slave 的反馈信息（收集slave节点返回的ack信息）。

2、数据库主从数据不一致解决方案

方法一：忽略错误后，继续同步

该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况。

方式二：重新做主从，完全同步

该方法适用于主从库数据相差较大，或者要求数据完全统一的情况。

3、mysql从服务器挂了恢复后怎么保证数据同步？

物理方法： rsync 磁盘文件同步。使用文件恢复，主节点需要停服务。
主从复制： 将从节点原有库删除，通过偏移量，重新做一次主从复制。

4、半同步复制什么情况下会降为异步复制？什么时候又会恢复同步复制？

当半同步复制发生超时（由rpl_semi_sync_master_timeout 参数控制，默认为10000ms，即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。
当malster dump 线程发送完一个事务的所有事件之后，如果在rpl_ semi_sync_master_ timeout 内，收到了从库的响应，则主从又重新恢复为半同步复制。

5、MySQL主从复制延迟原因和优化方法

主从复制延迟原因：

master服务器高并发，形成大量事务。

网络延迟。

主从硬件设备导致（cpu主频、内存IO、硬盘IO）。

是同步复制，而不是异步复制。

优化方法：

从库优化Mysql参数。比如增大innodb_buffer_pool_size，让更多操作在Mysql内存中完成，减少磁盘操作。
从库使用高性能主机。包括cpu强悍、内存加大。避免使用虚拟云主机，使用物理主机，这样提升了I/O方面性。
从库使用SSD磁盘。
网络优化，避免跨机房实现同步。

6、注意事项

每个master可以有多个slave。

每个slave只能有一个master。

每个slave只能有一个唯一的服务器ID（server-id）。
master一定要开启binlog二进制日志功能；通常为了数据安全，slave也开启binlog功能。

MySQL 主从复制原理解读，出现同步延迟如何解决？

主从复制解决的问题

数据分布：通过复制将数据分布到不同地理位置
负载均衡：读写分离以及将读负载到多台从库
备份：可作为实时备份
高可用性：利用主主复制实现高可用

复制原理

复制的原理其实很简单，仅分为以下三步：

在主库上把数据更改记录到二进制日志binary log中，具体是在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中去，MySQL会按照事务提交的顺序来记录二进制日志的。日志记录好之后，主库通知存储引擎提交事务。
从库会启动一个IO线程，该线程会连接到主库。而主库上的binlog dump线程会去读取主库本地的binlog日志文件中的更新事件。发往从库，从库接收到日志之后会将其记录到本地的中继日志relay-log当中。
从库中的SQL线程读取中继日志relay-log中的事件，将其重放到从库中。（在5.6版本之前SQL线程是单线程的，使得主从之间延迟更大）

两种复制方式

日志文件中记录的到底是什么呢？mysql支持了两种日志格式，这两种日志格式也体现了各自的复制方式

基于语句复制

基于语句的复制相当于逻辑复制，即二进制日志记录了操作的语句，通过这些语句在从库进行重放来实现复制。

这种方式简单，二进制日志占用空间少，使得带宽小传输效率较高。但是基于语句的更新依赖于其他因素，比如插入数据时利用时间戳函数调用当前时间作为时间值也会出现问题，因为由于主从之间的延迟导致时间值不一致。存储过程和触发器也可能出现问题。

所以在开发当中我们应该将逻辑尽量放在代码层，而不应放到mysql中，不易扩展。

基于行复制

基于行的复制相当于物理复制，即二进制日志记录了实际更新数据的每一行。这样导致行复制的压力比较大，因为日志占用空间较大，传输占用带宽也较高。但是比基于语句复制更加精确，可以屏蔽一些由于主库从库之间的差异导致的不一致。如刚才提到的时间戳函数。

二者对比：

语句复制

传输效率高，减少延迟。
在从库更新不存在的记录时，语句赋值不会失败。而行复制会导致失败，从而更早发现主从之间的不一致。
设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录

行复制

不需要执行查询计划。
不知道执行的到底是什么语句。

例如一条更新用户总积分的语句，需要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库需要再一次统计用户的积分，而基于行复制就直接更新记录，无需再统计用户积分。

因为两种方式各有优缺点，所以mysql在这两种复制模式进行动态的切换。默认是语句。

配置要点

# 如果在双主复制结构中没有设置ID的话就会导致循环同步问题
server_id=1

# 即日志中记录的是语句还是行更新或者是混合
binlog_format=mixed

# 在进行n次事务提交以后，Mysql将执行一次fsync的磁盘同步指令。将缓冲区数据刷新到磁盘。
# 为0的话由Mysql自己控制频率。
sync_binlog=n

# 为0的话，log buffer将每秒一次地写入log file中并且刷新到磁盘。
# mysqld进程崩溃会丢失一秒内的所有事务。
# 为1的话，每次事务log buffer会写入log file并刷新到磁盘。（较为安全）
# 在崩溃的时候,仅会丢失一个事务。
# 为2的话，每次事务log buffer会写入log file，但一秒一次刷新到磁盘
innodb_flush_logs_at_trx_commit=0


# 阻止从库崩溃后自动启动复制，给一些时间来修复可能的问题，
# 崩溃后再自动复制可能会导致更多的问题。并且本身就是不一致的
skip_slave_start=1 


# 是否将从库同步的事件也记录到从库自身的bin-log中
# 允许备库将重放的事件也记录到自身的二进制日志中去，可以将备库当做另外一台主库的从库
log_slave_update 

# 日志过期删除时间，延迟严重的话会导致日志文件占用磁盘
expire_logs_days=7

innodb_flush_logs_at_trx_commit的三个参数很容易弄混。以下是详细的解析：

mysql先将日志写到log buffer缓冲区当中，再将log buffer缓冲区的数据写到log file日志文件中，此时写入的是内存中的log file，最终仍需操作系统将内存中的数据刷写到磁盘上。

参数0：mysql每秒都会将log buffer的数据写入到log file中并且刷新到磁盘。意味着mysql崩溃的时候将会丢失一秒内的所有事务。

参数1：每次事务提交都会将log buffer写入到log file并刷新到磁盘。意味着在mysql崩溃的时候,仅会丢失一个事务。

参数2：每次事务提交都会将log buffer写入到log file但不同时写入到磁盘，由mysql自行控制每秒将log file刷写到磁盘上，当mysql崩溃的时候操作系统没崩溃的时候，log_file中仅会丢失一个事务，操作系统仍会将log file刷写到磁盘，而如果操作系统也崩溃或断电的话，则会丢失一秒内的事务。

推荐使用：

innodb_flush_logs_at_trx_commit=2
sync_binlog=500

性能会较快

innodb_flush_logs_at_trx_commit=1
sync_binlog=1

较为安全

延迟问题

延迟的产生

当主库的TPS并发较高时，由于主库上面是多线程写入的，而从库的SQL线程是单线程的，导致从库SQL可能会跟不上主库的处理速度（生产者比消费者快，导致商品堆积）。

延迟的解决

网络方面：将从库分布在相同局域网内或网络延迟较小的环境中。
硬件方面：从库配置更好的硬件，提升随机写的性能。
配置方面：

从库配置

sync_binlog=0
innodb_flush_log_at_trx_commit=2
logs-slave-updates=0
增大 innodb_buffer_pool_size

让更多操作在Mysql内存中完成，减少磁盘操作。或者升级Mysql5.7版本使用并行复制。

架构方面：比如在事务当中尽量对主库读写，其他非事务中的读在从库。消除一部分延迟带来的数据库不一致。增加缓存降低一些从库的负载。

posted @ 2022-12-01 21:35 风夏呀阅读(85) 评论(0) 编辑收藏举报

刷新页面返回顶部

登录后才能查看或发表评论，立即登录或者逛逛博客园首页

相关博文：

· MYSQL之日志管理、备份与恢复

· MySQL高可用之MHA集群

· MySQL主从复制与读写分离

· MySQL主从复制于读写分离

· MySQL主从复制与读写分离

阅读排行：
· TypeScript + Deepseek 打造卜卦网站：技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· 从HTTP原因短语缺失研究HTTP/2和HTTP/3的设计差异
· 三行代码完成国际化适配，妙~啊~

公告

昵称：风夏呀
园龄： 2年6个月
粉丝： 9
关注： 7

+加关注

2025年3月

日

一

二

三

四

五

六

随笔分类

OSI模型 TCP/IP协议(1)

随笔档案

阅读排行榜

评论排行榜

1. 综合布线子网掩码 IP地址子网划分(1)

简介

什么是读写分离

为什么要读写分离

什么时候要读写分离

读写分离原理

主从复制与读写分离

mysql支持的复制类型

主从复制的工作过程*

数据库主从数据不一致解决方案

mysql从服务器挂了 恢复后怎么保证数据同步？

半同步复制什么情况下会降为异步复制？什么时候又会恢复同步复制？

MySQL主从复制延迟原因和优化方法

MySQL主从复制的几个同步模式

主从复制案例演示（异步复制）

实验环境

兄弟们上面手误master是192.168.68.101.

关闭防火墙和selinux

MYSQL主从服务器时间同步

主服务器的mysql配置

从服务器的mysql配置

验证主从复制效果

主从复制案例演示（半同步复制）

实验环境

实验操作：

六、读写分离概念

6.1 MySQL读写分离原理

6.2 目前较为常见的MysQL读写分离分为以下两种

1）基于程序代码内部实现

2）基于中间代理层实现

读写分离案例（使用Amoeba）

1）安装 Java 环境

2）安装 Amoeba软件

grant all on *.* to yuji@'192.168.68.%' identified by '123123'; ​

7.2 客户端安装mariadb数据库

7.3 测试读写分离

重点总结：

1、主从复制的工作过程

2、数据库主从数据不一致解决方案

3、mysql从服务器挂了 恢复后怎么保证数据同步？

4、半同步复制什么情况下会降为异步复制？什么时候又会恢复同步复制？

5、MySQL主从复制延迟原因和优化方法

6、注意事项

MySQL 主从复制原理解读，出现同步延迟如何解决？

主从复制解决的问题

复制原理

两种复制方式

基于语句复制

基于行复制

二者对比：

配置要点

延迟问题

延迟的产生

延迟的解决

公告

搜索

常用链接

随笔档案

mysql从服务器挂了恢复后怎么保证数据同步？

grant all on . to yuji@'192.168.68.%' identified by '123123';

3、mysql从服务器挂了恢复后怎么保证数据同步？