led灯 东莞网站建设,网站建设哪家质量好,网站建设服务哪里便宜,西安网站制作的公司前言
上一篇介绍了 MySQL 的表分区和分库分表#xff0c;这一篇将介绍主从架构相关的内容。
主从架构
常见的主从架构模式有四种#xff1a;
一主多从架构#xff1a;适用于读大于写的场景#xff0c;采用多个从库来分担数据库系统的读压力。多主架构#xff1a;适用于…前言
上一篇介绍了 MySQL 的表分区和分库分表这一篇将介绍主从架构相关的内容。
主从架构
常见的主从架构模式有四种
一主多从架构适用于读大于写的场景采用多个从库来分担数据库系统的读压力。多主架构适用于读写参半的场景采用多个主库来承载数据库系统整体的读写压力。多主一从架构适用于写大于读的场景采用多个主库分担写压力单个从库承载读压力。级联复制架构适用于读大于写的场景采用单个从节点来分担从库对主库造成的 I/O 压力。
接下来的讨论都是针对最常见的一主多从架构。
主从架构中必须有一个主节点以及一个或多个从节点所有的数据都会先写入到主接着其他从节点会复制主节点上的增量数据从而保证数据的最终一致性使用主从复制方案可以进一步提升数据库的可用性和性能
在主节点宕机或故障的情况下从节点能自动切换成主节点的身份从而继续对外提供服务。提供数据备份的功能当主节点的数据发生损坏时从节点中依旧保存着完整数据。可以基于主从实现读写分离主节点负责处理写请求从节点处理读请求进一步提升性能。
但无论任何技术栈的主从架构都会存在致命硬伤同时也会存在些许问题需要解决
硬伤木桶效应一个主从集群中所有节点的容量受限于存储容量最低的哪台服务器。数据一致性问题由于同步复制数据的过程是基于网络传输完成的所以存储延迟性。脑裂问题从节点会通过心跳机制发送网络包来判断主机是否存活网络故障情况下会产生多主。
主从复制
MySQL 集群的主从复制过程梳理成 3 个阶段
写入 Binlog主库更新本地存储数据并写 binlog 日志然后提交事务。同步 Binlog把 binlog 复制到所有从库上每个从库把 binlog 写到暂存日志中。回放 Binlog回放 binlog并更新存储引擎中的数据。 具体详细过程如下
MySQL 主库在收到客户端提交事务的请求之后会先更新数据数据写入完成后再去写入 binlog然后提交事务返回客户端“操作成功”的响应主节点上有一条专门监听 binlog 的 log dump 线程当 log dump 线程监听到日志发生变更时会通知从节点来拉取数据从节点有专门的 I/O 线程io_thread用于等待主节点的通知当收到通知时会去请求一定范围的数据当从节点在主节点上请求到数据后会将得到的数据写入到 relay-log 中继日志然后返回给主库“复制成功”的响应从节点上有专门负责监听 relay-log 变更的线程sql_thread当日志出现变更时会开始工作中继日志出现变更后会从中读取日志记录然后回放 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复制
GTIDGlobal Transaction Identifier用于唯一地标识一个事务。
GTID 由节点 UUID 事务 ID 两部分组成MySQL 在第一次启动时都会利用 UUID 随机生成一个 server_id还会对每一个写事务都分配一个顺序递增的值作为事务 IDGTID 的格式为 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_position1会自动去新主库上寻找数据的同步点。
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 技术。即多个事务之间只要变更的数据记录没有重叠也就是操作的数据没有冲突无需在一个事务组内也可以支持并发执行。
两阶段提交
2PCtwo-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 也没有关系一样会被认为事务已经执行成功 不管是时刻 Aredo 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领导所在队列的所有事务全权负责整队的操作完成后通知队内其他事务操作结束。
同一时刻只允许一组事务提交。
最后
本文介绍了 MySQL 的主从架构。
至此我的 MySQL 学习笔记就全部更新完毕了。学习和使用 MySQL 陆陆续续也有两三年了从最开始只关注如何使用到现在为了应付面试而更多的关注原理和实现但是很多地方都只是停留在表面并没有自己深入源码去分析和做实验来验证只能说希望以后有机会再次学习吧。
