MySQL 主从复制与读写分离

最新推荐文章于 2024-11-09 19:00:00 发布

G咖喱炒饭

最新推荐文章于 2024-11-09 19:00:00 发布

阅读量1.3k

点赞数 3

文章标签： mysql 数据库 java

本文链接：https://blog.csdn.net/GaLiCHaoFan1/article/details/127068822

版权

本文详细介绍了MySQL的主从复制，包括复制类型、工作过程、同步模式及延迟原因与优化方法。此外，还展示了如何进行主从复制的配置与验证，以及读写分离的原理和实现方式，包括基于程序代码和中间代理层实现，重点讲解了Amoeba服务的搭建和测试验证。

摘要由CSDN通过智能技术生成

异步复制（Asynchronous replication）

增强半同步复制（lossless Semi-Sync Replication）

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

配置Amoeba读写分离，两个slave读负载均衡

一、主从复制概述

MySQL的主从复制和MySQL的读写分离两者有着紧密联系，首先要部署主从复制，只有主从复制完成可=了，才能在此基础上进行数据的读写分离

1.1 mysql支持的复制类型

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

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

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

1.2 主从复制的工作过程

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线程将进入睡眠状态，等待下一次被唤醒。

核心：两个日志，三个线程

两个日志：二进制日志（bin log） 、中继日志（Relay log）
三个线程：I/O线程、dump线程、SQL线程
- dump线程：① 监听本地二进制日志 ② 记录I/O线程对应的slave位置 ③ 同步二进制日志更新内容给I/O线程
- I/O线程：① 监听master的dump线程 ② 将slave信息发送给master：从服务器位置、日志的position（记录位置）、超时时间 ③ 接收master的dump线程传递过来的更新信息 ④ 写入relay-log中
- SQL线程：① 监听中继日志 ② 将中继日志中的更新内容执行到自己的数据库中（保证从库与主库执行相同操作）

注：

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

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

异步复制（Asynchronous replication）

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

全同步复制（Fully synchronous replication）

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

半同步复制（Semisynchronous replication）

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

增强半同步复制（lossless Semi-Sync Replication）

增强半同步是在MySQL5.7引入，其实半同步可以看成是一个过渡功能，因为默认的配置就是增强半同步，所以，大家一般说的半同步复制就是增强的半同步复制，也就是无损复制
增强半同步和半同步不同的是，等待ACK时间不同
rpl_semi_sync_master_wait_point = AFTER_SYNC（默认）
半同步的问题是因为等待ACK的点是Commit之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当binlog还未同步到Slave时，发生主从切换，那么此时从库是没有这个最新数据的，用户看到的是老数据
增强半同步将等待ACK的点放在提交Commit之前，此时数据还未被提交，外界看不到数据变更，此时如果发送主从切换，新库依然还是老数据，不存在数据不一致的问题

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

主从复制延迟原因：

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

优化方法：

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

二、主从复制案例演示

实验环境

Master 服务器：192.168.114.200

Slave1 服务器：192.168.114.59

Slave2 服务器：192.168.114.60

关闭防火墙及核心防护

systemctl stop firewalld #关闭防火墙

systemctl disable firewalld

setenforce 0 #关闭核心防护

2.1 主从服务器时间同步

yum -y install ntpdate ntp    #下载软件
ntpdate ntp.aliyun.com    #时间同步

2.2 主服务器Master配置

vim /etc/my.cnf
server-id = 1            #server-id与从服务器server-id不能重复
log-bin=master-bin       #添加，主服务器开启二进制文件
log_slave-updates=true   #添加，允许从服务器更新二进制文件

systemctl restart mysqld #重启mysql服务

修改配置文件，配置完成重启服务