MySQL主从复制于读写分离

发布时间 2024-01-02 20:00:19作者: citywalk

主从复制于读写分离

 

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

2、为什么要读写分离呢?
因为数据库的“写”(写10000条数据可能要3分钟)操作是比较耗时的。
但是数据库的“读”(读10000条数据可能只要5秒钟)。
所以读写分离,解决的是,数据库的写入,影响了查询的效率。

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

4、主从复制与读写分离
在实际的生产环境中,对数据库的读和写都在同一个数据库服务器中,是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此,通过主从复制的方式来同步数据,再通过读写分离来提升数据库的并发负载能力。有点类似于rsync,但是不同的是rsync是对磁盘文件做备份,而mysql主从复制是对数据库中的数据、语句做备份。

5、mysql支持的复制类型
(1)STATEMENT:基于语句的复制。在服务器上执行sql语句,在从服务器上执行同样的语句,mysql默认采用基于语句的复制,执行效率高。
(2)ROW:基于行的复制。把改变的内容复制过去,而不是把命令在从服务器上执行一遍。
(3)MIXED:混合类型的复制。默认采用基于语句的复制,一旦发现基于语句无法精确复制时,就会采用基于行的复制。

6、主从复制的工作过程
(1)Master节点将数据的改变记录成二进制日志(bin log),当Master上的数据发生改变时,则将其改变写入二进制日志中。
(2)Slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变,如果发生改变,则开始一个I/O线程请求 Master的二进制事件。
(3)同时Master节点为每个I/O线程启动一个dump线程,用于向其发送二进制事件,并保存至Slave节点本地的中继日志(Relay log)中,Slave节点将启动SQL线程从中继日志中读取二进制日志,在本地重放,即解析成 sql 语句逐一执行,使得其数据和 Master节点的保持一致,最后I/O线程和SQL线程将进入睡眠状态,等待下一次被唤醒。

注:
●中继日志通常会位于 OS 缓存中,所以中继日志的开销很小。
●复制过程有一个很重要的限制,即复制在 Slave上是串行化的,也就是说 Master上的并行更新操作不能在 Slave上并行操作。



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

8、目前较为常见的 MySQL 读写分离分为以下两种:
1)基于程序代码内部实现
在代码中根据 select、insert 进行路由分类,这类方法也是目前生产环境应用最广泛的。
优点是性能较好,因为在程序代码中实现,不需要增加额外的设备为硬件开支;缺点是需要开发人员来实现,运维人员无从下手。
但是并不是所有的应用都适合在程序代码中实现读写分离,像一些大型复杂的Java应用,如果在程序代码中实现读写分离对代码改动就较大。

2)基于中间代理层实现
代理一般位于客户端和服务器之间,代理服务器接到客户端请求后通过判断后转发到后端数据库,有以下代表性程序。
(1)MySQL-Proxy。MySQL-Proxy 为 MySQL 开源项目,通过其自带的 lua 脚本进行SQL 判断。
(2)Atlas。是由奇虎360的Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上,对其进行了优化,增加了一些新的功能特性。360内部使用Atlas运行的mysql业务,每天承载的读写请求数达几十亿条。支持事物以及存储过程。
(3)Amoeba。由陈思儒开发,作者曾就职于阿里巴巴。该程序由Java语言进行开发,阿里巴巴将其用于生产环境。但是它不支持事务和存储过程。
(4)Mycat。是一款流行的基于Java语言编写的数据库中间件,是一个实现了MySql协议的服务器,其核心功能是分库分表。配合数据库的主从模式还可以实现读写分离。

由于使用MySQL Proxy 需要写大量的Lua脚本,这些Lua并不是现成的,而是需要自己去写。这对于并不熟悉MySQL Proxy 内置变量和MySQL Protocol 的人来说是非常困难的。
Amoeba是一个非常容易使用、可移植性非常强的软件。因此它在生产环境中被广泛应用于数据库的代理层。

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

#### 异步复制 (Asynchronous replication)

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

#### 全同步复制 (Fully synchronous replication)

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

#### 半同步复制 (Semisynchronous replication)

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

 

 

主从复制工作原理

主会开启二进制日志,从开启中继日志。主更新数据时会写入到二进制日中中,从会开启i/o线程请求主发送二进制事件,
主会给每个i/o线程开启dump线程向从发送二进制事件,从收到二进制事件保存到中继日志中,
从开启sql线程读取中继日志中的二进制事件并解析成sql语句在本地进行重放/逐一放行
#在5.7版本开启了半同步复制的情况下主会用ack collector线程接受从服务器的反馈确认信息 #中继日志通常会位于 OS 缓存中,所以中继日志的开销很小。 #复制过程有一个很重要的限制,即复制在 Slave上是串行化的,也就是说 Master上的并行更新操作不能在 Slave上并行操作。

 

主从复制实验

主服务器:192.168.19.25

两个从服务器:192.168.19.26,

192.168.19.29

主服务器

yum install ntp ntpdate -y

service ntpd start



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的磁盘同步指令,将缓冲区数据刷新到磁盘


systemctl restart mysqld

mysql -u root -pabc123
GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.19.%' IDENTIFIED BY '123';

#给从服务器授权
FLUSH PRIVILEGES; #刷新


show master status; ##File 列显示日志名,Position 列显示偏移量

 

 #下载时钟同步,三个服务器都下并且启动

 #开启ntp服务

 #修改配置文件

 

 #给19网段的从服务器授权

 #File 列显示日志名,Position 列显示偏移量

 

从服务器 一

 #下载时间同步

 #开启ntp服务

 #设置计划任务,每半小时同步一次

 

server-id =3                         #修改,注意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 从库上开启该功能,建议开启。

 #重启mysql服务

 #进入mysql

 #配置同步,注意 master_log_file 和 master_log_pos 的值要与Master查询的一致

 #开启同步

 #确保 IO 和 SQL 线程都是 Yes,代表同步正常。

Slave_IO_Running: Yes #负责与主机的io通信
Slave_SQL_Running: Yes #负责自己的slave mysql进程

 

 

 

 

读写分离

 

#点回车和yes

 

 

 

 

 

 

 #创建文件夹

 

grant all on *.* to test@'192.168.19.%' identified by '123.com';

#配置 Amoeba读写分离,两个 Slave 读负载均衡##
#先在Master、Slave1、Slave2 的mysql上开放权限给 Amoeba 访问

用户不用root,root权限太大

 

 #修改amoeba配置文件

 

 

 

 #备份

 #修改数据库配置文件

 #root改为amoeba

 #并将password改为123

 

 

 #复制上面6行,填写第二个从服务器的IP

 

 #将65行中修改为slaves

 #将server改为slave

 

 

   测试读写分离 #安装mariadb

 #开启服务

 #修改授权

 

 #用navicat 当作客户端连接amoeba

//通过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;