腾讯云工程师：如何设计和部署高可用MySQL

开始我们今天的主要内容。今天我们主要用什么、为什么以及如何做。这个想法向你展示了MySQL的高可用性。

首先介绍一下什么是高可用？在我看来，这就是公司能够在高质量条件下为用户提供服务的整个运营时间。事实上，我们在处理MySQL工作，大家对数字9比较敏感。当任何人从云供应商选择云产品时，他们首先会查看数据库中有多少个 9。目前腾讯云MySQL可以做到99.95，常年需要25分钟。

据我所知，最高的高可用性可以是三个9和一个6。4个9很难实现，5个9已经是极限了。

为什么要做高可用？因为有太多我们无法控制的因素，比如挖掘机。我记得类似的事件基本上每隔一年就会发生一次。最近想到的是，2015年，杭州萧山某骨干网络被黑客攻击。损坏，导致部分阿里巴巴服务无法使用。此外，还有类似的停电或者一些自然灾害等。值得一提的是，有一些情况是运维人员工作失误，rm整个目录或者drop表就是大白话来逃避删除数据库。有很多不可控的因素。您的数据和用户就是您。如果不加以控制，您的业务将不会增长。

一般有两个指标作为衡量标准。第一个是RPO，第二个是RTO。 RPO是从故障到业务恢复的数据丢失量，RTO是从故障到业务恢复的时间。越短对双方都越好。

我们怎么样？业界一般有三种方法。左边是基于单机存储的方式。这种方式在游戏场景中比较常见。我们在上层使用一个单独的计算机节点，在下层使用三个副本来保证数据的可靠性。如果一个计算节点发生故障，可以快速故障转移到另一个计算节点。自然，腾讯云的MySQL也推出了这种模式。相对来说非常便宜，而且是基本版。任何人都可以从官方网站购买此模组。第二种是基于共享存储，也称为共享磁盘模式。这是比较典型的Oracle RAC架构。下层基于共享存储，上层使用多个计算节点。计算节点故障可以立即从IP列表上报，不影响用户访问。第三种是基于数据复制的模式，也称为Sharing Nothing模式，通过数据传输和复制协议来实现两台主机之间的数据一致性，这也是本次讲解的重点。另外，除了存储节点的高可用之外，它的所有链路也要高可用，比如我们的IDC机房、交换机、主机服务器。

我们引入了基础设施的高可用性。我们经常听到一些术语。第一个是同城双活，第二个是两地三中心。两地三中心，金融场景需求旺盛。其实说白了就是。这意味着我们在同城的两个节点之间有两个距离十公里的数据中心，还有一个距离一百公里的灾备中心，保证了机房的高可用性。它还包括网络和主机。事实上，建筑就是这样。至少你的交换网络有备份。如果其中一个失败，则必须更换另一个。

回到我们的焦点——基于数据复制的高可用。首先，我们来介绍一下备份。备份确实非常重要，备份是最后的保证，但备份确实是不可能的，所以我建议你在云端使用。对于企业来说，最好对自己的IDC进行尽可能多的备份。

MySQL 备份基本上有两种类型：逻辑备份和物理备份。逻辑备份通常使用官方的MySQLDump和第三方工具MyDumper。 MyDumper 受益于多线程备份和快速速度。物理备份使用Percona xtrabackup，不需要放在磁盘上。基于流式并发和压缩，创建备份的成功率更高、速度更快、临时存储更少。最后一张是快照。我们的腾讯云核心备份是通过快照创建的。

基于数据复制方式，通常是master和child两个节点，如何保证数据一致性？事实上，数据是通过复制协议进行传输的，Switch保证了故障后能够尽快恢复服务。右图与腾讯云MySQL架构基本类似。我们采用主从方式。子节点只负责故障转移。如果主节点发生故障，通过自动故障检测和自动故障转移来尽快恢复业务。 。此外，腾讯云MySQL现在可以支持单个驱动上有5个只读节点，实现读写分离。

引入复制。在介绍复制之前，需要先介绍一个重要的概念：binlog。 Binlog是一个二进制文件，主要存储用户数据库中更新的SQL信息。 binlog是什么样的？光盘上看起来是这样的。使用 show binlog events 之后，它看起来像这样。它存储一些元数据，例如位置、事件等。我们通过MySQL官方解析工具mysqlbinlog解析后，是这样的。里面的sql语句是base64编码的。解码后看起来像这样。可以看到有一个输入语句。那么什么时候写binlog呢？通过查看此图，我们知道提交交易有两个阶段：准备和绑定。 binlog是在什么阶段写入的？ Binlog实际上是在prep之后、commit之前写入的。 redolog和undolog是在事务写入过程中生成的。两者有什么区别？我们知道MySQL是多引擎的关系型数据库，binlog是MySQL Server层的日志，redolog是MySQL引擎的InnoDB层的日志；另一个区别是两者写作的时间不同。在准备阶段，每次执行 SQL 语句时都会写入重做日志。 redo和binlog是在prep和commit之前写入的。那么MySQL在主从架构下是如何保证数据一致性的呢？众所周知，MySQL首先将数据写入内存，然后再写入磁盘以提高性能。当数据库运行时会发生停机。恢复计算机时，某些数据可能会写入磁盘，有些数据可能不会写入磁盘。目前，mysql查找binlog的最新同步点或GTID来确定哪些重做日志或回滚实例需要回滚以及哪些事务需要重做。另外，为了高​​性能，MySQL在写入redolog或binlog等日志时，会先写入内存，再写入磁盘。因此，日志放置策略也会影响数据的一致性。为了保证数据一致性，建议将日志参数设置为“双1”，如图所示。

我们来看看整个复制过程。其实很简单。 master通过dump线程将binlog下载到磁盘。 Slave有两个线程，即IO线程和SQL线程。 IO线程接收master的binlog，形成中继日志。 SQL线程并行读取中继日志中的SQL信息，并执行重放操作。一般来说，复制有三种类型：异步复制、半同步复制、强同步。三者之间的区别在于SQL执行结果何时传递给客户端。在异步复制中，Master会忽略Slave，并在执行完SQL后立即将其返回给客户端。这种方法性能最好，但存在数据不一致的可能；通过强同步，master完全关心slave，等待slave重放中继日志，然后再将其返回给客户端。在客户端，这种方法可以保证数据的强一致性，但性能会有所下降；半同步是指Master部分关心Slave，认为只要将binlog转发到Slave端，成为中继日志，就可以返回给客户端。半同步是一种平衡的实现，一方面保证数据一致性，另一方面保证数据库性能。

我们在复制过程中经常遇到滞后问题。如图所示，复制经历了三个阶段：线程转储到磁盘binlog、IO线程到磁盘中继日志、SQL线程重放。这三个步骤是什么？哪一步是瓶颈？之所以是SQL线程，是因为SQL线程在日志回放时顺序执行SQL，而Master则并行对外提供服务。所以这里的瓶颈是SQL线程。您可以通过开启并行复制来解决滞后问题。 MySQL 5.6基于数据库级别的并行复制； MySQL 5.7基于逻辑时钟并行复制，即表级并行； MySQL8.0具有行级别更细粒度的并行复制。 ，复印效率更高。

我只是在谈论协议级别的复制。实际上，还有另一种方法可以在块级别复制数据。它不关心上层，只需要保证数据在磁盘层面的复制。当然，这种方法很少使用。说完复制，我们来说说切换。事实上，MySQL官方此前并没有提供自动检测和转发故障的能力，主要依靠第三方工具来实现。

首先是Keepalives。 Master和Slave互相检测并始终询问对方的生存状态。如果出现网络抖动或网络问题，可能会出现脑裂问题，导致两个主设备和数据写入错误。另一种方法是MMM方法。 M1M2互为主备，并加一个冗余节点。从图片上看，虽然是双主模式，但是该模式下一次只能有一个节点进行写入。如果检测到主写节点出现故障，则将 VIP 切换到另一个主节点。总的来说，这种方法比较老，问题也比较多。第三种是MHA，应用广泛。该方法由复制组和管理节点组成。每个复制组至少由三个数据节点组成。监控代理部署在数据节点上，定期向管理节点汇报。如果主节点出现问题时，管理节点决定是否切换到子节点。腾讯云自己实现了bug检测套件。结构如右图所示。监控节点具有高可用性保证检测和切换故障。另外，我们目前正在对MySQL进行高可用改造，可以实现30秒内故障检测和恢复，大大提高了高可用。

我们来谈谈集群高可用架构。其中最著名的是PXC、MGC和MGR。 PXC和MGC具有相似的结构。 MGR是官方提供的具有故障转移功能的高可用性架构。一般层次结构如下。 MGR 可作为插件使用。 MGR主要改变复制协议。由于 MGR 支持多任务处理，因此这里的另一个重点是冲突检测。如果多个节点同时写入相同的主键，那么根据哪个优先？ MGR使用基于Paxos协议的冲突检测。接下来，我们粗略地看一下结构。 MGR 支持写入多个节点，即多活动。支持节点故障后自动移除，恢复后自动加入集群。该图演示了 MGR 数据流背后的逻辑。该图显示了形成最小 MGR 集群的三个节点。假设DB1有写请求。在准备阶段，MGR插件生成一个名为WriteSet的集合并将其传递给其他节点。此 WriteSet 集合包含这次呈现的 binlog 和更新的唯一键。该唯一键由数据库名称、表名称和主键组成。在这里您可以看到 MGR 有一个限制。表必须有主键，否则无法检测到冲突。我们再谈谈吧。当节点收到此信息时，它会进行比较。每个节点都有一个缓存来存储当前的同步状态，即唯一键对应的GTID SET。比较后，将结果返回给DB1。只要超过一半的节点返回OK并且可以呈现，DB1就执行binlog下载操作，然后返回OK给客户端。其他节点写入中继日志，然后进行重放操作。如果大多数节点返回冲突，则 DB1 执行回滚，其他节点删除复制的 binlog。

其实PXC和MGC的思路是类似的。可以说，MGR 借用了它们，因为 PXC 和 MGC 出来得比较早。在这里，它们是相似的。主节点发送WriteSet写集，发送后验证并做出决定。

最后说一下NewSQL的高可用架构。首先，感谢 AWS 孵化了 Aurora，这是一个非常出色的 NewSQL 产品。那么极光是怎么产生的呢？这与AWS数据库架构有关。我们来看看这张照片。 AWS数据库构建在虚拟机和云盘上。我们都知道MySQL有很多日志，所以很多IO都是通过网络执行的，需要时间。这就是AWS有这种网络架构的原因。 IO是它的瓶颈，性能无法提升。基于此，我们来认识一下Aurora。

Aurora 是一种计算与存储分离的架构——典型的共享磁盘结构。基础存储使用 6 个副本，并用于三个不同的 AZ。这样可以保证即使一个AZ出现故障或者最多两个AZ丢失一份，数据也不会丢失，业务也能正常服务。Aurora 的理念是“日志就是数据库”。它彻底改变了MySQL存储层，去掉了很多LOG，只留下Redlog，并且具备将redlog转换为Innodb页面的能力。这样，Aurora声称可以减少至少85%的IO。另外，下沉到存储节点进行备份和回滚，使备份和恢复更快、更有保障。极光的整体感觉比较质朴，价格也比较低。

另一个是阿里云的Polar。它的概念与AWS不同。阿里云认为，未来的网络不是问题。未来的网络可能会接近总线质量，因此构建在RDMA网络的计算机空间中。日志方面大动作较少，保证了MySQL社区后期的新功能可以快速使用。 Polardb也是共享磁盘架构，其存储节点通过ParallelRaft协议保证数据完整性。可见它也是一个很棒的架构，但是它的成本比较高。

我们腾讯云自己的NewSQL正在开发中，但还没有正式上线。我们的名字是 CynosDB。相比之下，我们的理念是同时考虑两者。未来，我们将在新的大型网络硬件的核心实现中实现更高的性能、更可靠的服务和更高的可用性。请拭目以待。

王家琨，腾讯高级工程师、腾讯云关系型数据库MySQL负责人，拥有多年客户及数据库研发经验。拥有丰富的IOS客户端、MySQL、PostgreSQL、SQL Server等产品的研发和产品规划经验。