返回 登录
0

选择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
  • 幸存的重新启动  
    • 如果节点是关机重启或其他此类过程,对系统管理员很有帮助 
    • 正常关机正确设置 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来减少网络流量。

结论

做出正确的选择取决于:

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

原文:Choosing MySQL High Availability Solutions (译者/孙思)

评论