mysql 高可用 实践_MySQL高可用在网易的最佳应用与实践

今天分享主要包括三方面内容：一是常见的MySQL高可用架构；二是分布式数据库高可用实践；三是基于keepalive的MySQL高可用改造。第一部分会介绍业界一些经典的MySQL高可用解决方案，第二部分和第三部分分别介绍网易在分布式数据库和单节点MySQL上的高可用运维实践。

一、常见的MySQL高可用架构

MySQL高可用主要涉及两个方面，一是客户端如何切换，如何自动failover，二是多个MySQL节点之间如何做数据同步。业界MySQL高可用的解决方案有很多，总结起来有几类：从客户端自动切换的角度来看主要有两类：一类是基于HA同步软件的MySQL高可用，用户通过VIP访问数据库，然后第三方组件监控MySQL的状态，控制VIP的漂移。还有一类是基于API调用的MySQL高可用，把MySQL主从状态维护在客户端，应用程序可以通过API调用控制主从切换，进行数据同步。

MySQL多节点的数据同步方案也有多种，最常用的是基于binlog的数据同步，其次还有基于共享存储的数据同步，以及第三方自己实现的数据同步协议(如Galera)。

1、基于HA同步软件实现的高可用方案

如图所示，基于HA同步软件的MySQL高可用主要是通过VIP作为对外的访问入口，正常情况下VIP绑定在Master上，当Master出现故障后，可以将VIP切换漂移到Slave上。从而实现了一个故障failover的过程。这种基于VIP的高可用方案，最常用的数据同步方式是使用MySQL原生的binlog复制方式，当然，在成本允许的情况下，也可以选择利用SAN之类的共享存储解决方案。我们这边重点介绍的还是binlog复制或者其他软件层次的数据同步方式。

基于HA同步软件的高可用方式的主要特点包括：

结构简单、容易管理；

不支持多写、standby属于备机；

不保证数据一致性；

入侵性小，对用户透明。

2、MHA(Master High Availabitliy)

下面，我们来介绍几种典型的MySQL HA同步软件。在业界应用最为广泛，技术最为成熟的HA同步软件之一是MHA。MHA全称是Master High Availability，是一种一主多从的数据库高可用解决方案。他的特点是在保障高可用自切换的前提下，最大限度的保障主从数据的一致性。

我们先来看下MHA的架构图：

一次完整MHA故障切换流程如下：

保存故障的master节点的binlog日志;

Manager查找最新更新的slave节点；

应用差异的relay log日志到其他的slave；

在slave节点上应用从master保存的binlog日志；

提升一个slave为新的master；

使其他的slave连接新的master进行复制。

3、MMM(Master-Master Replication Manager for MySQL)

除了MHA以外，还有一个老牌的MySQL自动切换套件MMM。

与MHA相比，MMM是基于主主复制的故障切换。也就是不支持从多个slave中选择最新的一个，而是只能切换到特定的主主复制从节点。

4、基于API调用的MySQL高可用

刚才介绍的两种MySQL高可用解决方案，主要都是基于VIP切换的，优点是对应用程序没有入侵，但是缺点是不够灵活，而且系统的可靠性取决于HA软件本身的可靠性。如VIP通知产生问题，或者keepalive进程自己挂了，都可能导致切换出现问题。除了这种解决方案，还有一种是在客户端实现的MySQL高可用 –  基于API调用的MySQL高可用。也就是JDBC或者其他数据库驱动可以自主选择MySQL节点。这种实现方案可能使用的不是特别广泛，但是也有它自身的应用场景，它有如下特点：

架构较重，运维相对复杂

使用灵活，有一定开发成本

支持数据分片、分库分表、读写分离等高级特性

HA-JDBC 就是一种典型的基于API调用的MySQL高可用方案，它可以在应用程序中配置多个MySQL地址，由HA-JDBC实现选主/屏蔽故障节点以及多个应用程序之间的连接状态通知。HA-JDBC可以实现如下功能：

基本的failover

读写分离

节点状态通知

负载均衡

数据同步(先写主，然后同时写多个从节点，如果主写失败，则重新选主，如果从写失败，屏蔽从) 弱一致性。