金融系统 mysql_金融级MySQL高可用方案选型

原标题：金融级MySQL高可用方案选型

背景

市面上关于MySQL高可用方案五花八门：Keepalived，3M，MHA，甚至通过负载均衡，proxy中间件等等方案来实现。那么怎么来对这些选型做评判呢？

本文将围绕下面的主线逻辑进行探讨：

1.高可用的考量：为什么选型这种高可用方案，需要有什么标准来考量？

2. 高可用覆盖的故障：高可用要处理哪些层级的故障，不同故障场景下，考量的适用度是多少？

3. 高可用的选型：有了故障场景，有了考量标准后，探讨如何选型？

一. 高可用的考量

在讨论高可用考量之前我们来看一个简单的高可用架构模型(下图)；这个模型很简单，有一个HA的工具去检测主从状态，发现主实例异常后，就发生故障切换，切换前可能还需要做一些提升(Promote)的操作，比如数据补全，最后才绑定服务IP(ServiceIP)，对外提供流量。

上面的模型是一个比较经典的高可用模型，用过高可用的同学应该能对号入座，没用过的同学会对高可用有一个基本的印象。

有了对高可用功能的简单刻画，我们回到本章正题，来探讨高可用的考量；熟悉Oracle的同学，应该都知道Oracle的Data Guard。DG是Oracle推出的一种针对Oracle数据库的高可用性数据库方案。它有三种工作模式： 最大性能，最大可用，最大保护。所以针对MySQL的高可用性考量，那么我们同样定义了类似的标准：

1. 数据一致性。通过不同的高可用保障方式(异步／同步复制)实现主库发生切换时，数据零丢失。

2.业务连续性。业务连续性是指数据库的消费者(业务),是否可以一直访问和使用数据库。在发生主备切换时,数据库的业务连续性会受到多长时间的影响。

3. 数据库性能。由于主备上至少存有两份数据,与只有一份数据相比,主数据库承担业务压力的能力可能会受到影响，需要做好性能平衡。

到这里，似乎我们得到了一套高可用的考量标准，我们的问题马上又接踵而至。

1.1 一致性vs性能

一致性优先，全同步，数据slave提交后，master再提交

性能优先，异步，master直接提交，slave异步复制

问题1：如何平衡一致性和性能？

1.2 一致性vs连续性

数据一致性优先时,将尽可能补偿数据,补偿数据阶段花费的时间将较长,在补偿数据期间业务将不能访问;

业务连续性优先时,将在规定时间t内补偿数据,达到规定时间t后,放弃未补偿的数据,保证业务最多只中断t时间

问题2：如何平衡一致性和连续性？

上面的两个问题我们暂且卖个关子，到高可用选型的章节里再展开探讨。

二. 高可用覆盖的故障

上一章我们谈论了高可用的考量，这一节我们要探讨高可用要处理哪些层级的故障，不同故障场景下，考量的适用度是多少？

故障检测的目的是保证某一节点故障时, HA能及时获得通知, 并开启修复或切换任务。节点故障包括由硬件故障, 网络故障，操作系统故障, 被监控软件故障, 或监控软件的故障引起的节点状态异常或失去响应。