MySQL系列(十)：主从架构

在这里插入图片描述

一：主从架构

常见的主从架构模式有四种：

  • 一主多从架构：适用于读大于写的场景，采用多个从库来分担数据库系统的读压力。
  • 多主架构：适用于读写参半的场景，采用多个主库来承载数据库系统整体的读写压力。
  • 多主一从架构：适用于写大于读的场景，采用多个主库分担写压力，单个从库承载读压力。
  • 级联复制架构：适用于读大于写的场景，采用单个从节点来分担从库对主库造成的 I/O 压力。
    接下来的讨论都是针对最常见的一主多从架构。

主从架构中必须有一个主节点，以及一个或多个从节点，所有的数据都会先写入到主，接着其他从节点会复制主节点上的增量数据，从而保证数据的最终一致性，使用主从复制方案，可以进一步提升数据库的可用性和性能：

  • 在主节点宕机或故障的情况下，从节点能自动切换成主节点的身份，从而继续对外提供服务。

  • 提供数据备份的功能，当主节点的数据发生损坏时，从节点中依旧保存着完整数据。

  • 可以基于主从实现读写分离，主节点负责处理写请求，从节点处理读请求，进一步提升性能。
    但无论任何技术栈的主从架构，都会存在致命硬伤，同时也会存在些许问题需要解决：

  • 硬伤：木桶效应，一个主从集群中所有节点的容量，受限于存储容量最低的哪台服务器。

  • 数据一致性问题：由于同步复制数据的过程是基于网络传输完成的，所以存储延迟性。

  • 脑裂问题：从节点会通过心跳机制，发送网络包来判断主机是否存活，网络故障情况下会产生多主。

二：主从复制

MySQL 集群的主从复制过程梳理成 3 个阶段：

  • 写入 Binlog：主库更新本地存储数据，并写 binlog 日志，然后提交事务。
  • 同步 Binlog：把 binlog 复制到所有从库上，每个从库把 binlog 写到暂存日志中。
  • 回放 Binlog：回放 binlog，并更新存储引擎中的数据。
    在这里插入图片描述

具体详细过程如下：

1.MySQL 主库在收到客户端提交事务的请求之后，会先更新数据；
2.数据写入完成后，再去写入 binlog，然后提交事务，返回客户端“操作成功”的响应；
3.主节点上有一条专门监听 binlog 的 log dump 线程；
4.当 log dump 线程监听到日志发生变更时，会通知从节点来拉取数据；
5.从节点有专门的 I/O 线程（io_thread）用于等待主节点的通知，当收到通知时会去请求一定范围的数据；
6.当从节点在主节点上请求到数据后，会将得到的数据写入到 relay-log 中继日志，然后返回给主库“复制成功”的响应；
7.从节点上有专门负责监听 relay-log 变更的线程（sql_thread），当日志出现变更时会开始工作；
8.中继日志出现变更后，会从中读取日志记录，然后回放 binlog 更新数据，实现主从数据一致性。

复制模式
同步复制
MySQL 主库提交事务的线程要等待所有从库的复制成功响应，才返回客户端结果。这种方式在实际项目中，基本上没法用，原因有两个：一是性能很差，因为要复制到所有节点才返回响应；二是可用性也很差，主库和所有从库任何一个数据库出问题，都会影响业务。

异步复制
是 MySQL 默认使用的复制模式，MySQL 主库提交事务的线程并不会等待 binlog 同步到各从库，就返回客户端结果。这种模式一旦主库宕机，数据就会发生丢失。

半同步复制
MySQL 5.7 版本之后增加的一种复制方式，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。这种半同步复制的方式，兼顾了异步复制和同步复制的优点，即使出现主库宕机，至少还有一个从库有最新的数据，不存在数据丢失的风险。

增强式半同步复制
也被称为无损复制，也是 MySQL5.7 引入的。和之前传统的半同步复制区别在于：从 after-commit 变成了 after-sync ，如果将复制模式配置成半同步时，默认就会选用无损复制模式。

after-commit：主库在未收到从库的 ACK 之前，虽然不会给客户端返回写入成功，但本质上会提交事务，也就是主库中的其他事务是可以看见对应数据的，当此时出现宕机时，就会导致旧主上能查询出的数据，在新主上无法查询出来了。
after-sync：当主库未收到从库的 ACK 之前，也不会在主库上提交事务，也就是保证了主从节点的数据强一致性，解决了 after-commit 中存在的问题。但是相较于 after-commit，可能导致事务迟迟不提交，从而导致锁资源不释放和阻塞等待等性能问题。

延迟复制
当从库上的 I/O 线程，将主库的 binlog 请求回来后，从节点的 SQL 线程并不会立刻解析日志执行，而是等待一段时间后再解析日志执行，这个等待的时间可以配置。

延迟复制的好处是可以防止误删操作。缺点是会有很长一段时间的数据不一致，可能导致数据的丢失。一般用于仅作为备库的节点使用，不能进行读写分离。

并行复制
GTID复制
GTID，Global Transaction Identifier，用于唯一地标识一个事务。

GTID 由节点 UUID + 事务 ID 两部分组成，MySQL 在第一次启动时都会利用 UUID 随机生成一个 server_id，还会对每一个写事务都分配一个顺序递增的值作为事务 ID，GTID 的格式为 server_uuid:trx_id。

基于 GTID 的复制过程：

master 在更新数据时，会为每一个写事务分配一个全局的 GTID，并记录到 binlog 中。
slave 节点的 I/O 线程拉取数据时，会将读到的记录写到 relay-log 中，并设置 gtid_next 值。
slave 节点的 SQL 线程执行前，会读取 gtid_next 值得知接下来该解析哪条日志并执行。
slave 节点的 SQL 线程在执行时，会先比对自身的 binlog 日志中是否有对应的 GTID：
有：意味着该 GTID 对应的事务已经执行过了，slave 会自动忽略掉这条记录。
没有：SQL 解析该 GTID 对应的 relay-log 记录并执行，再将 GTID 记录到 binlog。

基于 GTID 的自动同步：发生主从切换时可以执行 change master to master_auto_position=1，会自动去新主库上寻找数据的同步点。

GTID 是基于事务来实现的，也就代表不支持事务的存储引擎无法使用这种机制。

组复制
GTID 复制是组复制得基础。组复制是指将一组并行执行的事务，全部放入到一个 GTID 中记录，后续从节点同步数据时，会一次性读取这一组事务解析并执行，即组提交。

组复制的 GTID 通过逗号分隔。

并行复制
并行复制是在组复制的基础上实现的。因为能够在同一时间内提交的事务，绝对是不存在锁冲突的，所以可以开启多条线程同时执行一个组中不同的事务。

并行复制能够在很大程度上提升从库复制数据的速度，也就是能够让从库的数据实时性提升。

在 MySQL5.7 中官方为这种机制命名为 enhanced multi-threaded slave，简称 MTS 机制，同时为了兼容 5.6 版本中的并行复制，又多加入了一个 slave-parallel-type 参数：

DATABASE：默认的并行复制模式，表示基于库级别来完成并行复制。
LOGICAL_CLOCK：表示基于组提交的方式来完成并行复制。
虽然 5.7 中的并行复制，在一定程度上解决了原有的从库延迟问题，但如果一个新的从节点加入集群时，因为要从头开始同步数据，这种并行复制的模式依旧存在效率问题，而到了 MySQL8.0 对于并行复制技术提出了真正的解决之道，也就是基于 writeset 的 MTS 技术。即多个事务之间，只要变更的数据记录没有重叠，也就是操作的数据没有冲突，无需在一个事务组内，也可以支持并发执行。

两阶段提交
2PC，two-phase commit protocol。

事务提交后，redo log 和 binlog 都要持久化到磁盘，但是这两个是独立的逻辑，可能出现半成功的状态，这样就造成两份日志之间的逻辑不一致。

如果在将 redo log 刷入到磁盘之后， MySQL 突然宕机了，而 binlog 还没有来得及写入。MySQL 重启后，通过 redo log 能将 Buffer Pool 中的相应数据恢复到新值，但是 binlog 里面没有记录这条更新语句，在主从架构中，binlog 会被复制到从库，由于 binlog 丢失了这条更新语句，从库的数据是旧值；
如果在将 binlog 刷入到磁盘之后， MySQL 突然宕机了，而 redo log 还没有来得及写入。由于 redo log 还没写，崩溃恢复以后这个事务无效，所以数据还是旧值；而 binlog 里面记录了这条更新语句，数据是新值；
在持久化 redo log 和 binlog 这两份日志的时候，如果出现半成功的状态，就会造成主从环境的数据不一致性。因为 redo log 影响主库的数据，binlog 影响从库的数据，所以 redo log 和 binlog 必须保持一致才能保证主从数据一致。

MySQL 为了避免出现两份日志之间的逻辑不一致的问题，使用了「两阶段提交」来解决，两阶段提交其实是分布式事务一致性协议，它可以保证多个逻辑操作要不全部成功，要不全部失败，不会出现半成功的状态。

当客户端执行 commit 语句或者在自动提交的情况下，MySQL 内部开启一个 XA 事务，分两阶段来完成 XA 事务的提交，分别是准备阶段和提交阶段。

prepare 阶段：将 XID（内部 XA 事务的 ID） 写入到 redo log，同时将 redo log 对应的事务状态设置为 prepare，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；
commit 阶段：把 XID 写入到 binlog，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事务接口，将 redo log 状态设置为 commit，此时该状态并不需要持久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事务已经执行成功；
在这里插入图片描述

不管是时刻 A（redo log 已经写入磁盘， binlog 还没写入磁盘），还是时刻 B （redo log 和 binlog 都已经写入磁盘，还没写入 commit 标识）崩溃，此时的 redo log 都处于 prepare 状态。

在 MySQL 重启后会按顺序扫描 redo log 文件，碰到处于 prepare 状态的 redo log，就拿着 redo log 中的 XID 去 binlog 查看是否存在此 XID：

如果 binlog 中没有当前内部 XA 事务的 XID，说明 redolog 完成刷盘，但是 binlog 还没有刷盘，则回滚事务。对应时刻 A 崩溃恢复的情况。
如果 binlog 中有当前内部 XA 事务的 XID，说明 redolog 和 binlog 都已经完成了刷盘，则提交事务。对应时刻 B 崩溃恢复的情况。
可以看到，对于处于 prepare 阶段的 redo log，即可以提交事务，也可以回滚事务，这取决于是否能在 binlog 中查找到与 redo log 相同的 XID，如果有就提交事务，如果没有就回滚事务。这样就可以保证 redo log 和 binlog 这两份日志的一致性了。

两阶段提交是以 binlog 写成功为事务提交成功的标识。

事务没提交的时候，redo log 也是可能被持久化到磁盘。但是 binlog 必须在事务提交之后，才可以持久化到磁盘。

组提交
两阶段提交虽然保证了两个日志文件的数据一致性，但是性能很差，主要有两个方面的影响：

磁盘 I/O 次数高：对于“双1”配置，每个事务提交都会进行两次 fsync（刷盘），一次是 redo log 刷盘，另一次是 binlog 刷盘。
锁竞争激烈：两阶段提交虽然能够保证「单事务」两个日志的内容一致，但在「多事务」的情况下，却不能保证两者的提交顺序一致，因此，在两阶段提交的流程基础上，还需要加一个锁来保证提交的原子性，从而保证多事务的情况下，两个日志的提交顺序一致。
MySQL 引入了 binlog 组提交（group commit）机制，当有多个事务提交的时候，会将多个 binlog 刷盘操作合并成一个，从而减少磁盘 I/O 的次数。

MySQL 5.7 开始有 redo log 组提交。
引入了组提交机制后，prepare 阶段不变，只针对 commit 阶段，将 commit 阶段拆分为三个过程：

flush 阶段：多个事务按进入的顺序将 binlog 从 cache 写入文件（不刷盘）；
sync 阶段：对 binlog 文件做 fsync 操作（多个事务的 binlog 合并一次刷盘）；
commit 阶段：各个事务按顺序做 InnoDB commit 操作；
上面的每个阶段都有一个队列，每个阶段有锁进行保护，因此保证了事务写入的顺序，第一个进入队列的事务会成为 leader，领导所在队列的所有事务，全权负责整队的操作，完成后通知队内其他事务操作结束。

同一时刻只允许一组事务提交。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/220601.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

可视化 Java 项目

可视化 Java 项目

有一定规模的 IT 公司，只要几年，必然存在大量的代码，比如腾讯，2019 年一年增加 12.9 亿行代码，现在只会更多。不管是对于公司，还是对于个人，怎么低成本的了解这些代码的对应业务，所提…
阅读更多...
Spring Boot统一功能处理（Spring拦截器）

Spring Boot统一功能处理（Spring拦截器）

为什么需要Spring拦截器 原生的Spring AOP实现统一拦截有两大难点，1.定义拦截的规则难写；2.在切面类中拿到HttpSession比较难。为此Spring官方提供了拦截器帮我们解决了上面痛点。 实现登入信息验证拦截器 实现HanderInterceptor接口重写preHeadler方…
阅读更多...
【LeetCode刷题】--172.阶乘后的零

【LeetCode刷题】--172.阶乘后的零

172.阶乘后的零 方法&#xff1a; class Solution {public int trailingZeroes(int n) {int ans 0;for(int i 5;i<n;i5){for(int x i; x % 50; x/5){ans;}}return ans;} }进一步优化&#xff1a; class Solution {public int trailingZeroes(int n) {int ans 0;while (n…
阅读更多...
【个人版】SpringBoot下Spring-Security核心概念解读【二】

【个人版】SpringBoot下Spring-Security核心概念解读【二】

Spring-Security HttpSecurity Spring-Security全局导读&#xff1a; 1、Security核心类设计 2、HttpSecurity结构和执行流程解读 3、Spring-Security个人落地篇 背景&#xff1a; Spring-Security框架的核心架构上一篇已经概述&#xff0c;展示其执行流程及逻辑&#xff0c;但…
阅读更多...
【期末考复习向】transformer的运作机制

【期末考复习向】transformer的运作机制

1.transformer的encoder运作 transformer的encoder部分包括了输入和处理2大部分。首先是输入部分inputs&#xff0c;这里初始的inputs是采用独热向量进行表示的&#xff0c;随后经过word2vec等操作把独热向量&#xff08;采用独热向量的好处就是可向量是正交的&#xff0c;可以…
阅读更多...
re:Invent 产品体验分享：Amazon ElastiCache Serverless 缓存即时扩展功能与感受

re:Invent 产品体验分享：Amazon ElastiCache Serverless 缓存即时扩展功能与感受

授权说明&#xff1a;本篇文章授权活动官方亚马逊云科技文章转发、改写权&#xff0c;包括不限于在亚马逊云科技开发者社区、 知乎、自媒体平台、第三方开发者媒体等亚马逊云科技官方渠道&#xff09;。 文章目录 前言产品介绍产品使用步骤1.创建缓存服务2.安全组开放访问权限…
阅读更多...
C++从bing采集各行业的企业官网信息

C++从bing采集各行业的企业官网信息

作为一名合格的销售&#xff0c;除了自己的人脉&#xff0c;还应该有新鲜的客户加入并发掘。不管哪行哪业&#xff0c;知彼知己&#xff0c;方才能做到百战百胜。今天我就用我们的专业技能&#xff0c;让销售获取更多同行业的公开企业信息&#xff0c;让业绩顺风顺水。 通常在C…
阅读更多...
如何实现电脑文件夹自动备份？以下是图解教程

如何实现电脑文件夹自动备份？以下是图解教程

在当今迅猛发展的科技时代&#xff0c;电脑已经成为不可或缺的办公工具。随着使用时间的增加&#xff0c;存储在电脑中的文件数量也逐渐增多。然而&#xff0c;由于设备故障、手动误删等原因&#xff0c;文件的丢失问题成为一个不可忽视的风险。如果丢失的文件具有重要性&#…
阅读更多...
数学learning

数学learning

目录 移动平均 简单移动平均 加权移动平均 指数移动平均 矩阵求导 矩阵对标量求导 Matrix-by-scalar 标量对矩阵求导 Scalar-by-matrix 参考博客 移动平均 优化算法里面会涉及到一个知识点&#xff1a;指数移动平均。 但是为了知识的完整性&#xff0c;这里会将常见的移动…
阅读更多...
MCU平台下一种简单的文件系统设计构想

MCU平台下一种简单的文件系统设计构想

本文介绍MCU平台下一种简单的文件系统设计构想。 在使用MCU的项目中&#xff0c;经常会涉及到一些数据的存储&#xff0c;受限于硬件&#xff0c;又不太可能直接上文件系统&#xff08;如FAT文件系统&#xff09;&#xff0c;直接指定存储地址&#xff0c;数据长度对数据进行读…
阅读更多...
React antd如何实现＜Upload＞组件上传附件再次上传已清除附件缓存问题

React antd如何实现＜Upload＞组件上传附件再次上传已清除附件缓存问题

最近遇到一个React上传组件的问题&#xff0c;即上传附件成功后&#xff0c;文件展示处仍然还有之前上传附件的缓存信息&#xff0c;需要解决的问题是&#xff0c;要把上一次上传的附件缓存在上传成功或者取消后&#xff0c;可以进行清除 经过一顿试错&#xff0c;终于解决了这…
阅读更多...
SE考研真题总结（二）

SE考研真题总结（二）

接上条&#xff0c;今天继续更新~ SE考研真题总结&#xff08;一&#xff09;-CSDN博客文章浏览阅读340次&#xff0c;点赞6次&#xff0c;收藏11次。本帖开始分享考研真题中设计【软件工程】的部分&#xff0c;预计会出5期左右&#xff0c;敬请期待~https://blog.csdn.net/js…
阅读更多...
EasyRecovery(数据恢复软件) 2024中文绿色无需激活版下载

EasyRecovery(数据恢复软件) 2024中文绿色无需激活版下载

EasyRecovery是一款功能强大且专业的数据恢复软件&#xff0c;软件能够对电脑误删的文件进行恢复&#xff0c;包括格式化硬盘是数据恢复、手机U盘数据恢复等&#xff0c;小编今天给大家带来的是根据官软件解压后直接使用。感兴趣的朋友快来下载使用吧。 EasyRecovery-2024mac最…
阅读更多...
Pytorch-CNN轴承故障一维信号分类(二)

Pytorch-CNN轴承故障一维信号分类(二)

目录 前言 1 数据集制作与加载 1.1 导入数据 1.2 数据加载&#xff0c;训练数据、测试数据分组&#xff0c;数据分batch 2 CNN-2D分类模型和训练、评估 2.1 定义CNN-2d分类模型 2.2 定义模型参数 2.3 模型结构 2.4 模型训练 2.5 模型评估 3 CNN-1D分类模型和训练、评…
阅读更多...
flink找不到隐式项

flink找不到隐式项

增加 import org.apache.flink.streaming.api.scala._ 即可
阅读更多...
改进的A*算法的路径规划(2)

改进的A*算法的路径规划(2)

子节点优化选择策略 (1)子节点选择方式 为了找到从起始点到终点的路径&#xff0c;需定义一种可以选择后续节点的方式。在 A*算法中两种常见的方法为4-邻接(见图5-7(a) 和8-邻接(见图5-7(b)), 但考虑到 在复杂越野环境上&#xff0c;我们希望智能车辆允许更多的自由运动来更…
阅读更多...
MSF学习

MSF学习

之前的渗透测试中 其实很少用到 cs msf 但是在实际内网的时候 可以发现 msf cs 都是很好用的 所以现在我来学习一下 msf的使用方法 kali自带msf https://www.cnblogs.com/bmjoker/p/10051014.html 使用 msfconsole 启动即可 首先就是最正常的木马生成 所以这里其实只需…
阅读更多...
分类预测 | Matlab实现DBO-SVM蜣螂算法优化支持向量机的数据分类预测【23年新算法】

分类预测 | Matlab实现DBO-SVM蜣螂算法优化支持向量机的数据分类预测【23年新算法】

分类预测 | Matlab实现DBO-SVM蜣螂算法优化支持向量机的数据分类预测【23年新算法】 目录 分类预测 | Matlab实现DBO-SVM蜣螂算法优化支持向量机的数据分类预测【23年新算法】分类效果基本描述程序设计参考资料 分类效果 基本描述 1.Matlab实现DBO-SVM蜣螂算法优化支持向量机的…
阅读更多...
数理统计基础：参数估计与假设检验

数理统计基础：参数估计与假设检验

在学习机器学习的过程中&#xff0c;我充分感受到概率与统计知识的重要性&#xff0c;熟悉相关概念思想对理解各种人工智能算法非常有意义&#xff0c;从而做到知其所以然。因此打算写这篇笔记&#xff0c;先好好梳理一下参数估计与假设检验的相关内容。 1 总体梳理 先从整体结…
阅读更多...
串口通信(4)-C#串口通信入门实例

串口通信(4)-C#串口通信入门实例

本文通过实例讲解C#串口通信。 入门实例设计一个串口助手&#xff0c;能够很好的涵盖串口要点的使用。 目录 一、成品图 二、界面文件 三、后台代码 四、实例中要点 一、成品图 如下&#xff1a; 实现的过程 创建winform项目&#xff0c;将Form1文件的名称改为MainForm&…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023