金融级MySQL高可用方案选型.pdf

金融级 MySQL 高可用方案选型 背景 市面上关于 MySQL 高可用方案五花八门：Keepalived，3M，MHA，甚至通过负载均 衡，proxy 中间件等等方案来实现。那么怎么来对这些选型做评判呢？ 本文将围绕下面的主线逻辑进行探讨： 1. 高可用的考量：为什么选型这种高可用方案，需要有什么标准来考量？ 2. 高可用覆盖的故障：高可用要处理哪些层级的故障，不同故障场景下，考量的适用度 是多少？ 3. 高可用的选型：有了故障场景，有了考量标准后，探讨如何选型？ 一. 高可用的考量 在讨论高可用考量之前我们来看一个简单的高可用架构模型（下图）；这个模型很简单，有 一个 HA 的工具去检测主从状态，发现主实例异常后，就发生故障切换，切换前可能还需要 做一些提升（Promote）的操作，比如数据补全，最后才绑定服务 IP （ServiceIP），对外 提供流量。 1.png 上面的模型是一个比较经典的高可用模型，用过高可用的同学应该能对号入座，没用过的同 学会对高可用有一个基本的印象。 有了对高可用功能的简单刻画，我们回到本章正题，来探讨高可用的考量；熟悉 Oracle 的 同学，应该都知道Oracle 的 Data Guard。DG 是 Oracle 推出的一种针对 Oracle 数据库 的高可用性数据库方案。它有三种工作模式： 最大性能，最大可用，最大保护。所以针对 MySQL 的高可用性考量，那么我们同样定义了类似的标准： 1. 数据一致性。通过不同的高可用保障方式（异步／同步复制）实现主库发生切换时， 数据零丢失。 2.业务连续性。业务连续性是指数据库的消费者(业务),是否可以一直访 问和使用数据库。在发生主备切换时,数据库的业务连续性会受到多长时间的影响。 2. 数据库性能。由于主备上至少存有两份数据,与只有一份数据相比,主数据库承担业务压 力的能力可能会受到影响，需要做好性能平衡。 到这里，似乎我们得到了一套高可用的考量标准，我们的问题马上又接踵而至。 1.1 一致性vs 性能 1. 一致性优先，全同步，数据 slave 提交后，master 再提交 2. 性能优先，异步，master 直接提交，slave 异步复制 问题 1：如何平衡一致性和性能？ 1.2 一致性vs 连续性 1. 数据一致性优先时,将尽可能补偿数据,补偿数据阶段花费的时间将较长,在补偿数据期 间业务将不能访问; 2. 业务连续性优先时,将在规定时间 t 内补偿数据,达到规定时间 t 后,放弃未补偿的数据, 保证业务最多只中断 t 时间 问题 2 ：如何平衡一致性和连续性？ 上面的两个问题我们暂且卖个关子，到高可用选型的章节里在给大家展开探讨！ 二. 高可用覆盖的故障 上一章我们谈论了高可用的考量，这一节我们要探讨高可用要处理哪些层级的故障，不同故 障场景下，考量的适用度是多少？ 故障检测的目的是保证某一节点故障时, HA 能及时获得通知, 并开启修复或切换任务。节点 故障包括由硬件故障, 网络故障，操作系统故障, 被监控软件故障, 或监控软件的故障引起的 节点状态异常或失去响应。 2.png 2.1 硬件故障 硬件故障可能是可恢复的, 也可能不可恢复. 由于无法全面且准确地预测硬件故障的发生时 间/发生种类/产生的影响等, 一般对硬件故障的检测方法如下： • 对可预测的硬件故障进行故障检测/预防性检测 • 检测由高层应用抛出的错误 什么意思呢，无法预测？那要我们高可用软件做什么？别急！大家考虑一下，如果我们要检 测一个硬件故障，大致的思路其实是有的，无非就是去检测硬件的错误码，回头想想，光磁 盘的供应商何其多，如果要把兼容性做齐，这个工程量可想而知；所以我们的结论是预防大 于治疗。 比如电源故障我们要上备用电池（BBU），磁盘做 Raid，网卡做Bond 等等一系列的运维 规范。那么无非防范的其他的硬件故障，我们依赖于高层应用的抛错来检测，比如系统报错 disk read only ，MySQL abort server 等等。 PS：高可用是一个运维体系，除了高可用软件，还需要配套运维规范；这也是为啥DBA 年 限越久价值越大的一种体现吧！ 2.2 网络故障 网络故障也可以细分成以下几类。 2.2.1 网络不可用 网络不可用指较长时间网络通路不可用, 可通过节点间心跳来检测. 2.2.2 网络闪断 网络闪断指较短时间内网络在可用和不可用状态间震荡. 可将心跳检测的超时时间设为能容 忍的网络闪断的最长时间