MYSQL 到底什么是好的高可用,与费尽心机

近一直在做公司整体数据库的灾难恢复的演练的组织工作，手下的几个DBA也是忙的不亦乐乎（真的乐的起来起不来我就不知道了）。

各种数据库的高可用方法不少，从MYSQL 的 innodb cluster ,PXC, MHA , 到PG 的 pacemaker corosync, patroni , repmgr ， 每种数据库都有那么几种。这就陷入一个有意思的问题中, 到底使用的数据库的高可用那种好,应该用那种更好.

这就需要讨论讨论了, 个人认为没有更好,只有更适合. 我们罗列一下高可用中需要注意的地方. 在确认你使用的数据库的种类后, 我们罗列一下这个数据库可以使用的高可用的方式,这里以MYSQL 为例

1  甲骨文公司主推的方式  innodb cluster 

2  Percona xtradb

3  MHA + GTID + MYSQLBINLOG  SERVER

4  MHA + 非GTID的方式

5  现在还有人提的  MASTER MASTER

6   其他

这么多高可用的方式,那种是你公司应该用的,首先先问几个问题,在来选择,而不是脑子一热,选一个"坑".

1   你的硬件环境的问题

这是一个非常重要的环节,有的公司的数据库下层是基于 云的环境的, 硬件的可用性很高,基本上很少出现问题, 但有的公司不是 ,三天两头的出问题, 硬件不稳定, 什么都是白费.

2   你整体的软件层一贯的设计风格

这也是一个非常重要的环节, 如果你公司的开发人员都知道 例如设计表的时候想着尽量在日后的查询中少 JOIN , 并且甚至控制事务的大小,在查询中基本不去使用例如  group by , order by  ,  分页的时候知道通过主键+ limit 的方式来去分页,那么你距离高可用方式的选择的自由会更近一些.

3   整体业务层业务逻辑的问题

估计说到这里,会被质疑, 那我来解释一下,如果你设计的高可用,对应的业务本身就不搭,那么后续的使用也会是满满的坑, 举例您的业务,并发低,使用率低,与业务并发高, 对于故障恢复的严苛性高的两种业务对比,这终会影响你选择高可用的方式

4  技术成熟度的问题

一项技术,使用的人越多,越能发现其中的问题,所以在选择一项技术的时候,这项技术的热度也是一个需要考虑的问题, 如果技术偏门,相关遇到异常方式中处理问题的方案少, 使用的单位少,等等 这对以后使用这项技术如何进行快速处理都是问题.

下面我们可以举例,一些不匹配的情况

1   硬件稳定性无法保证, 网络稳定性无法保证的情况下, MYSQL的高可用架构选择了  PXC , innodb cluster 的情况下, 那么在发生网络不稳定,和抖动的情况下, 那么集群很可能因此而解体, 同时如果公司使用的虚拟机,并且将类似这样的技术的集群,放置在一台物理机基础上的虚拟机后, 则在物理机DOWN掉后,在恢复硬件的情况下, 这个集群很可能就很难快速恢复了.  所以硬件的稳定性,对于数据库的高可用的架构设计是有至关重要的作用的,无法被忽视.

2   软件设计的问题, 很难想象一群以ORACLE 数据库为主的软件设计编程人员,能很快的理解 MYSQL中的事务的大小控制, 在UPDATE 的时候控制一次的UPDATE的行数,需要进行限制,等等一系列每个数据库自有的特性和注意事项,如果此时使用 PXC ,那么推过来一个大事务将对于这类的MYSQL的架构是危险的,并且在出现问题后,具有灾难性. 

3   业务的问题, 在数据库集群出现问题后,如何快速的拉起数据库,维持业务的继续性, 在我们这次操作中,有些数据库的确有问题,例如三台机器,两台出现故障后,单独一台无法从集群中解除,无法恢复单机工作,这对于核心业务,以及要求快速恢复的数据库服务的要求下, 这样的架构就需要考虑是不是应该被使用在这个环境中来满足严苛的业务属性了.

4   技术成熟度的问题,任何一项技术都会有从兴盛到衰败的情况,哪怕是我们认为的某些神话类的数据库如ORACLE ,他也是有技术的兴盛到衰败的过程,所以不能迷信任何一种技术, 那么技术的成熟度本身就需要进行一个分析和考量,例如MHA ,一项成熟的不能在成熟的技术,目前MYSQL的高可用中大部分企业还是在使用MHA这项技术, 但这项技术早早晚晚是要被淘汰的, 原因很多,例如在使用 GTID的情况下你的binlog server 的设置就成为一个问题, 

1  将binlog server 放置到一个独立的服务,那么产生的问题是,如果这个服务器DOWN了,那么我们的MHA 的切换服务就终止了

2   将binlog server 放置到 主库, 那么主库如果是MYSQL的服务DOWN 则

可以进行切换,但如果是主机DOWN ,则MHA 无法进行切换

3  将binlog server 放置到指定的从库, 则可以满足大部分情况中的高可用切换,但在这台SERVER DOWN 后,MHA 也是失效的状态.

所以即使是MHA 这样成熟的技术,也会有很多的选择和其中的问题. 现在您还觉得一项高可用技术的选择有那么简单和容易吗? 

终到底那些是好的MYSQL的高可用架构

1   如果您的公司硬件网络基础好,并且开发的素质高, INNODB CLUSTER 是好的选择,这是未来的MYSQL的方向

2   如果您的硬件网络基础不怎么好,开发的素质一般, MHA + MYSQL 是一个好的选择,当然如果您这边想进一步,则 MHA  + GTID + MYSQL + 在从库进行BINLOG SERVER的设置是一个好的方法

3   如果您的业务稳定,并发小,读多写少,开发的素质高,硬件网络基础好,需要多节点的一致性, PXC 是一个好的选择

4  如果不想使用VIP 虚拟IP 飘来飘去, PROXYSQL 作为以上结构中的中间件是一个好的选择.