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.备库不能提供读服务，资源浪费

1. 安装配置简单

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

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

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

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

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

无法保证强一致,在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。 例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。

使用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）故障切换快,在主从复制集群中，只要从库在复制上没有延迟，MHA通常可以在数秒内实现故障切换。9-10秒内检查到master故障， 可以选择在7-10秒关闭master以避免出现裂脑，几秒钟内，将差异中继日志（relay log）应用到新的master上，因此总的宕机时间通 常为10-30秒。恢复新的master后，MHA并行的恢复其余的slave。即使在有数万台slave，也不会影响master的恢复时间。

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

3）无需修改当前的MySQL设置,MHA的设计的重要原则之一就是尽可能地简单易用。MHA工作在传统的MySQL版本5.0和之后版本 的主从复制环境中。和其它高可用解决方法比，MHA并不需要改变MySQL的部署环境。MHA适用于异步和半同步的主从复制。启动 /停止/升级/降级/安装/卸载MHA不需要改变（包扩启动/停止）MySQL复制。当需要升级MHA到新的版本，不需要停止MySQL，仅仅 替换到新版本的MHA，然后重启MHA　Manager就好了。

4）无需增加大量的服务器MHA,由MHA Manager和MHA Node组成。MHA Node运行在需要故障切换/恢复的MySQL服务器上，因此并不需要额外 增加服务器。MHA Manager运行在特定的服务器上，因此需要增加一台（实现高可用需要2台），但是MHA Manager可以监控大量（甚至上百台） 单独的master，因此，并不需要增加大量的服务器。即使在一台slave上运行MHA Manager也是可以的。综上，实现MHA并没用额外增加大量的服务。

5）无性能下降,MHA适用与异步或半同步的MySQL复制。监控master时，MHA仅仅是每隔几秒（默认是3秒）发送一个ping包，并不发送重查询。 可以得到像原生MySQL复制一样快的性能

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

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

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

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

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

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

DeNA

魅族

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

1.TID：Transaction ID,事务的ID号：也就是说在mysql复制中每一个事务都有自己的ID号（随机数）

2.GTID：Global Transaction ID,全局事务ID，在整个事务架构中每一个事务ID号是全局唯一的，不止是在一个节点上而是整个主从复制架构中每任何两个事务的ID号都不会相同。

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是连续的没有空洞的，保证数据的一致性，零丢失。

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

galera仲裁者Arbitrator,galera仲裁者是集群的一员，参与投票，但不真正参与复制。galera仲裁者的设立出于以下两个目的：

真正的多主模式（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。

架构图

PXC特性：

PXC劣势：

案例

架构图

主要功能：

优势：

缺点：

局限

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

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

国内使用的较少；

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

至少三节点；

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

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

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

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

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

PhxSQL的设计是为了解决MySQL半同步复制的不足，使MySQL集群在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。

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

切换流程：

优点：

缺点：