MySQL集群架构 —— 集群架构设计

MySQL集群架构 —— 集群架构设计

集群架构设计

架构设计理念

在集群架构设计时，主要遵从下面三个维度：

• 可用性

  • 站点高可用，冗余站点
  • 服务高可用，冗余服务
  • 数据高可用，冗余数据

  **保证高可用的方法是冗余。**但是数据冗余带来的问题是数据一致性的问题。

  实现高可用的方案有以下几种架构模式：

  • 主从模式

    灵活简单，能满足多种需求。比较主流的用法，但是写操作高可用需要自行处理。

  • 双主模式

    互为主从，有双主双写、双主单写两种方式。建议使用双主单写。

• 扩展性

  扩展性主要围绕着读操作扩展和写操作扩展展开

  • 如何扩展以提高读性能

    • 加从库

      简单易操作，方案成熟

      从库过多会引发主库性能损耗。建议不要作为长期的扩充方案，应该设法用良好的设计避免持续加从库来缓解读性能问题。

    • 分表分库

      可以分为垂直拆分和水平拆分，垂直拆分可以缓解部分压力，水平拆分理论上可以无限扩展。

  • 如何扩展以提高写性能

    • 分表分库

• 一致性

  一致性主要考虑集群中各数据库数据同步以及同步延迟问题。可以采用的方案如下：

  • 不使用从库

    扩展读性能问题需要单独考虑，否则容易出现系统瓶颈

  • 增加访问路由层

    可以先得到主从同步最长时间t，在数据发生修改后的t时间内，先访问主库。

主从模式

适用场景

MySQL 主从模式是指数据可以从一个 MySQL 数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样节点不用一直访问主服务器来更新自己的数据，从节点可以复制主数据库中的所有数据库，或者特定的数据库，或者特定的表。

MySQL 主从复制用途：

• 实时灾备，用于故障切换（高可用）
• 读写分离，提供查询服务（读扩展）
• 数据备份，避免影响业务（高可用）

主从部署必要条件：

• 从库服务器能连通主库
• 主库开启 binlog 日志（设置 log-bin 参数）
• 主从 server-id 不同

实现原理

主从复制

主从复制整体分为以下三个步骤：

• 主库将数据库的变更操作记录到 Binlog 日志文件中
• 从库读取主库中的 Binlog 日志文件信息写入到从库的 Relay Log 中继日志中
• 从库读取中继日志信息在从库中进行 Replay，更新从库数据信息。

在上述三个过程中，涉及了 Master 的 BinlogDump Thread 和 Slave 的 I/O Thread、SQL Thread，它们的作用如下：

• Master 服务器对数据库更改操作记录早 Binlog 中，BinlogDump Thread 接到写入请求后，读取 Binlog 信息推送给 Slave 的 I/O Thread
• Slave 的 I/O Thread 将读取到的 Binlog 信息写入到本地 Relay Log 中。
• Slave 的 SQL Thread 检测到 Relay Log 的变更请求，解析 Relay Log 中的内容在从库执行。

上述过程都是异步操作（异步复制），存在数据延迟现象。

下图是异步复制的时序图：

MySQL 主从复制存在的问题：

• 主库宕机后，数据可能丢失
• 从库只有一个 SQL Thread ，主库写压力大时，复制很可能延时

解决办法：

• 半同步复制 —— 解决数据丢失的问题
• 并行复制 —— 解决从库复制延迟的问题

半同步复制

为了提升数据安全，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。

并行复制

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 多线程思想，不断优化，减少复制延迟。

MySQL 5.6 并行复制原理

MySQL 5.6 版本支持并行复制，但是其并行只是基于库的。如果用户的 MySQL 数据库中是多个库，对于从库复制的速度的确可以有比较大的帮助。

基于库的并行复制，实现相对简单，使用也相对简单些。基于库的并行复制遇到单库多表使用场景就发挥不出优势了，另外对事务并行处理的执行顺序也是个大问题。

MySQL 5.7 并行复制原理

MySQL 5.7 是基于组提交的并行复制，MySQL 5.7 才可称为真正的并行复制，这其中最为主要的原因就是 slave 服务器的回放与 master 服务器是一致的，即 master 服务器上是怎么并行执行的 slave 上就怎样进行并行回放。不再有库的并行复制限制。

MySQL 5.7中组提交的并行复制究竟是如何实现的？

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，表示这些事务都在一组内，可以进行并行的回放。

最后，如果MySQL 5.7要使用MTS功能，建议使用新版本，最少升级到5.7.19版本，修复了很多Bug。