配置多台主从数据库服务器以实现读写分离
基于语句的复制(STATEMENT,MySQL默认类型)
在服务器上执行sql语句,在从服务器上执行同样的语句,mysql默认采用基于语句的复制,执行效率高。
基于行的复制(ROW)
把改变的内容复制过去,而不是把命令在从服务器上执行一遍。
混合类型的复制(MIXED)
默认采用基于语句的复制,一旦发现基于语句无法精确复制时,就会采用基于行的复制。
注:
中继日志通常会位于 OS 缓存中,所以中继日志的开销很小。
复制过程有一个很重要的限制,即复制在 Slave上是串行化的,也就是说 Master上的并行更新操作不能在 Slave上并行操作。
#主服务器
192.168.67.100
systemctl disable --now firewalld
setenforce 0
#关闭防火墙和selinux策略
#从服务器1
192.168.67.101
systemctl disable --now firewalld
setenforce 0
#关闭防火墙和selinux策略
#从服务器2
192.168.67.102
systemctl disable --now firewalld
setenforce 0
#关闭防火墙和selinux策略
#所有服务器默认已经编译安装mysql服务
ntpdate ntp.aliyun.com
#与阿里云进行时间同步
vim /etc/my.cnf
#编辑mysql配置文件
#在[mysqld]项添加
server-id=1
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_logs_at_trx_commit=1 #redo log(事务日志)的刷盘策略,每次事务提交时MySQL都会把事务日志缓存区的数据写入日志文件中,并且刷新到磁盘中,该模式为系统默认
sync_binlog=1 #在进行每1次事务提交(写入二进制日志)以后,Mysql将执行一次fsync的磁盘同步指令,将缓冲区数据刷新到磁盘
#添加完后
systemctl restart mysqld
#重启服务
#前往/usr/local/mysql/data/目录下查看二进制文件是否创建成功
cd /usr/local/mysql/data
ls
#进入数据库服务器
grant replication slave on *.* to 'aaa-slave'@'192.168.67.%' identified by '12323';
#授权做主从复制,指定所有库和所有表,指定网段192.168.67使用aaa-slave用户并设定密码
flush privileges;
#刷新权限
show master status;
#查看主服务器二进制文件与位置点偏移量
yum install ntp ntpdate -y
service ntpd start
#开启服务
/usr/sbin/ntpdate 192.168.67.100 #与主服务器进行时间同步
#设置计划任务
crontab -e
*/30 * * * * /usr/sbin/ntpdate 192.168.67.100
#每半小时与主服务器进行一次时间同步
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
#重启服务
#登录mysql
CHANGE master to master_host='192.168.67.100',master_user='aaa-slave',master_password='123123',master_log_file='mysql-bin.000002',master_log_pos=777;
#指定master主机地址、端口号、用户名、密码、日志文件、位置点偏移量
start slave;
#启动同步,如有报错执行 reset slave;
show slave status\G #查看 Slave 状态
//确保 IO 和 SQL 线程都是 Yes,代表同步正常。
yum install ntp ntpdate -y
service ntpd start
#开启服务
/usr/sbin/ntpdate 192.168.67.100 #与主服务器进行时间同步
#设置计划任务
crontab -e
*/30 * * * * /usr/sbin/ntpdate 192.168.67.100
#每半小时与主服务器进行一次时间同步
vi /etc/my.cnf
#编辑配置文件
#添加
server-id = 3
relay-log=relay-log-bin
relay-log-index=relay-log-bin.index
systemctl restart mysqld
#重启服务
#登录mysql
CHANGE master to master_host='192.168.67.100',master_user='aaa-slave',master_password='123123',master_log_file='mysql-bin.000002',master_log_pos=777;
#指定master主机地址、端口号、用户名、密码、日志文件、位置点偏移量
start slave;
#启动同步,如有报错执行 reset slave;
show slave status\G #查看 Slave 状态
//确保 IO 和 SQL 线程都是 Yes,代表同步正常。
#一般 Slave_IO_Running: No 的可能性:
1、网络不通
2、my.cnf配置有问题
3、密码、file文件名、pos偏移量不对
4、防火墙没有关闭
MySQL主从复制延时问题的故障现象通常表现为主库上的数据变更在从库上出现延迟。
这可能导致从库上的数据与主库不同步,并可能对应用程序或业务产生一些问题。
一些常见的故障现象包括:
从库数据延迟:主库上的数据变更在从库上出现延迟,通常可以通过查看从库的 Seconds_Behind_Master 参数来确定延迟的时间。
延迟逐渐增加:从库上的延迟可能会逐渐增加,从几秒钟到几分钟甚至更长。
复制停止:复制进程可能会在某些情况下停止,导致复制完全中断。
数据丢失:如果出现严重的复制延迟或复制停止,可能会导致从库上的数据丢失。在复制延迟问题得到解决之前,从库上的数据可能无法与主库保持同步。
#前往主服务器
create database scj;
#创建新库
create table scj.scj1 (id int, name varchar(10), age int, sex char(1));
#创建新表
#添加数据
insert into scj.scj1 values (1, '张三', 20, '男');
insert into scj.scj1 values (2, '李四', 22, '男');
insert into scj.scj1 values (3, '赵四', 21, '男');
insert into scj.scj1 values (4, '尼古拉斯', 24, '男');
#前往从服务器查看
#从服务器1
#从服务器2
MySQL默认的复制即是异步的,主库在执行完客户端提交的事务后会立即将结果返给客户端,并不关心从库是否已经接收并处理
这样就会有一个问题,主如果crash掉了,此时主上已经提交的事务可能并没有传到从上,如果此时,强行将从提升为主,可能导致新主上的数据不完整。
指当主库执行完一个事务,所有的从库都执行了该事务才返回给客户端。
因为需要等待所有从库执行完该事务才能返回,所以全同步复制的性能必然会收到严重的影响。
介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到relay log中才返回给客户端。
相对于异步复制,半同步复制提高了数据的安全性,同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。
所以,半同步复制最好在低延时的网络中使用。
主:192.168.67.100
从:192.168.67.101
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
#重启服务
vim /etc/my.cnf
plugin-load=rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled=ON
systemctl restart mysqld
#重启服务
#前往主服务器
#进入mysql
show status like 'Rpl_semi_sync_master_status';
#查看是否开启半同步复制
show variables like 'rpl_semi_sync_master_timeout';
#查看超时时间
#前往从服务器开启mysql
show status like 'Rpl_semi_sync_slave_status';
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
#重启io进程
#在主库查询半同步状态
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 的反馈。
是让主数据库处理事务性增、改、删操作(INSERT、UPDATE、DELETE),而从数据库处理SELECT查询操作。
数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。
数据库不一定要读写分离,如果程序使用数据库较多时,而更新少,查询多的情况下会考虑使用。
利用数据库主从同步,再通过读写分离可以分担数据库压力,提高性能。
在实际的生产环境中,对数据库的读和写都在同一个数据库服务器中,是不能满足实际需求的。
无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。
因此,通过主从复制的方式来同步数据,再通过读写分离来提升数据库的并发负载能力。有点类似于rsync,但是不同的是rsync是对磁盘文件做备份,而mysql主从复制是对数据库中的数据、语句做备份。
在代码中根据 select、insert 进行路由分类,这类方法也是目前生产环境应用最广泛的。
优点是性能较好,因为在程序代码中实现,不需要增加额外的设备为硬件开支;
缺点是需要开发人员来实现,运维人员无从下手。
但是并不是所有的应用都适合在程序代码中实现读写分离,像一些大型复杂的Java应用,如果在程序代码中实现读写分离对代码改动就较大。
代理一般位于客户端和服务器之间,代理服务器接到客户端请求后通过判断后转发到后端数据库,有以下代表性程序。
#主服务器
192.168.67.100
#从服务器1
192.168.67.101
#从服务器1
192.168.67.102
#amobeba
192.168.67.103
#客户端
192.168.67.104
systemctl disable --now firewalld
setenforce 0
vim /etc/selinux/config
cd /opt
#所需安装包
amoeba-mysql-binary-2.2.0.tar.gz
jdk-6u14-linux-x64.bin
chmod +x jdk-6u14-linux-x64.bin
#给予可执行权限
./jdk-6u14-linux-x64.bin
#直接执行
#ctrl C选择yes
mv jdk1.6.0_14/ /usr/local/jdk1.6
#移动jdk主目录到/usr/local下
#添加环境变量
cd /etc/profile.d
vi java.sh
export JAVA_HOME=/usr/local/jdk1.6 #java家目录
export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib #编译路径
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH #设置java环境变量
export AMOEBA_HOME=/usr/local/amoeba #设置amobeba家目录
export PATH=$PATH:$AMOEBA_HOME/bin #设置amobeba环境变量
source /etc/profile.d/java.sh
java -version
#查看当前脚本
mkdir amoeba
#创建amobeba工作目录
tar zxvf /opt/amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/
#解压缩软件包
cd /usr/local/amoeba/bin
#前往启动文件处
./amoeba
#以当前目录启动
#在主从服务器同时操作
grant all on *.* to amoeba@'192.168.67.%' identified by '123123';
#在Master、Slave1、Slave2 的mysql上开放权限给 Amoeba 访问
#前往amoeba
cd /usr/local/amoeba/conf
#前往配置文件处
cp amoeba.xml amoeba.xml.bak
#备份xml文件
vim amoeba.xml
#修改amoeba配置文件
cp dbServers.xml dbServers.xml.bak
#拷贝数据库配置文件
vi dbServers.xml
#修改数据库配置文件
/usr/local/amoeba/bin/amoeba start&
#启动Amoeba软件,在后台执行
ss -natp |grep java
#查看是否启动成功
#该步骤沿用主从复制配置
#前往客户端
yum install -y mariadb-server mariadb
#安装一个简单配置的mysql数据库
systemctl start mariadb.service
#开启服务
mysql -uamoeba -padmin123 -h 192.168.67.103 -P8066
#登录原先设置的账户
show databases;
select * from scj.scj1;
#查看库和表数据内容是否同步
#在表中添加数据查看同步情况
insert into scj.scj1 values (5, 'sakula酱', 20, '女');
#前往主服务器、从服务器1、从服务器2查看
#进入数据库
select * from scj.scj1;
#查看表数据
#同步没有问题
#证明连接amoeba可以在三台服务器中进行写入操作
#需要证明连接amoeba执行写入操作是写入哪一台服务器的
#前往从服务器1-2关掉同步
stop slave;
#现在前往客户端添加数据
insert into scj.scj1 values (6, '日川冈板', 28, '男');
#验证能否实现读的负载均衡
#在从服务器1添加数据
insert into scj.scj1 values (7, '强者', 23, '男');
#在从服务器2添加数据
insert into scj.scj1 values (8, '弱者', 20, '男');
#前往客户端查看
#进入数据库
select * from scj.scj1