在这篇文章中，我们将看到不同的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集群，尝试每件事物有三个。如果你跨越数据中心，它有三个数据中心。如果你的节点是在一个交换机上，尝试有三个交换机。
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
- 幸存的重新启动
- 如果节点是关机重启或其他此类过程，对系统管理员很有帮助
- 正常关机正确设置 seqno
需要能够读取后写入吗？
异步复制跨节点并不能保证数据的一致视图。XtraDB集群提供了因果读取。副本将等待该事件用于处理其他查询，保证一致的跨节点读取状态。
如果做很多数据加载呢?
在过去，这是传统的智慧，在这样的场景中使用复制的XtraDB集群。MTS对数据分布在多个模式下有所帮助，但不适合所有的情况。XtraDB集群现在是一个可行的选择，因为我们发现了一个错误，在Galera不能正确地拆分大事务。
对Split Brain采取预防措施
脑裂发生在集群的节点划分，通常由于网络信号，其会形成两个或两个以上的节点新的和独立的集群。XtraDB集群配置进入无主状态，并拒绝接受。一个更新的设置与XtraDB集群将允许脏读取非主节点
我的应用程序需要高并发吗？
新方法来复制允许并行线程(XtraDB集群已经开始)，如多线程服务器(MTS)。MTS允许复制多个SQL线程都有自己的中继日志。由于无法信任SHOW SLAVE STATUS获得中继日志位置，它通过Percona XTRABackup安全使GTID备份。
有限的内存？
一些分布式解决方案比如MySQL集群需要大量的内存，即使基于文件表。一定要适当地计划。XtraDB集群工作更像是一个独立的节点。
我的网络有多稳定？
网络是没有100%的可靠。一些“网络问题”是由于外部因素导致的，如系统资源争用(特别是在虚拟机)。网络问题导致不恰当的故障转移问题。使用局域网段XtraDB集群跨WAN来减少网络流量。
结论
做出正确的选择取决于：
- 知道你真正需要的！
- 知道你的选择。
- 了解你的约束！
- 了解每种解决方案的优缺点。
- 设置正确的期望值！
（译者/孙思）
