今天分享主要包括三方面内容:一是常见的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
读写分离
节点状态通知
负载均衡
数据同步(先写主,然后同时写多个从节点,如果主写失败,则重新选主,如果从写失败,屏蔽从) 弱一致性。