选择MySQL高可用性解决方案

在这篇文章中，我们将看到不同的MySQL高可用性解决方案，并且检查它们的优势与不足。

高可用性环境为数据库必须保持可用性提供大量的好处。高可用性数据库环境是跨多台机器共同部署的一个数据库，其中任何一个都可以假定数据库的功能。通过这种方式，数据库将不会有“单点故障”。

这儿有很多HA策略和解决方案，那么如何在无数选项中选择最好的解决方案。首先你要考虑的第一个问题是：你要解决的问题是什么？答案归结为冗余、扩展和高可用性，这些并不一定都一样！

• 在灾难事件中需要数据的多个副本
• 需要增加读/写的吞吐量

• 必须尽量减少停机时间

  

当你规划你的数据库环境时，你重要的是要记住CAP定理的应用。CAP定理将问题分成三个类别：一致性、可用性和分区容忍性。从这三个中，你可以选择任意两个，并牺牲第三个。

• 一致性。所有节点同时看到相同的数据。
• 可用性。每个请求不管成功或者失败都有响应。
• 分区容忍性。尽管任意分区会导致网络故障，但系统仍继续运作。

无论你选择何种解决方案，它应该最大限度的保持一致性。问题是，虽然MySQL复制是伟大的，它本身并不能保证所有节点的一致性。总有潜在的数据不同步，因为事务可能会在故障转移中丢失或由于其他原因。Galera-based集群如Percona XtraDB集群是以认证为基础，来防止这种情况发生！

数据丢失

你应该问自己的第一个问题是：我能承受丢失数据吗?

这通常取决于应用程序。应用程序应该检查事务中的状态码，以确保他们数据不丢失。然而，很多人却不这样！那么，后果是它有可能在故障转移期间丢失事务。在故障转移时，简单的复制方案会有丢失数据的可能性

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

避免单点故障

看你的系统是什么？或者是任何站准备干预失败？对于复制，看看MHA和MySQL协调器。两者都是来执行一个副本故障转移的伟大工具。还有其他。
　　　　
对于Percona XtraDB集群，故障转移通常更快，但它并不是适用于每个案例的完美解决方案。

我能承受丢失事务？

很多MySQL DBA担心设置innodb_flush_log_at_trx_commit到1为ACID Compliance和sync_binlog，但使用复制没有一致性检查！这在逻辑上是一致的吗？通过认证Percona XtraDB集群保持一致性。

冲突检测与解决方案

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

• 事务继续作为正常节点，直到达到提交阶段。　　
• 更改收集到一个writeset中。　　
• Writeset发送到所有节点进行认证。　　
• PKs是用来确定writeset是否可以应用。　　
• 如果认证失败，writeset下降，事务回滚。　　
• 如果它成功，事务提交和writesets被应用到所有的节点。　　
• 所有的节点将在每一次事务中都会做出同样的决定，因此确定。

我想做故障转移或分布式系统？

另一个重要考虑因素是是否应该有一个故障转移或分布式系统。故障转移系统在一段时间内运行一个实例，并且当出现问题时，“故障转移”将到另一个实例中。一个分布式系统在同一时间内运行多个实例，并且处理不同的数据。

• 故障转移陷阱：　　　　
  
  • 故障转移系统监控检测失败的节点和移动服务在其他地方是否可用　　
  • 故障转移需要时间！
• 分布式系统：
  
  • 分布式系统最小化故障转移的时间

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

• 利用手动故障转移
  
  • 手动故障转移的主要优点是，人类通常可以做出更好的决定是否有必要做故障转移。　　
  • 系统很少能让它完美，但他们可以关闭！
• 利用自动故障转移
  
  • 更多的9由于最小化中断
  • 不需要等待一个DBA执行

进一步的问题是如何快速使故障转移发生？显然，它发生的速度越快，潜在数据丢失的时间就越少。

• 复制/MHA/MMM
  
  • 取决于需要多长时间来等待副本事务完成之前发生故障转移　　
  • 通常约30秒
• DRBD
  
  • 通常15至30秒
• XtraDB集群/ MySQL集群
  
  • VERY 快速故障转移。通常小于1秒取决于负载均衡器

你有多少9是真的需要的？

“9”测量的精度是为了如何完善系统的一个标准。当涉及到“多少个9”，“每个9的数量级是更准确的。99.99是4个9，而99.999是5个9。

每个管理者一直都会回答多少个9的问题，“尽我所能。“这听起来不错，但现实是需要权衡！许多应用程序可以忍受几分钟的停机时间。下面的表显示了对每个9相关的宕机时间 ︰

我需要进行大规模的读和/或写操作？

当在看你的环境时，重要的是要了解你的工作负载。到底你的工作量沉重的原因是由于读取还是写入或者二者都有？选择你的HA解决方案，最重要的是要知道你读取或写入的规模：

• 规模读取
  
  • 大多数解决方案提供从多个节点读取或副本的能力　　
  • MHA，XtraDB集群，MySQL集群和其他都非常适合
• 规模写入
  
  • 很多人错误地通过写入 XtraDB Cluster 中的多个节点来尝试规模写入，最终导致冲突
  • 其它人尝试主主复制也是有问题的　　
  • 这一点可能是关于MySQL集群最好的解决方案

配置新节点呢？

• 复制
  
  • 很大程度上，这是一个手动过程
  • MySQL工具使这比以往更容易
• 分布式集群
  
  • XtraDB集群和MySQL集群使这更容易
  • XtraDB集群使用状态传输(不锈钢或IST)到自动化集群节点的过程

万事皆三

XtraDB集群，尝试每件事物有三个。如果你跨越数据中心，它有三个数据中心。如果你的节点是在一个交换机上，尝试有三个交换机。
　　　
XtraDB集群至少需要三个集群中的节点。由于投票的原因奇数是首选。忘掉在故障期间试图与只有两个数据中心保持群集。你最好做一个DR网站。试图通过在两个数据中心来忘记自定义权重。

有多少数据中心?

知道有多少数据中心参与你搭建的环境是一个关键因素。运行多个数据中心会影响你采用 HA 解决方案。

如果我只有一个数据中心呢？你可以获得保护单个失败的节点或者更多，这取决于集群大小。如果你有两个数据中心，你或许应该考虑作为DR解决方案的第二个数据中心。当使用Galera-based集群如XtraDB集群时，有三个或更多的数据中心是最健壮的解决方案。

如何进行故障恢复计划？

灾难恢复计划在HA环境中是至关重要的。确保DR节点(s)可以处理交通，即使在最小的性能水平。

• 从XtraDB集群复制到一个DR网站　　
  
  • 异步复制从XtraDB集群到单个节点　　
  • 异步复制从XtraDB集群复制拓扑　　
  • 从集群XtraDB异步复制到另一个XtraDB集群

需要什么存储引擎？

尤其是现在，还有大量的存储引擎可用于数据库环境。为了你的HA解决方案，你应该使用哪一个？你的解决方案将帮助你确定可以使用哪些存储引擎。

• 不依赖于存储引擎。适用于所有的存储引擎
• XtraDB集群。需要InnoDB。支持MyISAM 是实验性的，并不应在生产中使用
• MySQL集群。需要NDB存储引擎

负载平衡器的选择

负载平衡器提供了一种手段，将你的工作量分布到您的环境资源中去，以免在任何一个特定点造成瓶颈。以下是一些负载平衡选项：

• HAProxy 　　
  
  • 开源软件解决方案　　
  • 不能读和写。如果这是一个前提，这个应用程序需要去使用它！　
• F5 BigIP 　　
  
  • 典型的硬件解决方案　　
• MaxScale 　　
  
  • 可以读/写拆分　　
• 弹性负载均衡器(ELB)

如果群集重新启动，会发生什么?

为了更改应用，某些更改要求集群被重新启动。例如，更改参数组的参数值仅适用于群集后重新启动的群集。群集可能也由于电源中断或其他技术故障而重新启动。由于电源中断或其他技术故障，集群也可以重新启动。

• 断电在单个数据中心可能会导致问题　　
  
  • XtraDB集群为自动启动可以进行配置　
  • 在所有节点同时失去权力时，可能不总是工作。当服务器正在运行时，grastate.dat文件显示了序号 1
• 幸存的重新启动　　
  
  • 如果节点是关机重启或其他此类过程，对系统管理员很有帮助　
  • 正常关机设置正确的序号

需要能够读取后写入吗？

异步复制跨节点并不能保证数据的一致视图。XtraDB集群提供了因果读取。副本将等待该事件用于处理其他查询，保证一致的跨节点读取状态。

如果做很多数据加载呢?

在过去，这是传统的智慧，在这样的场景中使用复制的XtraDB集群。MTS对数据分布在多个模式下有所帮助，但不适合所有的情况。XtraDB集群现在是一个可行的选择，因为我们发现了一个错误，在Galera不能正确地拆分大事务。

对Split Brain采取预防措施

脑裂发生在集群的节点划分，通常由于网络信号，其会形成两个或两个以上的节点新的和独立的集群。XtraDB集群配置进入无主状态，并拒绝接受。一个更新的设置与XtraDB集群将允许脏读取非主节点

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

新方法来复制允许并行线程(XtraDB集群已经开始)，如多线程服务器(MTS)。MTS允许复制多个SQL线程都有自己的中继日志。由于无法信任SHOW SLAVE STATUS获得中继日志位置，它通过Percona XTRABackup安全使GTID备份。

有限的内存？

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

我的网络有多稳定？

网络是没有100%的可靠。一些“网络问题”是由于外部因素导致的，如系统资源争用(特别是在虚拟机)。网络问题导致不恰当的故障转移问题。使用局域网段XtraDB集群跨WAN来减少网络流量。

结论

做出正确的选择取决于：

• 知道你真正需要的！　
• 知道你的选择。　　
• 了解你的约束！　
• 了解每种解决方案的优缺点。　
• 设置正确的期望值！

原文：Choosing MySQL High Availability Solutions （译者/孙思）