一、相关概念介绍
1、读写分离概念介绍
读写分离,基本的原理是让主数据库处理事务性增、改、删操作(INSERT、UPDATE、DELETE),而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。
2、为什么要读写分离
因为数据库的“写”(写10000条数据可能要3分钟)操作是比较耗时的。
但是数据库的“读”(读10000条数据可能只要5秒钟)。
所以读写分离,解决的是,数据库的写入,影响了查询的效率。
3、 什么时候要读写分离
数据库不一定要读写分离,如果程序使用数据库较多时,而更新少,查询多的情况下会考虑使用。利用数据库主从同步,再通过读写分离可以分担数据库压力,提高性能。
4、 主从复制与读写分离
在实际的生产环境中,对数据库的读和写都在同一个数据库服务器中,是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此,通过主从复制的方式来同步数据,再通过读写分离来提升数据库的并发负载能力。有点类似于rsync,但是不同的是rsync是对磁盘文件做备份,而mysql主从复制是对数据库中的数据、语句做备份。
5、mysql支持的复制类型
- STATEMENT:基于语句的复制。在服务器上执行sql语句,在从服务器上执行同样的语句,执行效率高。
- ROW:基于行的复制。把改变的内容复制过去,而不是把命令在从服务器上执行一遍。MySQL 5.7.7 之后,binlog 的存储格式默认 Row
- MIXED:混合类型的复制。默认采用基于语句的复制,一旦发现基于语句无法精确复制时,就会采用基于行的复制。
6、主从复制的工作过程
关键词:两个日志,三个线程
1)主库(master)如果发生数据更新,会将操作记录写入二进制日志(bin log)里
2)从库(slave)探测到主库的二进制日志发生了更新,就会开启IO线程向主库请求二进制日志事件
3)主库会为每个从库IO线程的请求开启DUMP线程,并发送二进制日志事件给从库
4)从库接收到二进制日志事件后会保存到自己的中继日志(relay log)中
附:在半同步模式下从库会返回确认信息给主库,主库会用ack收集线程接收从库反馈的确认信息(5.7版本开始支持)
5)从库还会开启SQL线程读取中继日志里的事件,并在本地重放(将二进制日志事件解析成sql语句逐一执行),从而实现主库和从库的数据一致
7、主从复制的配置步骤
- 主从服务器先做时间同步
- 修改主从数据库的配置文件,主库开启二进制日志,从库开启中继日志
- 在主库创建主从复制的用户,并授予主从复制的权限
- 在从库使用 change master to 对接主库,并 start slave 开启同步
- 在从库使用 show slave status\G 查看 IO线程和 SQL线程的状态是否都为 YES
8、主从复制的同步模式
- 异步复制 主库在执行完客户端提交的事务后就会立即响应给客户端
- 半同步复制 主库在执行完客户端提交的事务后,只要等待一个从库返回响应给主库,才会响应给客户端
- 全同步复制 主库在执行完客户端提交的事务后,要等待所有从库返回都响应给主库,才会响应给客户端
实现主从复制的半同步模式
主数据库配置
vim /etc/my.cnf
......
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
从数据库配置
vim /etc/my.cnf
......
plugin-load=rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled=ON
systemctl restart mysqld
查看半同步是否在运行
#主数据库执行
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 内,收到了从库的响应, 则主从又重新恢复为半同步复制。
在什么情况下半同步复制会降为异步复制?
- 当主库在半同步复制超时时间内(rpl_semi_sync_master_timeout)没有收到从库的响应,就会自动降为半同步复制。
- 当主库发送完一个事务事件后,主库在超时时间内收到了从库的响应,就会又恢复为半同步复制。
二、搭建MySQL主从复制
1、初始化操作
###关闭和禁止防火墙开机自启功能
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
vim /etc/selinux/config
SELINUX=disabled
2、完成时间同步
rpm -q chrony
chrony-3.4-1.el7.x86_64
vim /etc/chrony.conf
systemctl restart chronyd.service
3、主服务器MySQL的配置
vim /etc/my.cnf
server-id=11
log-bin=mysql-bin #添加,主服务器开启二进制日志
binlog_format=mixed
#选配项
expire_logs_days=7 #设置二进制日志文件过期时间,默认值为0,表示logs不过期
max_binlog_size=500M #设置二进制日志限制大小,如果超出给定值,日志就会发生滚动,默认值是1GB
skip_slave_start=1 #阻止从库崩溃后自动启动复制,崩溃后再自动复制可能会导致数据不一致的
#"双1设置",数据写入最安全
innodb_flush_log_at_trx_commit=1 #redo log(事务日志)的刷盘策略,每次事务提交时MySQL都会把事务日志缓存区的数据写入日志文件中,并且刷新到磁盘中,该模式为系统默认
sync_binlog=1 #在进行每1次事务提交(写入二进制日志)以后,Mysql将执行一次fsync的磁盘同步指令,将缓冲区数据刷新到磁盘
---------------------------------------------------------------
#"双1设置"适合数据安全性要求非常高,而且磁盘IO写能力足够支持的业务,比如订单、交易、充值、支付消费系统。"双1模式"下,当磁盘IO无法满足业务需求时,比如11.11活动的压力。推荐一下性能较快的设置,并使用带蓄电池后备电源,防止系统断电异常。
innodb_flush_log_at_trx_commit=2 #每次事务提交时MySQL都会把日志缓存区的数据写入日志文件中,但是并不会同时刷新到磁盘上。该模式下,MySQL会每秒执行一次刷新磁盘操作
sync_binlog=500 #在进行500次事务提交以后,Mysql将执行一次fsync的磁盘同步指令,将缓冲区数据刷新到磁盘
---------------------------------------------------------------
创建用户并给从服务器授权
mysql -u root -pabc123
create user 'myslave'@'192.168.10.%' identified by 'myslave123';
GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.10.%' IDENTIFIED BY 'myslave'; #给从服务器授权
FLUSH PRIVILEGES;
show master status;
4、MySQL从服务器配置
vim /etc/my.cnf
server-id = 2 #修改,注意id与Master的不同,两个Slave的id也要不同
relay-log=relay-log-bin #开启中继日志,从主服务器上同步日志文件记录到本地
relay-log-index=relay-log-bin.index #定义中继日志文件的位置和名称,一般和relay-log在同一目录
#选配项
innodb_buffer_pool_size=2048M #用于缓存数据和索引的内存大小,让更多数据读写在内存中完成,减少磁盘操作,可设置为服务器总可用内存的 70-80%
sync_binlog=0 #MySQL不做任何强制性的磁盘刷新指令,而是依赖操作系统来刷新数据到磁盘
innodb_flush_log_at_trx_commit=2 #每次事务log buffer会写入log file,但一秒一次刷新到磁盘
log-slave-updates=0 #slave 从 master 复制的数据会写入二进制日志文件里,从库做为其他从库的主库时设置为 1
relay_log_recovery=1 #当 slave 从库宕机后,假如 relay-log 损坏了,导致一部分中继日志没有处理,则自动放弃所有未执行的 relay-log, 并且重新从 master 上获取日志,这样就保证了 relay-log 的完整性。默认情况下该功能是关闭的,将 relay_log_recovery 的值设置为 1 时, 可在 slave 从库上开启该功能,建议开启。
systemctl restart mysqld
配置同步
#配置同步,注意 master_log_file 和 master_log_pos 的值要与 Master 查询的一致
change master to master_host='192.168.10.20', master_port=3306, master_user='myslave', master_password='myslave', master_log_file='mysql-bin.000002', master_log_pos=603;
#基于整个数据库的同步
CHANGE master to master_host='192.168.10.20',master_port=3306,master_user='myslave',master_password='myslave';
start slave; #启动同步,如有报错执行 reset slave;
show slave status\G #查看 Slave 状态
//确保 IO 和 SQL 线程都是 Yes,代表同步正常。
Slave_IO_Running: Yes #负责与主机的io通信
Slave_SQL_Running: Yes #负责自己的slave mysql进程
5、主从复制测试
主服务器创建增加数据库
从服务器查看
补充:主从复制延迟问题
根本原因:主库可以并发多线程执行写入操作,而从库的SQL线程默认是单线程串行化复制,从库的复制效率可能会跟不上主库的写入速度
如何判断发生了主从复制延迟?
通过在从库执行show slave status\G命令,查看输出的Seconds_Behind_Master参数的值来判断,是否有发生主从延时。如果为正值表示主从已经出现延时,数字越大表示从库落后主库越多。
导致主从复制延迟有哪些因素?
1)主库写入操作并发量太大
2)网络延迟
3)从库硬件比主库差
4)使用了同步复制
5)慢SQL语句过多
延迟的解决:
网络方面:将从库分布在相同局域网内或网络延迟较小的环境中。
硬件方面:从库配置更好的硬件(CPU 内存 固态硬盘),提升随机写的性能。
配置方面:sync_binlog=0 innodb_flush_log_at_trx_commit=2 #由于从库不需要这么高的数据安全性,所以不使用 双1设置
logs-slave-updates=0 #从库同步的事件不记录到从库自身的二进制日志中
innodb_buffer_pool_size=物理内存的80% #加大innodb引擎缓存池大小,让更多数据读写在内存中完成,减少磁盘的IO压力
架构方面:主从复制的同步模式采用 异步复制 或 半同步复制 或 并行复制
采用读写分离架构
操作方面:将大事务拆分为多个较小的事务
优化 DDL 操作,合并多个 DDL 操作为一个批处理操作
主从复制不一致问题的解决:
1)先进入主库,进行锁表,防止数据写入
flush tables with read lock;
set gloabl read_only=1;2)进行数据全量备份
mysqldump -u root -p密码 库名 表名 > XXX.sql3)使用scp命令把备份文件传到从库机器,进行数据恢复
scp XXX.sql 从库IP:目录/stop slave;
mysql -u root -p密码 < XXX.sql
4)使用 change master to 重新做主从复制
change master to master_host='主库IP', master_port=3306, master_user='用户名', master_password='密码', master_log_file='二进制文件', master_log_pos=二进制事件位置;附:二进制文件和二进制事件位置需要在主库查询 show master status;
start slave;
5)主库解锁
unlock tables;
set gloabl read_only=0;
三、实现MySQL读写分离
1、原理
- 只在主服务器上写,只在从服务器上读
- 主数据库处理事务性操作,从数据库处理SELECT查询
- 数据库复制用于将事务性操作的变更同步到集群中的从数据库
读写分离方案
1、基于程序代码内部实现
2、基于中间代理层实现
- MySQL-Proxy
- Amoeba
2、具体实现过程
结合上一个主从复制的实验,引用Amoeba服务器,使客户端发来的读写请求,进行读写分离,写的操作交予主mysql主服务器处理,读的操作由从库服务器进行处理。
1、Amoeba服务器配置
##安装 Java 环境##
因为 Amoeba 基于是 jdk1.5 开发的,所以官方推荐使用 jdk1.5 或 1.6 版本,高版本不建议使用。
cd /opt/
cp jdk-6u14-linux-x64.bin /usr/local/
cd /usr/local/
chmod +x jdk-6u14-linux-x64
./jdk-6u14-linux-x64.bin
//按yes,按enter
mv jdk1.6.0_14/ /usr/local/jdk1.6
##安装 Amoeba软件##
mkdir /usr/local/amoeba
tar zxvf amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/
chmod -R 755 /usr/local/amoeba/
/usr/local/amoeba/bin/amoeba
//如显示amoeba start|stop说明安装成功
2、配置 Amoeba读写分离,两个 Slave 读负载均衡
#先在Master、Slave1、Slave2 的mysql上开放权限给 Amoeba 访问
create user 'amoeba'@'192.168.10.%';
grant all on *.* to 'amoeba'@'192.168.10.%';
修改amoeba.xml文件配置
vim amoeba.xml #修改amoeba配置文件
--30行--
<property name="user">amoeba</property>
--32行--
<property name="password">123456</property>
--115行--
<property name="defaultPool">master</property>
--117-去掉注释-
<property name="writePool">master</property>
<property name="readPool">slaves</property>
修改dbServers配置
cp dbServers.xml dbServers.xml.bak
vim dbServers.xml #修改数据库配置文件
--23行--注释掉 作用:默认进入test库 以防mysql中没有test库时,会报错
<!-- <property name="schema">test</property> -->
--26--修改
<property name="user">test</property>
--28-30--去掉注释
<property name="password">123.com</property>
--45--修改,设置主服务器的名Master
<dbServer name="master" parent="abstractServer">
--48--修改,设置主服务器的地址
<property name="ipAddress">192.168.80.10</property>
--52--修改,设置从服务器的名slave1
<dbServer name="slave1" parent="abstractServer">
--55--修改,设置从服务器1的地址
<property name="ipAddress">192.168.80.11</property>
--58--复制上面6行粘贴,设置从服务器2的名slave2和地址
<dbServer name="slave2" parent="abstractServer">
<property name="ipAddress">192.168.80.12</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
3、启动Amoeba
/usr/local/amoeba/bin/amoeba start& #启动Amoeba软件,按ctrl+c 返回
netstat -anpt | grep java #查看8066端口是否开启,默认端口为TCP 8066
4、验证
----测试读写分离 ----
yum install -y mariadb-server mariadb
systemctl start mariadb.service
在客户端服务器上测试:
mysql -u amoeba -p123456 -h 192.168.80.20 -P8066
//通过amoeba服务器代理访问mysql ,在通过客户端连接mysql后写入的数据只有主服务会记录,然后同步给从--从服务器
在主服务器上:
use db_test;
create table test (id int(10),name varchar(10),address varchar(20));
在两台从服务器上:
stop slave; #关闭同步
use db_test;
//在slave1上:
insert into test values('1','zhangsan','this_is_slave1');
//在slave2上:
insert into test values('2','lisi','this_is_slave2');
//在主服务器上:
insert into test values('3','wangwu','this_is_master');
//在客户端服务器上:
use db_test;
select * from test; //客户端会分别向slave1和slave2读取数据,显示的只有在两个从服务器上添加的数据,没有在主服务器上添加的数据
insert into test values('4','qianqi','this_is_client'); //只有主服务器上有此数据
//在两个从服务器上执行 start slave; 即可实现同步在主服务器上添加的数据
start slave;