基于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_CLOCKslave-parallel-workers=8master_info_repository=TABLE     # 设置成TABLE  ，性能可以有50%~80%的提升relay_log_info_repository=TABLErelay_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_orderMySQL 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_CLOCKslave-parallel-workers=16slave_pending_jobs_size_max = 2147483648slave_preserve_commit_order=1master_info_repository=TABLErelay_log_info_repository=TABLErelay_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。

下节内容：读写分离

基于CentOS7，MySQL5.7的同步/半同步复制实现相关推荐

mysql5.623 GTID主从复制+半同步复制安装与配置
一.GTID简介什么是GTID GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号. GTID实际上是由UUID+TID组成的.其中UUID是 ...
Mysql5.6.x版本半同步主从复制的开启方法
介绍先了解一下mysql的主从复制是什么回事,我们都知道,mysql主从复制是基于binlog的复制方式,而mysql默认的主从复制方式,其实是异步复制. 主库实际上并不关心从库是否把数据拉完没有, ...
mysql 异步同步不支持,Mysql 异步/同步/半同步复制
Mysql复制异步逻辑 MySQL 默认的复制就是异步的,主库再执行完客户端提交的事务后会立即将结果返回给客户端,并不关系从库是否已经接收和处理. 技术实现 MySQL主库将Binlog事件写入到 ...
MySQL 5.7 深度解析: 半同步复制技术
复制架构衍生史在谈这个特性之前,我们先来看看MySQL的复制架构衍生史. MySQL的复制分为四种: 普通的replication,异步同步. 搭建简单,使用非常广泛,从mysql诞生之初,就产生了 ...
mysql复制多行_mysql中的复制方式总结(半同步复制，并行复制，多源复制)
一.MySQL主从复制(异步复制,默认) Mysql主从复制原理 Mysql的复制原理大致如下: 1.主库记录binlog日志在每次准备提交事务完成数据更新前,主库将数据更新的事件记录到二进制日志b ...
MySQL双主(master-master)+半同步(Semisync Replication)
环境: 主机名主机IP 操作系统 MySQL版本 mysqlA 172.16.4.235 CentOS 6.5 2.6.32-431.el6.x86_64 mysql-community-serve ...
mysql 半同步关闭_MySQL的半同步模式配置
1.什么是半同步? 在有一台主服务器.多台从服务器的情况下,主服务器只会等待一台从服务器同步数据. 2.为什么要使用半同步? 在使用同步模式时,数据的写速度太慢. 在使用异步模式时,可能会造成从服务器 ...
MySQL 半同步复制+MMM架构
介绍上篇文章介绍了MMM架构的实现方法,但是上篇文章的MMM方案的复制是异步复制,异步复制的主要问题在于当主从存在延时时如果主机出现了故障导致了主从切换时这时将会存在数据丢失:mysql为了解决异步 ...
linux mysql主从半同步_centos下安装mysql主从架构（半同步/多实例）
centos下安装mysql主从架构(半同步/多实例) [toc] 简介本教程会进行mysql一机多实例的安装.mysql主从同步配置.半同步配置环境 OS: CentOS Linux relea ...

基于CentOS7，MySQL5.7的同步/半同步复制实现