本文为一篇博客的翻译（文末有原文链接），略有删减。

在这篇博客当中我们将着眼于MySQL的高可用解决方案，并检查它们各自的优缺点。

高可用性环境为必须保持可用的数据库提供了大量的好处。高可用性数据库环境在多台机器上共同定位数据库，其中任何一个可以承担数据库的功能。这样，数据库就没有“单点故障”。

有很多高可用的策略和解决方案，那如何从众多的选择中挑选最合适的方案呢。第一个需要思考问题是”你想解决的问题是什么？”，答案归结为冗余、扩展和高可用。在不同的场景下，你的答案也会不同：

• 发生灾难时需要多个数据副本
• 需要提升读(或)写的吞吐量
• 需要将数据库服务的停机时间降到最低

当你正在规划你的数据库环境，很重要的一点就是谨记并应用CAP定律。CAP定理将问题分成三个类别:一致性、可用性和分区容错性。从这三个你可以选择任意两个,代价就是损失第三个。

• 一致性： 所有的节点在同一时间看到的数据相同
• 可用性： 对每个请求进行相应其成功与否
• 分区容错性： 在任意一个分区出现网络故障时，系统可以继续运转

无论选择哪种解决方案，都要尽可能的保证数据的一致性。问题是,虽然MySQL复制是极好的,它本身并不能保证所有节点的一致性。因为failover或者其他原因，事务可能会丢失，所以总有潜在的数据不同步的可能性。基于Galera的集群，如Percona XtraDB集群是基于认证的，以防止这种情况！

数据丢失

你应该问自己的第一个问题就是“我能容忍丢失数据吗？”

这通常取决于应用程序。 应用程序应检查事务的状态代码，以确保它们已提交。但很多不会！ 也可能在failover期间丢失事务。 在failover期间，简单的复制方案可能会丢失数据。

节点数据不一致是另一个问题。 没有冲突检测和解决方案，节点的数据不一致是不可避免的。 一个解决方案是经常运行pt-table-checksum来检查复制节点的不一致的数据。 另一个选择是使用基于Galera的分布式集群，如具有认证流程的Percona XtraDB集群。

避免单点故障

什么在监控你的系统？或者是什么准备准备干预失败呢？针对复制,看看MHA和MySQL Orchestrator。两者都是在复制环境中用来执行failover极好的工具。

对于Percona XtraDB集群,故障转移通常会更快,但它并不是一个可以应对所有场景的完美的解决方案。

我能容忍丢失事务吗？

许多MySQL DBA担心将innodb_flush_log_at_trx_commit设置为1以符合ACID并且开启sync_binlog，但是他们使用复制却不进行一致性检查！这在逻辑上是一致的吗？ Percona XtraDB集群通过认证保持一致性。

冲突检测与解决方法

所有的解决方案都必须有一些冲突检测和解决方案。Galera的认证过程遵循以下方法:

• 事务在一个节点上持续正常，直到达到COMMIT阶段
• 数据变更会被收集到写入集合(Write-Set)中
• Write-Set被发送到所有的节点进行认证
• 使用PK来判定Write-Set是否可用
• 如果认证失败，丢弃Write-Set，并进行事务回滚
• 如果认证成功，提交事务，并将Write-Set应用到所有的节点
• 所有节点将对每个事务达成相同的决策

我想要Failover或者分布式系统吗？

另一个需要重点考虑的因素是你是否应该有一个故障转移或分布式系统。故障转移系统一次运行一个实例，并在发生问题时将“故障切换”到其他实例。分布式系统一次运行多个实例，全部处理不同的数据。

• Failover陷阱：
  • 故障转移系统有一个监视器可以检测到失败的节点，但该节点对在其他地方移动服务可用
  • 故障切换需要时间
• 分布式系统：
  • 分布式系统最小化故障转移时间

另一个问题是你的故障转移应该自动还是手动?

• 手动故障迁移
  • 手动故障转移的主要优点是,人类通常可以做出更好的判断故障转移是否是必须的
  • 系统很少得到它的完美，但他们可以接近！
• 自动故障迁移
  • 更短暂的服务中断时间
  • 无需等待DBA介入

另一个问题是故障发生后Failover的速度有多快？显然，Failover的速度越快，潜在数据丢失的时间就越短。

• Replication / MHA / MMM
  • 取决于在发生故障转移之前待处理的Replication事务完成所需的时间
  • 通常需要30s
• DRBD
  • 通常15s至30s之间
• Percona XtraDB Cluster / MySQL Cluster
  • 非常快的故障转移。通常小于1秒，取决于负载均衡器

你需要多大比例的服务可靠性的保证（多少个9）？

“9”精度测量是系统可靠性的标准。 当谈到“有多少9”时，每个9都是一个数量级更准确的。 99.99是四个九，99.999是五个九。

每一个管理者应对多少个’9’的问题始终是”尽可能多”。听起来不错，但事实是需要权衡！ 许多应用程序可以容忍几分钟的停机时间，并且影响很小。下表显示与每个“9”相关的停机时间：

我是否需要衡量reads and/or writes?

了解你的环境时，了解你的工作负载很重要。你的工作量在读取，写入还是两者都很重？ 知道你是否需要扩展读取或写入，这对于选择HA解决方案很重要：

• Scaling reads
  • 大多数解决方案提供从多个节点或副本读取的能力
  • MHA, Percona XtraDB Cluster, MySQL Cluster等都是非常适合的
• Scaling writes
  • 许多人错误地尝试通过向Percona XtraDB Cluster中的多个节点写入来进行扩展，导致冲突
  • 另一些人尝试使用M-M复制，这也是有问题的
  • 在这方面MySQL集群可能是最好的解决方案

如何配置新节点？

• Replication
  • 很大程度上,这是一个手动过程
  • 使用MySQL Utilities工具会更简单
• 分布式集群
  • Percona XtraDB Cluster和MySQL Cluster使其变得异常简单
  • Percona XtraDB Cluster使用状态传输(SST或者IST)来自动执行集群节点的进程

我有多少个数据中心？

了解你的环境中包含多少个数据中心是一个关键因素。 运行多个数据中心对你选择HA解决方案有影响。

如果我只有一个数据中心怎么办？ 你可以针对单个(或多个)故障节点增加保护，具体取决于群集大小。 如果你有两个数据中心，那么你应该将第二个数据中心作为DR解决方案。 拥有三个或更多数据中心时最强大的解决方案是使用基于Galera的集群。

我需要什么样的存储引擎？

特别是现在有许多可用于数据库环境的存储引擎。 在你的HA解决方案里应该使用哪一个存储引擎？ 你的HA解决方案将有助于确定你可以使用哪个存储引擎。

• 不依赖存储引擎：所有的存储引擎都适用
• Percona XtraDB Cluster：要求是InnoDB。 对MyISAM的支持是实验性的，不应该在生产中使用
• MySQL Cluster： 依赖NDB引擎

负载均衡

负载均衡器提供了一种在你的环境资源中分配工作负载的方法，以免在任何节点产生性能瓶颈。 以下是一些负载平衡选项：

• HAProxy
  • 开源软件解决方案
  • 无法实现读写分离。如果有这种需求，需要在应用程序中实现
• F5 BigIP
  • 典型的硬件解决方案
• MaxScale
  • 可以实现读写分离
• Elastic Load Balancer (ELB)
  • Amazon的解决方案

我的应用程序是否需要高并发？

新的复制方法允许并行线程（Percona XtraDB Cluster从一开始就拥有了这一点），如多线程复制（MTS）。 MTS允许slave节点具有多个SQL线程，每个线程都有自己的relay log。 通过Percona XtraBackup进行备份时，开启GTID会更加安全，因为无法信任SHOW SLAVE STATUS来获取中继日志位置。

我对内存的使用有限制吗？

一些分布式解决方案，如MySQL Cluster，即使使用基于文件的表，也需要大量的内存。一定要适当地规划。 XtraDB集群的工作原理更像一个独立的节点。

我的网络有多稳定？

网络永远不会达到100％可靠性。 一些“网络问题”是由于外部因素，如系统资源争用（特别是虚拟机）。 网络问题导致不当的故障转移问题。在Percona XtraDB集群中使用局域网段，以最大限度地减少跨WAN的网络流量。

结论

做出正确的选择取决于：

• 弄清楚你真正需要的是什么
• 清楚你的选择
• 了解自身的限制
• 了解所选解决方案段优缺点
• 设定正确期望值！

参考资料

Choosing MySQL High Availability Solutions