基于CentOS7,MySQL5.7的读写分离架构搭建实战2
实战1遗留问题:
mysql主从复制存在的问题和解决方法(异步复制方式)
mysql主从复制存在的问题:
- 主库宕机后,数据可能丢失
- 从库只有一个SQL Thread,主库写压力大,复制很可能延时
解决方法:
- 半同步复制(解决数据丢失的问题)
- 并行复制(解决从库复制延迟的问题)
在此节将进行介绍:半同步复制和并行复制,来解决上述问题
一、半同步复制
1.1 概述
为了提升数据安全,MySQL让Master在某一个时间点等待Slave节点的 ACK(Acknowledge
character)消息,接收到ACK消息后才进行事务提交,这也是半同步复制的基础,MySQL从5.5版本开
始引入了半同步复制机制来降低数据丢失的概率。
介绍半同步复制之前先快速过一下 MySQL 事务写入碰到主从复制时的完整过程,主库事务写入分为 4
个步骤:
-
InnoDB Redo File Write (Prepare Write)
-
Binlog File Flush & Sync to Binlog File
-
InnoDB Redo File Commit(Commit Write)
Send Binlog to Slave当Master不需要关注Slave是否接受到Binlog Event时,即为传统的主从复制。 当Master需要在第三步等待Slave返回ACK时,即为 after-commit,半同步复制(MySQL 5.5引入)。 当Master需要在第二步等待 Slave 返回 ACK 时,即为 after-sync,增强半同步(MySQL 5.7引入)。
下图是 MySQL 官方对于半同步复制的时序图,主库等待从库写入 relay log 并返回 ACK 后才进行Engine Commit。
1.2 搭建半同步复制(MySQL Master主节点配置)
需要在主库和从库中进行相关软件的安装和配置,半同步需要一个模块的支撑:semi,在5.7中需要额外的安装
查看是否支持动态安装:
select @@have_dynamic_loading
查看mysql中自带插件:
查看是否已经安装了semi,show plugins;
安装semi:
install plugin rpl_semi_sync_master soname 'semisync_master.so'
查看半同步相关别的参数:
show variables like '%semi%';
修改配置:配置文件或者使用set命令
开启:set global rpl_semi_sync_master_enabled = 1;
设置延迟时间:set global rpl_semi_sync_master_timeout=1000; 单位:毫秒
1.3 搭建半同步复制(MySQL Slave从节点配置)
安装semi:
install plugin rpl_semi_sync_slave soname 'semisync_slave.so'
查看半同步相关别的参数:
show variables like '%semi%';
修改配置:配置文件或者使用set命令
开启:set global rpl_semi_sync_slave_enabled = 1;
重启从库:
验证效果:
此时主库和从库的semi都处于开启状态,则使用的就是半同步复制
检查当前操作是否使用的是半同步复制:
* 查看主库和从库的semi都处于开启状态
* 查看主库的日志
从日志文件中,能够获取
二、并行复制
2.1 并行复制概述
MySQL的主从复制延迟一直是受开发者最为关注的问题之一,MySQL从5.6版本开始追加了并行复制功能,目的就是为了改善复制延迟问题,并行复制称为enhanced multi-threaded slave(简称MTS)。
在从库中有两个线程IO Thread和SQL Thread,都是单线程模式工作,因此有了延迟问题,我们可以采用多线程机制来加强,减少从库复制延迟。(IO Thread多线程意义不大,主要指的是SQL Thread多线程)
在MySQL的5.6、5.7、8.0版本上,都是基于上述SQL Thread多线程思想,不断优化,减少复制延迟。
2.2 搭建并行复制(MySQL Master主节点配置)
查看组提交相关参数:
show variables like '%binlog_group%';
修改相关参数,开启并行复制:配置文件的方式或者set命令
set global binlog_group_commit_sync_delay=1000; 延迟
set global binlog_group_commit_sync_no_delay_count=100; 事务数
2.3 搭建并行复制(MySQL Slave从节点配置:核心操作,relaylog操作)
查看组提交相关参数:
show variables like '%slave%';
核心参数1:slave_parallel_type
为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,
其可以配置的值有:
DATABASE(默认值,基于库的并行复制方式)、LOGICAL_CLOCK(基于组提交的并行复制方式)。
核心参数2:
slave_parallel_workers ,支持最大线程数,设置为4~8个即可
参数设置:配置文件的方式或者set命令
stop slave;
set global slave_parallel_type='LOGICAL_CLOCK';
set global slave_parallel_workers=8;
查看relay_log相关参数:
show variables like '%relay_log%';
核心参数:relay_log_recovery
参数设置:配置文件的方式或者set命令
set global relay_log=1;
注意:使用set命令设置的方式报错,因为变量是只读变量;此时可以使用配置文件的方式,使用设置永久失效。
修改从库的配置文件:vi /etc/my.cnf
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=8
master_info_repository=TABLE # 设置成TABLE ,性能可以有50%~80%的提升
relay_log_info_repository=TABLE
relay_log_recovery=1
修改配置的方式,需要重启服务:
systemctl restart mysqld
修改配置文件的方式设置后,重启服务,配置仍然生效
验证效果:此时主库和从库的semi都处于开启状态,则使用的就是半同步复制
检查当前操作是否使用的是半同步复制:
2.4 MySQL 5.6并行复制原理
MySQL 5.6版本也支持所谓的并行复制,但是其并行只是基于库的。如果用户的MySQL数据库中是多个
库,对于从库复制的速度的确可以有比较大的帮助。
优点:基于库的并行复制,实现相对简单,使用也相对简单些。
缺点:基于库的并行复制遇到单库多表使用场景就发挥不出优势了,另外对事务并行处理的执行顺序也是个大问题。
2.5 MySQL 5.7并行复制原理
MySQL 5.7是基于组提交的并行复制,MySQL 5.7才可称为真正的并行复制,这其中最为主要的原因就是slave服务器的回放与master服务器是一致的,即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制。
实现原理:
MySQL 5.7是通过对事务进行**分组**,当事务提交时,它们将在单个操作中写入到二进制日志中。
如果多个事务能同时提交成功,那么它们意味着没有冲突,因此可以**在Slave上并行执行**,所以通过在主库上的二进制日志中添加组提交信息。
MySQL 5.7的并行复制基于一个前提,即所有已经**处于prepare阶段的事务**,都是可以**并行提交**的。
这些当然也可以在从库中并行提交,因为处理这个阶段的事务都是没有冲突的。
在一个组里提交的事务,一定不会修改同一行。
这是一种新的并行复制思路,完全摆脱了原来一直致力于为了防止冲突而做的分发算法,等待策略等复杂的而又效率底下的工作。
InnoDB事务提交采用的是两阶段提交模式。一个阶段是prepare,另一个是commit。
为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,其可以配置的值有:DATABASE(默认值,基于库的并行复制方式)、LOGICAL_CLOCK(基于组提交的并行复制方式)。
同组确认:生成的Binlog内容如何告诉Slave哪些事务是可以并行复制的在MySQL 5.7版本中,其设计方式是将组提交的信息存放在GTID中。为了避免用户没有开启GTID功能(gtid_mode=OFF),MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型
ANONYMOUS_GTID_LOG_EVENT。通过mysqlbinlog工具分析binlog日志,就可以发现组提交的内部信息。
MySQL 5.7二进制日志较之原来的二进制日志内容多了last_committed和sequence_number,last_committed表示事务提交的时候,上次事务提交的编号,如果事务具有相同的last_committed,表示这些事务都在一组内,可以进行并行的回放。
2.6 MySQL8.0 并行复制
MySQL8.0 是基于write-set的并行复制。MySQL会有一个集合变量来存储事务修改的记录信息(主键哈希值),所有已经提交的事务所修改的主键值经过hash后都会与那个变量的集合进行对比,来判断改行是否与其冲突,并以此来确定依赖关系,没有冲突即可并行。这样的粒度,就到了 row级别了,此时并行的粒度更加精细,并行的速度会更快。
2.7 并行复制配置与调优
* binlog_transaction_dependency_history_size 用于控制集合变量的大小。
* binlog_transaction_depandency_tracking 用于控制binlog文件中事务之间的依赖关系,即last_committed值。
* COMMIT_ORDERE: 基于组提交机制
* WRITESET: 基于写集合机制
* WRITESET_SESSION: 基于写集合,比writeset多了一个约束,同一个session中的事务last_committed按先后顺序递增
* transaction_write_set_extraction 用于控制事务的检测算法,参数值为:OFF、 XXHASH64、MURMUR32
* master_info_repository
开启MTS功能后,务必将参数master_info_repostitory设置为**TABLE**,这样**性能可以有50%~80%的提升**。
这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升,资源的竞争也会变大。
* slave_parallel_workers
若将slave_parallel_workers设置为0,则MySQL 5.7退化为原单线程复制,但将slave_parallel_workers设置为1,则SQL线程功能转化为coordinator线程,但是只有1个worker线程进行回放,也是单线程复制。
然而,这两种性能却又有一些的区别,因为多了一次coordinator线程的转发,因此slave_parallel_workers=1的性能反而比0还要差。
* slave_preserve_commit_order
MySQL 5.7后的MTS可以实现更小粒度的并行复制,但需要将slave_parallel_type设置为**LOGICAL_CLOCK**。
但仅仅设置为LOGICAL_CLOCK也会存在问题,因为此时在slave上应用事务的顺序是无序的,和relay log中记录的事务顺序不一样。
这样数据一致性是无法保证的,为了保证事务是按照relay log中记录的顺序来回放,就需要开启参数slave_preserve_commit_order。
要开启enhanced multi-threaded slave其实很简单,只需根据如下设置:
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
slave_pending_jobs_size_max = 2147483648
slave_preserve_commit_order=1
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
2.8 并行复制监控
在使用了MTS后,复制的监控依旧可以通过SHOW SLAVE STATUS\G,但是MySQL 5.7在
performance_schema库中提供了很多元数据表,可以更详细的监控并行复制过程。
通过replication_applier_status_by_worker可以看到worker进程的工作情况:
注意:如果MySQL 5.7要使用MTS功能,建议使用新版本,最少升级到5.7.19版本,修复了很多Bug。