MySQL的高可用架构对比分析

数据不丢失

服务持续可用

自动的主备切换

数据库高可用基本要求

SAN(Storage Area Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动MySQL

架构图

1.可以避免存储外的其它组件引起的数据丢失。

2.部署简单，切换逻辑简单，对应用透明。

3.保证主备数据的强一致。

优点:

1.共享存储是单点，若共享存储挂了，则会丢失数据。

2.价格比价昂贵。

3、大并发场景不好扩展

限制或缺点:

共享存储

DRBD(Distributed Replicated Block Device)是一种磁盘复制技术，可以获得和SAN类似的效果。DBRD是一个以linux内核模块方式实现的块级别同步复制技术它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD与SAN类似，也是有一个热备机器，开始提供服务时会使用和故障机器相同的数据，只不过DRBD的数据是复制存储，不是共享存储。

1.切换对应用透明

2.保证主备数据的强一致。

优点：

1.影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。

2.一般配置两节点同步，可扩展性比较差

3.备库不能提供读服务，资源浪费

限制或缺点：

heartbeat（keepalive) + drbd + MySQL

1. 安装配置简单

2. Master故障时，Slave快速切换提供服务，并且对应用透明。

1.需要主备的IP在同一个网段。

2.提供的检测机制比较弱，需要自定义脚本来确定Master是否能提供服务，比如更新心跳表等。

3.无法保证数据的一致性，原生的MySQL采用异步复制，若Master故障，Slave数据可能不是最新，导致数据丢失，因此切换时要考虑Slave延迟的因素，确定切换策略。对于强一致需求的场景，可以开启(semi-sync)半同步，来减少数据丢失。

4.keepalived软件自身的HA无法保证。

heartbeat（keepalive)+主从复制（异步/半同步)

使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

数据一致性

该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。

。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave;

（3）应用差异的中继日志(relay log) 到其他slave;

（4）应用从master保存的二进制日志事件(binlog events);

（5）提升一个slave为新master;

（6）使用其他的slave连接新的master进行复制。

过程

故障切换

2）master故障不会导致数据不一致，当目前的master出现故障时，MHA自动识别slave之间中继日志（relay log）的不同，并应用到所有的slave中。这样所有的salve能够保持同步，只要所有的slave处于存活状态。和Semi-Synchronous Replication一起使用，（几乎）可以保证没有数据丢失。

6）适用于任何存储引擎，MHA可以运行在只要MySQL复制运行的存储引擎上，并不仅限制于InnoDB，即使在不易迁移的传统的MyISAM引擎环境，一样可以使用MHA。

MHA的优势

1.无法保证强一致，因为从故障Master上保存二进制日志并不总是可行，比如Master磁盘坏了，或者SSH认证失败等。

2.只支持一主多从架构，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。

3.采用全局目录数据库方案切换时，需要应用感知变化，因此对应用不透明，因此要保持切换对应用透明，依然依赖于VIP。

4.不适用于大规模集群部署，配置比较复杂。

5.MHA管理节点本身的HA无法保证。

缺点：

DeNA在超过150个MySQL（主要5.0/5.1版本）主从环境下使用了MHA。当mater故障后，MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中，4秒内完成故障切换是不可能的。

DeNA

魅族

生产实例

heartbeat（keepalive)+MHA+半同步复制

GTID(Global Transaction ID)是MySQL5.6引入的功能，可以在集群全局范围标识事务，用于取代过去通过binlog文件偏移量定位复制位置的传统方式。借助GTID，在发生主备切换的情况下，MySQL的其它Slave可以自动在新主上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制位置发生误操作的风险。另外，基于GTID的复制可以忽略已经执行过的事务，减少了数据发生不一致的风险。

3.全局事务ID是怎么生成的？简单来讲是由mysql服务器自动管理的，在mysql5.6以后每一个mysql服务器都有一个全局唯一的ID号叫做uuid，通用唯一识别码 (Universally Unique Identifier)，而GTID就是由当前节点的UUID（一个128位的随机数）和为当前节点生成的随机数（TID）组成的，因此只要UUID不同再在此基础上保证事务ID不同就保证全局不一样了。

4.全局事务ID有何用处？简单来讲GTID能够保证让一个从服务器到其他的从服务器那里实现数据复制而且能够实现数据整合的。GTID在分布式架构中可以保证数据的一致性。从而也实现了mysql的高可用性。

5.GTID相关操作：默认情况下将一个事务记录进二进制文件时将首先记录它的GTID而且GTID和事务相关信息一并要发送给从服务器由从服务器在在本地应用认证但是绝对不会改变原来的事务ID号。

6.因此在GTID的架构上就算有了N层架构，复制是N级架构、事务ID依然不会改变；有效的保证了数据的完整和安全性。

简介

1、更简单的实现failover，不用以前那样在需要找log_file和log_pos。

2、更简单的搭建主从复制。

3、比传统的复制更加安全。

4、GTID是连续的没有空洞的，保证数据的一致性，零丢失。

优势

1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。

2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。

3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

4、如果有记录，说明该GTID的事务已经执行，slave会忽略。

5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

工作原理

不需要重启MySQL服务器.

不需要改变复制拓扑结构.

配置过程在线，整个复制集群仍然对外提供读和写的服务.

更简单的搭建主从复制。

比传统的复制更加安全。

可以在任何结构的复制集群中在线启用GTID功能.

GTID是连续的没有空洞的，保证数据的一致性，零丢失。

GTID在线启用功能的优点

GTID的主从同步复制

先提交到当前节点的write-set内。将write-set改变复制到其他节点。到其他节点后，最关键的一步，用Primary key探测是否有冲突，有冲突就rollback，没有就commit，如果有问题的几点怎么办，把它踢出去。

1、偶数节点时，仲裁者作为一个节点使集群成为奇数，从而避免脑裂

2、它可以请求一个连续的应用状态快照，可用来做备份

复制原理图

真正的多主模式（True Multi-master）：意味着你可以在任意节点读写，适度的规模可以提高集群整体的性能。不会出现主从模式的故障转移（Master-Slave Failover）操作，也不需要VIP。

同步复制（Synchronous Replication）：意味着没有slave lag，没有节点crash的时候出现的丢数据现象(Hot Standby)。并且是Multi-threaded Slave，性能也不错。紧耦合（Tightly Coupled）所有节点数据和状态一致。

自动节点管理（Automatic Node Provisioning）：不需要人工去备份数据库恢复到新节点。

优点

只支持InnoDB，XtraDB

表里面需要有PK：如果没有Primary Key，那不同节点DELETE后，可能顺序不一致，表现在select limit语句在不同节点可能返回不一致。

不支持LOCK和UNLOCK语句，也不支持GET_LOCK()和RELEASE_LOCK()函数。

查询日志不能存到表里，只能存文件。

缺点

官网推荐采用状态快照转移的方式来备份。

节点可以在一个特定的时间点来启动备份，这个时间无需人工选择干预，数据库会自动选择一个没有任何影响数据库的变更执行的时间点。

这种备份方式会把GTID和备份相关联，对于可能发生的潜在数据丢失或损坏故障，便于使用GTID进行修复。

备份时节点与cluster不再保持同步，避免做备份时影响带宽性能，备份进程更不会阻断节点。

集群能够自主判断某个节点正在执行备份，就不会选这个节点再作为另一个节点的donor。

MySQL Galera集群的备份方案：

Percona XtraDB Cluster（简称PXC集群）提供了MySQL高可用的一种实现方法。

1.集群是有节点组成的，推荐配置至少3个节点，但是也可以运行在2个节点上。

2.每个节点都是普通的mysql/percona服务器，可以将现有的数据库服务器组成集群，反之，也可以将集群拆分成单独的服务器。

3.每个节点都包含完整的数据副本。PXC集群主要由两部分组成：Percona Server with XtraDB和Write Set Replication patches（使用了Galera library，一个通用的用于事务型应用的同步、多主复制插件）。

Percona Server:三个流行MySQL分 支：Drizzle、MariaDB和Percona Server（包括XtraDB引擎）。

1，同步复制，事务要么在所有节点提交或不提交。

2，多主复制，可以在任意节点进行写操作。

3，在从服务器上并行应用事件，真正意义上的并行复制。

4，节点自动配置，数据一致性，不再是异步复制。

PXC特性：

1、 当前版本（5.6.20）的复制只支持InnoDB引擎，其他存储引擎的更改不复制。然而，DDL（Data Definition Language） 语句在statement级别被复制，并且，对mysql.*表的更改会基于此被复制。例如CREATE USER...语句会被复制，但是 INSERT INTO mysql.user...语句则不会。（也可以通过wsrep_replicate_myisam参数开启myisam引擎的复制，但这是一个实验性的参数）。

2、XC集群一致性控制机制，事有可能被终止，原因如下：集群允许在两个节点上同时执行操作同一行的两个事务，但是只有一个能执行成功，另一个会被终止，集群会给被终止的客户端返回死锁错误(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).

3、写入效率取决于节点中最弱的一台，因为PXC集群采用的是强一致性原则，一个更改操作在所有节点都成功才算执行成功。

4、只支持innodb引擎，所有表都要有主键，.由于写要同步到其它节点，存在写扩大问题

5、非常依赖于网络稳定性，不适用于远距离同步

PXC劣势：

中国移动

案例

Percona+XtraDB +Galera（PXC)

haproxy作为MariaDB Galera Cluster的前端

2台haproxy用keepalived避免单点故障

3台MariaDB和一个garbd仲裁节点组成集群，仲裁节点上无数据

Galera的SST采用Percona提供的XtraBackup(防止锁表，非阻塞)

同步复制

l 真正的multi-master，即所有节点可以同时读写数据库

l 自动的节点成员控制，失效节点自动被清除

l 新节点加入数据自动复制

l 真正的并行复制，行级

l 用户可以直接连接集群，使用感受上与MySQL完全一致

主要功能：

因为是多主，所以不存在Slavelag(延迟)

l 不存在丢失事务的情况

l 同时具有读和写的扩展能力

l 更小的客户端延迟

l 节点间数据是同步的，而Master/Slave模式是异步的，不同slave上的binlog可能是不同的

优势：

l 加入新节点时开销大，需要复制完整的数据

l 不能有效地解决写扩展的问题，所有的写操作都发生在所有的节点

l 有多少个节点，就有多少份重复的数据

l 由于事务提交需要跨节点通信，即涉及分布式事务操作，因此写入会比主从复制慢很多，节点越多，写入越慢，死锁和回滚也会更加频繁

l 对网络要求比较高，如果网络出现波动不稳定，则可能会造成两个节点失联，Galera Cluster集群会发生脑裂，服务将不可用

l 仅支持InnoDB/XtraDB存储引擎，任何写入其他引擎的表，包括mysql.*表都不会被复制。但是DDL语句可以复制，但是insert into mysql.user(MyISAM存储引擎)之类的插入数据不会被复制

l Delete操作不支持没有主键的表，因为没有主键的表在不同的节点上的顺序不同，如果执行select … limit …将出现不同的结果集

l LOCK/UNLOCK TABLES/FLUSH TABLES WITH READ LOCKS不支持单表所锁，以及锁函数GET_LOCK()、RELEASE_LOCK()，但FLUSH TABLES WITH READ LOCK支持全局表锁

l General Query Log日志不能保存在表中，如果开始查询日志，则只能保存到文件中

l 不能有大事务写入，不能操作wsrep_max_ws_rows=131072(行)，且写入集不能超过wsrep_max_ws_size=1073741824(1GB)，否则客户端直接报错

l 由于集群是乐观锁并发控制，因此，在commit阶段会有事务冲突发生。如果两个事务在集群中的不同节点上对同一行写入并提交，则失败的节点将回滚，客户端返回死锁报错

l XA分布式事务不支持Codership Galera Cluster，在提交时可能会回滚

l 整个集群的写入吞吐量取决于最弱的节点限制，集群要使用同一的配置

局限

MariaDB Galera Cluster

基于Galera的同步复制

全部使用官方组件，不依赖于第三方软件；

可以实现数据的强一致性；

国内使用的较少；

配置较复杂，需要使用NDB储存引擎，与MySQL常规引擎存在一定差异；

至少三节点；

“NDB” 是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点

管理(MGM)节点：这类节点的作用是管理MySQL Cluster内的其他节点，如提供配置数据、启动并停止节点、运行备份等。由于这类节点负责管理其他节点的配置，应在启动其他节点之前首先启动这类节点。

数据节点：这类节点用于保存 Cluster的数据。数据节点的数目与副本的数目相关，是片段的倍数。例如，对于两个副本，每个副本有两个片段，那么就有4个数据节点。不过没有必要设置多个副本。

SQL节点：这是用来访问 Cluster数据的节点。对于MySQL Cluster，客户端节点是使用NDB Cluster存储引擎的传统MySQL服务器。

MySQL cluster

MGR——Mysql的组复制之多主模式

PhxSQL是一个兼容MySQL、服务高可用、数据强一致的关系型数据库集群。PhxSQL以单Master多Slave方式部署，在集群内超过一半机器存活的情况下，可自身实现自动Master切换，且保证数据一致性。

PhxSQL的设计是为了解决MySQL半同步复制的不足，使MySQL集群在Master切换过程中保证数据的一致。

Master通过Paxos协议投票选出。

Master带有租约，并定时续租。租约过期后，需重新选举新的Master。

全局只有1个Master，或者没有Master存在。

有效拒绝过期Master的非法写入。

PhxSQL自身进行了Master管理

PhxSQL具有服务高可用、数据强一致、高性能、运维简单、和MySQL完全兼容的特点。

服务高可用：PhxSQL集群内只要多数派节点存活就能正常提供服务；出于性能的考虑，集群会选举出一个Master节点负责写入操作；当Master失效，会自动重新选举新的Master。

数据强一致：PhxSQL采用多节点冗余部署，在多个节点之间采用paxos协议同步流水，保证了集群内各节点数据的强一致。

高性能：PhxSQL比MySQL SemiSync的写性能更好，得益于Paxos协议比SemiSync协议更加高效；

运维简单：PhxSQL集群内机器出现短时间故障，能自动恢复数据，无需复杂的运维操作；PhxSQL更提供一键更换（新增/删除）集群内的机器，简化运维的工作。

MySQL完全兼容：PhxSQL是基于Percona的研发，完全兼容MySQL的操作命令。可通过MySQL提供的mysqlclient/perconaserverclient直接操作PhxSQL。

特性

微信开源PhxSQL（Paxos 算法）

图中每个MySQL节点上面部署了一个HA client，用于实时向zookeeper汇报本地节点的心跳状态，比如主库crash，通过修改zookeeper(以下简称zk)上的节点信息，来 通知HA。HA节点在zk上注册监听事件，当zk节点发生变化时会自动让HA感知，HA节点可以部署一个或多个，主要用于容灾。HA节点之间通过 zookeeper服务来实现数据的一致性，通过分布式锁保证多个HA节点不会同时对一个主从节点进行切换。HA本身是无状态的，所有MySQL节点状态 信息全部保存在zookeeper服务器上，切换时，HA会对MySQL节点进行复检，然后切换。我们看看引入zookeeper后的切换流程：

a.HA client 检测到 Master 异常，进行一系列判断，最后确定 Master 宕掉；

b.HA client 删除 Master在zk上的节点信息；

c.由于监听机制，HA会感知到有节点被删除；

d.HA对MySQL节点进行复检，比如建立连接，更新心跳表等

e.确认异常后，则进行切换。

切换流程：

1. 保证了整个系统的高可用

2. 主从的强一致依赖于MySQL本身，比如半同步，或者外围工具的回补策略，类似MHA。

3. 扩展性非常好，可以管理大规模集群。

1.引入zk，整个系统变得复杂。

基于zookeeper的高可用

mySQL的高可用架构对比分析