mysql适合金融行业_金融级MySQL高可用方案选型

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

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

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

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

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

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

1.1 一致性vs性能

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

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

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

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

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

1.2 一致性vs连续性

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

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

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

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

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

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

二. 高可用覆盖的故障

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

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

2.1 硬件故障

硬件故障可能是可恢复的, 也可能不可恢复. 由于无法全面且准确地预测硬件故障的发生时间/发生种类/产生的影响等, 一般对硬件故障的检测方法如下：

- 对可预测的硬件故障进行故障检测/预防性检测

- 检测由高层应用抛出的错误

什么意思呢，无法预测？那要我们高可用软件做什么？别急！大家考虑一下，如果我们要检测一个硬件故障，大致的思路其实是有的，无非就是去检测硬件的错误码，回头想想，光磁盘的供应商何其多，如果要把兼容性做齐，这个工程量可想而知；所以我们的结论是预防大于治疗。

比如电源故障我们要上备用电池(BBU)，磁盘做Raid，网卡做Bond等等一系