Mysql的主从复制和读写分离

一、Mysql读写分离的相关知识

1.什么是读写分离？

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

2.为什么要读写分离呢?

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

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

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

3.什么时候要读写分离？

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

二、主从复制的相关知识 

1.主从复制的优点

• 数据分布：通过复制将数据分布到不同地理位置

• 负载均衡：读写分离以及将读负载到多台从库

• 备份：可作为实时备份

• 高可用性：利用主主复制实现高可用

2.主从复制与读写分离

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

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

3.mysql支持的复制类型 

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

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

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

  STATEMENT和row的对比

STATEMENT：

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

row

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

4. mysql主从复制的工作过程

主从复制基于主mysql服务器和从mysql服务器的三个线程和两个日志展开进行的：

两个日志：二进制日志（bin log） 、中继日志（Relay log）

三个线程：I/O线程、dump线程、SQL线程

 5.主从复制的几个同步模式

（1）异步复制（Asynchronous replication）

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

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

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

（3）半同步复制（Semisynchronous replication）

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

三、主从复制的常见问题及解决方案 

1.主从复制延迟的原因及解决方案 

主从复制延迟原因

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

解决方案
 （1）硬件方面
从库配置更好的硬件，提升随机写的性能。比如原本是机械盘，可以考虑更换为ssd固态。升级核心数更强的cpu、加大内存。避免使用虚拟云主机，使用物理主机

（2）网络方面 
  将从库分布在相同局域网内或网络延迟较小的环境中。尽量避免跨机房，跨网域进行主从数据库服务器的设置

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

（4）mysqld服务配置方面 
该配置设置针对mysql主从复制性能优化最大化，安全性并不高。如果从安全的角度上考虑的话，就要设置双一设置

追求安全性的双一设置：

innodb_flush_log_at_trx_commit=1
sync_binlog=1

 追求性能化设置：

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

配置讲解

1）sync_binlog：binlog 的刷盘策略，默认为0

• 如果为 0，像操作系统刷其他文件的机制一样，MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log。
• sync_binlog = N (N>0)，MySQL 在每写 N 次 二进制日志binary log时，会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。

2）innodb_flush_log_at_trx_commit：redo log 的刷盘策略，默认为 1

• 如果innodb_flush_log_at_trx_commit设置为 0：log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行.该模式下，在事务提交的时候，不会主动触发写入磁盘的操作;
• 如果innodb_flush_log_at_trx_commit设置为 1：每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去;
• 如果innodb_flush_log_at_trx_commit设置为 2：每次事务提交时MySQL都会把log buffer的数据写入log file，但是flush(刷到磁盘)操作并不会同时进行。该模式下,MySQL会每秒执行一次 flush(刷到磁盘)操作。 

3）logs-slave-updates=0 

 从服务器从主服务器接收到的更新不记入它的二进制日志 

 4）innodb_buffer_pool_size 

•  它的是一个内存区域，用来缓存 InnoDB存储引擎的表中的数据和索引数据。以便提高对 InnoDB存储引擎表中数据的查询访问速度。
• 在查看 innodb_buffer_pool_size这个参数值的时候，是以 字节(byte)为单位进行展现的。它的默认值为 134217728字节，也就是 128MB(134217728/1204/1024=128MB，1MB=1024KB,1KB=1024Byte)。
• 在MySQL 5.7.5版本后，可以在不重启MySQL数据库服务的情况下，动态修改这个参数的值，但是在此版本之前的老版本修改后需要重启数据库服务才可以生效。

2.主从复制不一致的原因及解决方案 

 产生主从复制不一致的可能原因

• 人为原因导致从库与主库数据不一致（从库写入）
• 主从复制过程中，主库异常宕机
• 设置了ignore/do/rewrite等replication等规则
• binlog非row格式
• 异步复制本身不保证，半同步存在提交读的问题，增强半同步起来比较完美。 但对于异常重启（Replication Crash Safe），从库写数据（GTID）的防范，还需要策略来保证。
• 从库中断很久，binlog应用不连续，监控并及时修复主从
• 从库启用了诸如存储过程，从库禁用存储过程等
• 数据库大小版本/分支版本导致数据不一致？，主从版本统一
• 备份的时候没有指定参数 例如mysqldump --master-data=2 等
• 主从sql_mode 不一致
• 一主二从环境，二从的server id一致
• MySQL自增列 主从不一致
• 主从信息保存在文件里面，文件本身的刷新是非事务的，导致从库重启后开始执行点大于实际执行点
• 采用5.6的after_commit方式半同步，主库当机可能会引起主从不一致，要看binlog是否传到了从库
• 启用增强半同步了（5.7的after_sync方式），但是从库延迟超时自动切换成异步复制
   

预防方案 

（1）双一配置进行

  master配置：

innodb_flush_log_at_trx_commit=1
sync_binlog=1

slave配置： 

master_info_repository="TABLE"
relay_log_info_repository="TABLE"
relay_log_recovery=1

 （2） 将从库设置为只读模式

（3）可以使用5.7增强半同步避免数据丢失等。

（4）binlog row格式

（5）必须引定期的数据校验机制。 

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

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

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

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

四、主从复制（异步）的详细操作

实验设计

本次实验采用的是一主二从的异步主从设置。需求：在主机中创建更新的数据库列表，能在短时间内更新到从数据库中。 

 master主库服务器：192.168.190.10/24    

slave从库服务器01：192.168.190.20/24

slave从库服务器02：192.168.190.30/24

1.同步主从服务器的时间

时间同步的原因：

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

 1）msater 服务器的时间同步 

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

 

 2）两台slave服务器的时间同步 

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

 注意：

如果出现ntpdate更新后时间不一致，尝试：

service  ntpd  stop
 /usr/sbin/ntpdate 192.168.190.10
systemctl  start  ntpd

2.主服务器的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 -p
 
 #给从服务器授权
 grant replication slave on *.* to 'myslave'@'192.168.190.%' identified by 'abc123';  
 flush privileges;               #刷新权限
 ​
 show master status;     #查看主服务器状态

 3.从服务器的配置部署 

两台slave配置一致（server-id  设置不同即可，其他操作均相同）

 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.190.10',master_user='myslave',master_password='abc123',master_log_file='mysql-bin.000001',master_log_pos=604;     
 
 #配置同步，注意 master_log_file 和 master_log_pos 的值要与Master查询的一致
 ​
 start slave;                #启动同步，如有报错执行 reset slave;
 ​
 show slave status\G         #查看 Slave 状态
 

从服务器20： 

 从服务器30:

 注意：

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

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

4.主从复制的测试 

1）主服务器创建数据，从服务器复制数据 

主服务器：创建测试数据

 从服务器20：

 从服务器30：

2) 从服务器更新数据，是否主服务器能查看 

 查看主服务器

 实验结论 

 验证了主从复制过程中，从服务时通过io线程记录主发来的二进制文件保存在中继日志中，

通过sql线程的重放获取数据，此过程时主服务器对从服务器的一个单向过程，不可逆。

五、主从复制中的（半同步）设置 

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 的反馈。

 -------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 内，收到了从库的响应， 则主从又重新恢复为半同步复制。

六、 Amoeba读写分离与主从复制的结合运用

 实验设计

结合上一个主从复制的实验，引用Amoeba服务器，使客户端发来的读写请求，进行读写分离，写的操作交予主mysql主服务器处理，读的操作由从库服务器进行处理。 

 master主库服务器：192.168.190.10/24    

slave从库服务器01：192.168.190.20/24

slave从库服务器02：192.168.190.30/24

 Aomeba读写分离服务器：192.168.190.50/24

客户端：192.168.190.40/24

省略上面的一主二从实验  

1.Amoeba服务器安装 Java 环境

因为 Amoeba 基于是 jdk1.5 开发的，所以官方推荐使用 jdk1.5 或 1.6 版本，高版本不建议使用。 

Amoeba主机：

 cd /opt/
 cp jdk-6u14-linux-x64.bin /usr/local/
 cd /usr/local/
 chmod +x jdk-6u14-linux-x64.bin     #为二进制文件增加执行权限
./jdk-6u14-linux-x64.bin
 ##按yes，按enter
 ​
 mv jdk1.6.0_14/ /usr/local/jdk1.6     #将jdk目录重命名
 ​
 #添加环境变量
 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
 ​
 source /etc/profile     #刷新文件，使立即生效
 java -version           #查看jdk版本

 2.安装 Amoeba软件 

 Aomeba主机：

 #创建Amoeba的解压目录
mkdir /usr/local/amoeba/
 #将Amoeba安装包上传到/opt/目录，解压安装包
cd /opt/
tar zxvf amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/
 #增加目录权限
chmod -R 755 /usr/local/amoeba/
 #开启Amoeba
/usr/local/amoeba/bin/amoeba      #如显示amoeba start|stop说明安装成功
 

 3.配置 Amoeba读写分离，两个 Slave 读负载均衡 

1）matser，两台slave的设置：

#先在Master、Slave1、Slave2 的mysql上开放权限给 Amoeba 访问。注意：这里授权的用户名和密码，会在下一步写入数据库配置文件。
 grant all on *.* to amoeba@'192.168.190.%' identified by 'abc123';
 

2)  Aomeba主机amoeba.xml配置文件的设置：

cd /usr/local/amoeba/conf/
 ​
 #备份配置文件，修改amoeba配置文件
cp amoeba.xml amoeba.xml.bak
vim amoeba.xml
 --30行--
 <property name="user">amoeba</property>     #30行和32行，授权客户端用于登录amoeba的账号和密码
 --32行-- 
 <property name="password">abc123</property>
 ​
 --115行--
 <property name="defaultPool">master</property>  #设置默认服务器池
 --117-去掉注释-
 <property name="writePool">master</property>   #定义写的服务器池名称
 <property name="readPool">slaves</property>    #定义读的服务器池名称
 

3)  Aomeba主机dbServers.xml配置文件的设置：

 #备份数据库配置文件，之后修改数据库配置文件dbServers.xml
cp dbServers.xml dbServers.xml.bak
vim dbServers.xml  
 --23行--注释掉  作用：默认进入test库，注释掉以防mysql中没有test库时，会报错
 <!-- <property name="schema">test</property> -->
 ​
 ##26-30行，此用户就是之前在3台主从服务器上授权的用户，授权amoeba服务器用来登录mysql数据库的用户和密码。
 --26行--修改
 <property name="user">amoeba</property>  
 --28-30行--去掉注释
 <property name="password">abc123</property>
 ​
 --45行--修改，设置主服务器的名称master和地址
 <dbServer name="master"  parent="abstractServer">
 --48行--修改，设置主服务器的地址
 <property name="ipAddress">192.168.190.10</property>
 ​
 --52行--修改，设置从服务器1的名称slave1
 <dbServer name="slave1"  parent="abstractServer">
 --55行--修改，设置从服务器1的地址
 <property name="ipAddress">192.168.190.20</property>
 --58行--复制上面6行粘贴，设置从服务器2的名称slave2和地址
 <dbServer name="slave2"  parent="abstractServer">
 <property name="ipAddress">192.168.190.30</property>
 ​
 --65行--修改
 <dbServer name="slaves" virtual="true">
 --71行--修改
 <property name="poolNames">slave1,slave2</property>
 ​
 ​
/usr/local/amoeba/bin/amoeba start &  #后台启动Amoeba软件，按ctrl+c 返回
netstat -anpt | grep java            #查看8066端口是否开启，默认端口为TCP 8066

4. 客户端测试 

客户端准备： 

yum install -y mariadb-server mariadb   #安装mariadb数据库
 systemctl start mariadb.service         #启动mariadb
 
mysql -u amoeba -p -h 192.168.190.50  -P 8066
 

 1）测试1：验证salve轮询只读 

向两台salve服务器插入验证的数据：

 192.168.190.20：

insert into info values(4,'随便');

192.168.190.30

insert into info values(4,'随便2号');

客户端进行结果测试：

 2）经过客户端进行写作用，验证影响的数据库

客户端插入数 据进行测试

insert into info values(4,'写测试');

 测试结果