关于mysql:三高Mysql-搭建三高架构之复制

内容为慕课网的《高并发高性能高可用 Mysql 实战》视频的学习笔记内容和集体整顿扩大之后的笔记，这一节讲述搭建 Mysql 三高架构中的复制，Mysql 的复制在实战中实现比较简单，然而 Mysql 针对复制的外部优化却是始终在进行，这样阐明这是值得器重和学习的内容，所以本节针对复制这一特色介绍相干的实践内容。

如果内容比拟难能够追随《Mysql 是怎么样运行》集体读书笔记专栏补补课：

地址如下：从零开始学 Mysql。

三高架构比拟好了解，这里简略过一遍：

高并发：同时解决多条事务数高
高性能：SQL 执行效率高
高可用：零碎可用率达到 99% 以上。

三高是目标不是伎俩

三高架构的关键在于三个关键字：复制，扩大，切换。

复制：数据冗余，binlog 传送，并发量晋升，可用性进步。毛病是复制会加大服务器的性能开销。

扩大：扩大容量，数据库分片分表，性能和并发量晋升。毛病是升高可用性。

切换：主从库进步高可用，主从身份切换，并发量晋升。毛病是失落切换时刻的数据。

这三点对应 CAP 的实践，CAP 中最多只能满足 CP 或者 AP，CAP 的理论知识这里略过，联合下面三点能够简略梳理。

三高实现实质：

三高的实质其实就是如何联合复制、扩大、切换三个办法实现三高，咱们须要思考上面的三个问题：

如何将数据进行冗余？
如何无效扩大容量，进步并发性能？
如何做主从备份切换，进步高可用？

针对下面三个问题在回到结尾提到的三高最终 Mysql 的三高总结来说就是上面三点：

高并发：复制和拓展，扩散多节点

高性能：复制晋升速度，拓展容量

高可用：节点之间切换。

复制是 Mysql 中实现高可用的重要性能，复制类型分为三种：异步复制和半同步复制，组复制 的模式以及新版本带来的 GTID 复制加强模式。

异步复制
半同步复制
组复制（Mysql5.7 新个性）
GTID 复制模式（Mysql5.6.5 之后新增）（缩小复制故障）

异步复制

异步复制是十分传统的 Mysql 复制形式也是实现形式最为简略的一种，异步复制和其名字的意义一样主库在写入 binlog 之后告诉从库数据曾经发送而后本人干本人的事件去了，此时从库会被动发动 IO 申请建设和主库的连贯，接着是 binlog 拷贝到本地写入到 relay log 中进行重放日志最终 sql 线程重放而后在最初达到数据统一的成果。

根本的解决步骤如下：

主节点执行备份线程，读取 binlog 文件并且发送给从库。
从库的 io 线程和主库建设连贯，应用二进制转储线程读取到 binlog 文件，如果数据是同步的则睡眠期待主库发送同步信号，否则获取数据把 binlog 文件保留为 relay log，留神从库不会立马执行主库发来的 sql，而是会放入到 redo log 中。
从库会通过 sql 线程定时读取最新的 relay log 文件，对于 relay log 重放，重放之后本人再记录一次 binlog 日志。（本人再记录一次次要是因为从库自身也有可能是其余子从库的主库，整个过程依照雷同的步骤解决）

异步复制的问题：

读取 binlog 文件的时候主节点的状态？是否须要锁表？

主节点此时仍然能够失常执行，不须要锁表，因为操作的是二进制的 binlog 文件。

重放 relay log 是啥意思？

relay log：中继日志，relay

relay：中继。

重放：从新播放能够认为是重读

从库复制波及多少线程

两个，一个 IO 线程一个 SQL 线程，IO 线程负责从主库获取 binlog 文件，SQL 负责将中继日志进行重放。

为什么从库最初还须要记录一次 binlog？

因为从库也有可能存在本人的子节点，所以也须要依照同样的步骤复制给本人的子节点。

为什么须要 relay log 中继日志？

如果备库间接连贯主库进行拷贝并且间接执行可能会存在问题，如果此时主库频繁的往 binlog 塞日志，那么很容易呈现主库和备库之间长时间连贯并且备库无奈失常工作。

异步复制流程图：依据流程图能够看到，在主库执行完 sql 之后会记录 binlog 文件并且 commit 事务，通过异步的形式把 binlog 发给其余分片上的从库，从库会依据主库的 binlog 重放 relay log 之后最终记录到binlog，而后和主库一样实现提交的动作保证数据同步。

问题：
如果主库写入 binlog 然而此时忽然断电，然而 Binlog 曾经发送给从节点，此时会呈现什么状况？
没有影响，因为记录 binlog 意味着曾经实现了事务的操作，即时断电主库也能够通过 redo log 和 bin log 复原数据，因为事务曾经提交了，发送给从库呈现新增数据也是失常的。

异步复制有上面的特点：

对于网络提早具备肯定要求
实现形式和原理简略。
不能保障日志被送到备库 可能会呈现日志失落。

通过下面的特点介绍，能够发现异步复制的最大问题就在于异步两个字，因为网络环境的复杂性主库和备库之间是相互拆散的，为了确保数据的确送到了从库，Mysql 在此基础上改良复制的流程，前面提到的半同步复制其实就在提交之前进行一次“确认”的操作。

半同步复制：

如下面所说的，半同步复制其实就在主库发送 binlog 文件之后没有立马提交事务，而是期待所有的从库接管到了 binlog 并且写入到 relay log 之后才进行事务提交，留神这里并不是等所有的从库提交再提交，而是确认承受到 binlog 转为 relay log 之后立马就进行提交。

半同步的复制是提早了主库肯定的提交工夫，确保主备数据同步。

问题：

半同步复制工夫期待过久怎么办？

rpl_semi_sync_master_timeout 参数能够配置脱扣工夫，脱扣工夫是主备库之间的同步过了多少工夫超时。

组复制（Mysql Group Replication）

组复制是 Mysql5.7 版本呈现的新个性，组复制的外围是确保数据的强一致性，毛病也很显著会导致数据库系统的响应速度受到影响。

介绍：复制组由多个 Mysql Server 组成，组中的每个成员能够在任何时候独立执行事务，他们外部应用十分复杂的共识算法进行辨认

（外围个人通信零碎（GCS）协定），组复制的特点是在复制的时候须要放弃 强一致性，如上面的图结构显示，和下面提到了复制形式不

同，在组复制的模式下所有的节点是近似平级关系，通过播送的模式告诉改变，当主节点产生 binlog 变动的时候，须要让其余的同级节点

收到告诉验证之后能力进行事务的提交。

读者可能会误会组复制让 Mysql 实现集群了，然而只是有其行没有其本质组复制只不过是用了些新的对概念包装了一些旧货色罢了，可

以看到组复制的最大痛点在于强一致性的等待时间，看起来很美妙，数据仿佛永远都不会呈现故障相对能保持一致，实际上这个组复制的

等待时间在很多高并发的零碎是没法承受的。

组复制的概念呈现于比拟新的 Mysql 版本并且在 Mysql8.0 中被最终欠缺，这里找了两篇文章供大家拓展浏览：

Mysql 5.7 基于组复制(Mysql Group Replication) – 运维小结 – 散尽浮华 – 博客园 (cnblogs.com) – 运维小结 – 散尽浮华 – 博客园 (cnblogs.com)”)
官网用了一个小节专门吹组复制：Mysql :: Mysql 8.0 Reference Manual :: 18 Group Replication

这里仅仅记录操作，倡议读者依据本人的版本进行试验，留神上面的试验在默认的状况下是 异步复制：

为了模仿复制能够先弄两台 linux 虚拟机，比方古代 144 和 146 两台服务器，装置了同样为 5.7 版本的 Mysql，这个试验中 144 为主库，146 位从库。

两个试验数据库的数据库内容如下：

两个服务器都须要批改配置 ini 文件并且凋谢 binlog，图中为局部配置：

systemctl restart Mysqld重启主库的服务器，此时能够通过命令 show master status 和show slave status来判断是否形成主备架构。
Mysql 命令连贯主库同时执行 flush tables with read lock 加上全局锁来进行第一次主备数据全量同步，此时能够应用 show master status 查看以后 binlog 的写入的地位，应用 Mysqldump 命令进行全量备份。

全量备份的应用能够浏览：” 三高 ”Mysql – Mysql 备份概览中对于 Mysqldump 复制这一部分的内容。

把备份文件到从库上执行 source xxx.sql 实现主备数据之间的同步，留神此时从库须要和主库一样须要将 binlog 的日志的写入地位进行同步，而 binlog 文件的写入地位通过主库的 show master status 进行查看，比方这里从库就须要同步到主库的 .000012 的 194 地位。

关键步骤：从库如果是 slave 状态须要通过命令 stop slave 进行 slave 主库，并且执行 reset slave 重置状态，为了和主库放弃同步，须要通过上面的命令同步 binlog 的写入地位，实现之后通过 show slave status 查看两边是否同步：

最初查看是否失常主备复制同步：

至此，异步主从复制的实战流程完结，如果咱们想要试验半同步复制，须要在 my.ini 中配置半同步的插件，因为半同步复制并不是原生反对的，须要额定的插件反对。

最初通过 show variances like 'rpl_semi_sync_master_timeout' 能够查看脱扣工夫，通过 show processlist 命令能够查看主节点的以后线程状况。

主节点有上面的线程，能够看到有一个期待 Binlog 写入的线程，这是从库期待主库改变 binlog 的一个线程工作

从节点有两个线程，也能够通过 show processlist 办法查看 IO 现场和重放 relay log 的两个线程。

通过上一个大节的介绍，咱们发现传统主备节点复制的操作比拟麻烦，特地是 LOG_FILE + LOG_POS 的形式解决比拟麻烦，根本原因是备库不晓得从哪一个 log 开始进行复制，Mysql 针对这一点在更高的版本中提供了全局事务的个性，给每一个事务配置一个惟一 ID，也就是 Mysql5.6 的 GTID 加强模式，GTID 就是 server_uuid:gno 组成一个键值对：

server_uuid（节点的 UUID）
Gno：事务流水号（回滚之后进行回收）

启动 GTID 模式的配置很简略，在配置文件中退出如下的配置：

gitd_mode = on
enforece_gtid_consistency = on

最初应用 GTID 配置能够批改上一节最初局部提到的 change..master 局部：

change master to 
MASTER_HOST = 'xx.xx.xx.xx'
MASTER_USER = 'root'
master_auto_position = 1

GTID 复制是为了加强主从复制缩小故障率而呈现的，举荐默认开启

留神在主从复制中最为要害的 binlog 格局随着 Mysql 的降级是做过调整的，在 Mysql5.0 之前的 binlog 格局是 statement 格局，同时外部记录的是原文，而对于一些非凡的语句来说同样的语句可能会有不同的成果，这时候就会有数据危险，比方上面的语句在解决对过程中会呈现问题：

为什么要应用 row 格局

通过下面的介绍，咱们大抵理解了为什么须要应用 row 格局，因为 row 格局 不记录 SQL 语句的原文，而是记录数据行的变动。然而 row 格局仍然没有解脱记录逻辑日志的这一条规定，而记录文本数据数据量比 statement 更大，之后会呈现空间占用比拟大的问题。

进一步改良：mixed 格局的 binlog

针对 binlog 的 row 格局文本存储的问题，Mysql 在提供了一种混合 row 和 statement 的对混合模式，对于有数据同步危险的应用 row 格局，而对于没有危险的则间接应用原文。

另外 statement 和 row 格局也称为给予语句的复制和给予行的复制，只是说法上的差异而已实质上并没有差异。

首先咱们须要理解为什么主备之间存在提早？

log 的传送其实开销比拟小，次要的耗费是生产 relay log 的耗时，
备库的性能比主库要小很多
备库承当了很多剖析 SQL 的工作，压力比主库要打
如果主库有长事务没有提交。

通常主备提早有上面的解决形式：

主备之间应用雷同配置的机器
备库敞开 log 实时落盘
应用大数据系统分担日志解决工作

然而下面的解决也不是完满的，存在比拟大的缺点，并且通过下面的解决形式之后，仍然没有方法齐全排除所有的问题，还有诸如备库的性能因为被动承受复制，性能要比主库大打折扣，主库反对“多线程”而备库限度于“单线程”。

总结下面的内容能够发现主备提早的特点如下：

备库提早次要是备库执行总是要比主库要慢。
通过降级备库的硬件和敞开 log 实时落盘进步性能
减少其余的组件分担复制的压力
对于新时代的利用零碎，应用“组复制”是官网的举荐抉择。

针对下面的问题，Mysql 对于传统的复制模式提供了更加细分的解决形式：并行复制。并行复制通常有两种思路，第一种是按表散发，第二种是按行散发，以及较新版本呈现的事务组并行策略。

并行复制的原理

留神：Mysql 5.6的版本才呈现并行复制。

并行复制是在主从复制同步的时候，从库在获取到主库的 binlog 日志并且保留为 relay log 之后，把重放 relay log 的工作另外调配一个叫做 worker 的线程执行，sql 线程则执行调配 relay log 的工作，从库只须要读取并分配任务不须要本人进行解决，从而更高效的重放 relay log。

难点：如何调配 relay log 日志。

这里还波及几个关联问题：事务存在上下文依赖如何解决？如果存在抵触如何调配解决？（比方新增数据同时并行删除）。

并行复制名称看起来比拟高大上，然而最大的问题是 仅仅只是放慢了重访 relay log 的速度，对于 binlog 解析为 relay log 没有进行更多改良，也就是说把工作分担给了第三者让本人压力小了一点点，然而本人的处理速度和之前根本没太大变动。咱们能够通过上面的图进行理解：

并行复制 – 调配思路：

因为并行复制的难点在于如何散发 relay log，Mysql 提供了两种调配形式：按行调配 和按表调配。

在最晚期还有一种思路呈现那就是 按库并行 的策略：这种解决形式是散发抉择形式特地快，同时反对各种的 log 格局散发，然而同时毛病也非常明显，库粒度十分大并且负载平衡十分难。

开启形式：

salve-parallel-type=DATABASE，这是最后配置，由依照库的形式并行复制，这样的解决形式有上面的特点：

散发抉择十分快，反对各种 log 格局
难以进行负载平衡，库粒度十分大。因为所有的 worker 实际上都是调配到一个独自的库进行解决，和之前的单线程解决形式并没有太大的却别。

基于下面的一些问题，在后续的版本中 Mysql 对于并行复制进行了优化。

当然 Mysql 不会满足于库的粒度，所以后续基于按库复制根底上呈现更多调配的形式：

按行调配：因为 binlog 记录的是数据行的改变内容，如果批改的不是同一行就能够调配，否则就把他们调配到同一个线程执行。

按表调配：语句依照不同的表进行分类，同一个表的事务放到同一个线程进行调配。

按事务组调配：Mysql5.7 提出，应用事务组的形式进行并发提交和解决，下文将会独自介绍。

Mysql 依照事务组并行策略（Mysql5.7 新个性）

在介绍具体的策略之前，须要解释一下主库对于 binlog 刷盘的原理，binlog 刷盘分为两步动作，通过这两步动作之后，由此主库的 binlog 多线程拜访，对于多线程事务的提交就能够进行并行刷盘的操作：

binlog → binlog cache 写到 binlog 内存文件
binlog 内存文件刷到磁盘中（fsync 长久化磁盘）

事务组并行策略：

上面这图看起来十分复杂，其实简略了解能够认为每一次同步相似咱们一次 ctrl+s 的动作，咱们每一次的保留动作都须要刷新到磁盘，在多线程的操作过程中批改先是批改内存，而后依照程序的进行刷盘。这里有读者可能会疑难，如果线程之间存在事务穿插怎么办？所以这里会根据 binlog 刷磁盘的逻辑，依照相似按行调配的解决形式将多线程写入到一个 binlog 缓冲文件之后一次刷新磁盘。

这样事务组并行缓冲合并刷新到形式，使得并行调配必定会存在上面两种准则：

可能在同一个组里提交的事务，肯定不会批改同一行
主库上能够并行执行的事务，备库上也肯定是能够并行执行的

吐槽：其实这个个性说白了还是“抄”了 Mysql 原作者的思路，这里提一嘴 MariaDB 是在 Mysql 版权被 Oracle 收买后，由 Mysql 创始人 Monty 创建的一个开源数据库，其版权授予了“MariaDB 基金会（非营利性组织）。果然最理解儿子的还是亲爹。

上面的结构图是依照下面的文字描述的事物组并行策略的改良图：

能够看到下面的解决形式非常消耗 IO 性能，并行刷盘频繁节约性能，能够发现最初一步能够合并后面的并行批改通过一次刷盘实现，所以呈现了上面的优化形式：

事务组的含意就是将上面多个并行刷盘的操作合并为同一个，然而这时候又会有一个疑难到底期待多久合并并且刷新一次磁盘？

Mysql 应用了上面的参数进行管制：

（两个条件是或的关系）

binlog\_group\_commit\_sync\_delay：提早多少微秒之后调用fsync()。
binlog\_group\_commit\_sync\_no\_dalay\_count：相似多少次之后才调用fsync()。

事务组并行策略优化（Mysql5.7.22 版本）

在 5.7 版本中还存在过一个小版本的降级对于这个策略做了更多的扩大，比方上面的参数：

binlog-transaction-dependency-tracking 参数

COMMIT\_ORDER：默认策略
WRITESET：没有批改雷同行的事务能够并行。
WRITESET\_SESSION：同一个线程先后执行两个事务不能并行。

如何判断备库曾经追上去：

强制延时
- seconds\_behind\_master = 0
比照 binlog 执行位点
比照 GTID 比照状况

然而无奈从根本上解决备库提早的问题，它具备上面几个无奈解决的根本性问题：

binlog 传送和 redo log 重放须要工夫，这时候受到网络 IO 或者磁盘 IO 阻塞的影响
备库复制永远只能尽可能减小，无奈从实质上完满解决提早问题。
备库因须要

针对次仍然能够应用上面的形式判断具体事务是否重放：

期待 binlog 位点：比方通过上面的命令间接监听到具体位置的变动，一旦有变动就认为主库的数据事务实现了。

期待 GTID（5.7.6 之后每次都会返回 GTID），通过上面的命令查看惟一事务 ID：

主 - 主复制架构一半在一些我的项目比拟小或者一些小公司常常应用，主主复制也就是两个库不存在主备关系，而是通过一个热备的库对于主节点宕机之后长期撑持业务应用。简略了解能够了解为柴油发电机，在停电的时候长期充当应用。

两个节点均为 Master
两个节点均为 Salve
两库的数据相互复制
如果其中一个呈现问题，立即切换到另一个库。

主主架构有上面一些比拟显著的问题：

数据抵触
- 两边同时插入数据，呈现抵触
- 约定好插入不同 ID
- 只有一些库可写，另一个只读
- 切换过快的数据库失落问题。
利用切换问题
- 利用本人切换比拟麻烦
- keepalived 伎俩主动切换
循环复制问题
- 实践上的问题。
未开 GTID：应用 ServerID 过滤。

在复制的局部介绍了复制的基本原理以及 Mysql 复制的三种形式，在 5.6 之后还提供了 GTID 的复制模式使得复制的故障率进一步降落，而针对复制的外围一方面是 binlog 文件，这里简略的介绍了 binlog 文件的三种写入格局，最早的 statement，罕用的 row 和一种举荐的混合模式，然而混合模式应用频率仍然不如 row 多，外部的机制在实际过程中仍然发现不少问题。

而另一方面则是在整个复制过程中插入“中间层”放慢局部操作的处理速度，比方在重放 relay log 中退出一个 worker 专门负责解决和散发重放 relay log 的工作，Mysql 在这个 relay log 重放散发的过程中做文章引入了并行复制，并行复制在晚期应用按库的力度调配，这尽管很简略好实现然而因为粒度太大被立马改良，后续呈现了按行调配和按表调配，最终呈现了按事务组的策略调配，这些内容咱们只须要了解，并不要去背诵或则牢记。

介绍完主备复制以及相干优化之后，咱们切换视角来到了主库这边，主库这边也呈现了更优良的同步策略，那就是间接针对点进行监控，当然这种解决形式比拟极其少数状况下不会接触到所以本局部没有过多介绍。

最初咱们简略介绍了一下双主的架构，适宜大部分的中小公司，对于集体开发的开源我的项目也能根本应酬需要。

复制局部仅仅是三高 Mysql 的第一个大关，前面和还有切换和扩大等着咱们介绍，这里也会持续整顿给大家带来更多好内容。

关于mysql:三高Mysql-搭建三高架构之复制

三高 Mysql – 搭建“三高”架构之复制

引言

什么是“三高”架构？

复制

复制原理

主从复制实战

GTID 加强复制模式

binlog 格局格局演变

主备提早如何解决

强制走主库

简略 - 双主架构

小结

写在最初