典型的高可用设计（二）：MySQL

一、高可用模式

        MySQL数据库提供了数据库建的复制能力，做到了多个数据库同时拥有同一个数据副本，保证了数据的安全性，一台数据库服务器出现问题，其他数据库可以做到数据不丢失。MySQL的服务高可用设计也是以数据库复制能力为基础，增加故障转移能力实现的。

        常见的模式有双主（多主）、主备、主从几种。MySQL本身没有提供故障转移能力，在发生故障后需要手工或者借助第三方工具完成故障转移。

二、双主模式

 2.1实现原理

        双主模式大概有两种方式，一种是有两个主从集群组成，两个主节点互为主从，另一种是两个主库搭配一组从库。

        两台MySQL数据库互为主从，当主库B的IO线程接受到主库A传递来的二进制日志(Binlog)并将之保存为主库B的中继日志(relay log),然后主库B的SQL线程将中继日志(relay log)的事件重做到主库B上，实现主从数据同步，反之亦然。如果SQL线程发现该事件的server_id与当前库的server_id相同，则会丢弃该事件，因此两台互为主从的MySQL不会重复执行相同的事件。

        在双主模式1中，只需切换主库即可，切换速度快一些，只切换VIP就行，不需要重启数据库服务，缺点是存在一定的资源浪费。在双主模式2中，不但要切换主库，还要切换从库，需要重启从库服务，切换速度相对会慢一些，会短暂影响业务系统的可用性，好处是资源利用效率高。

        无论那种模式，都是依赖调整VIP配置、MySQL主从配置来实现，人工修改配置也好，由第三方工具实现也好，最终的结果都是一样的。

2.2实现方式

2.2.1 Keepalive  实现

        Keepalived是一个基于VRRP协议来实现的 WEB 服务高可用方案，可以利用其来避免单点故障。一个 WEB 服务至少会有2台服务器运行 Keepalived ，一台为主服务器（MASTER），一台为备份服务器（BACKUP），但是对外表现为一个虚拟IP，主服务器会发送特定的消息给备份服务器，当备份服务器收不到这个消息的时候，即主服务器宕机的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。

        在 Keepalived服务正常工作时，主 Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉Backup节点自己还活看，当主 Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主 Master节点的心跳了，Keeplived会自动将VIP切换到Backup节点，接管主Master节点的 IP资源及服务。而当主 Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。

         Keepalived方式适合双主模式1，可以有Slave节点，也可以没有Slave节点。使用Keepalived构建MySQL高可用架构是较为简单的一种方式；可满足刚开始使用MySQL的用户构建简单的高可用性架构。但Keepalived没有日志自动补齐功能，无法将最新的binlog应用到存活节点，容易产生数据丢失。

2.2.2 MMM 实现

        Google开源项目MySQL-MMM(Master-Master Replication Manager for MySQL)提供了MySQL主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件。

        在MMM高可用解决方案中，典型的应用是双主多从架构，通过MySQL replication技术实现两台服务器互为主从，且在任何时候只有一个节点可以写入，避免多点写入的数据冲突。同时，当可写的主节点故障时，MMM套件可以立刻监控到，然后将服务自动切换到另一个主节点，继续提供服务，从而实现MySQL的高可用。

        MMM高可用MySQL方案是一个通过Perl编写的、基于MySQL主从复制的、成熟完善的MySQL高可用集群解决方案，由一个管理端（monitor）和多个代理端（agent）构成。通过MMM可以实现监控和管理MySQL主主复制和服务状态，同时也可以监控多个Slave节点的复制以及运行状态，并且可以做到任意节点发生故障时实现自动切换的功能。MMM集群方案的出现为MySQL的读、写分离架构的应用提供了一个很好的平台，这是因为MMM集群方案将读IP(reader IP)和写IP(write IP)从数据库层面提取出来，在业务系统只需调用即可实现读、写分离功能。

        MMM 提供了自动和手动两种方式移除一组服务器中复制延迟较高的服务器的虚拟ip，同时它还可以备份数据，实现两节点之间的数据同步等。由于MMM无法完全的保证数据一致性，所以MMM适用于对数据的一致性要求不是很高，但是又想最大程度的保证业务可用性的场景。

        MMM 具有良好的稳定性、高可用性和可扩展性，当活动的Master服务器故障以后，备用Master服务器会立刻接管，而其他的Slave服务器也能自动切换到备用Master服务器继续进行同步复制，整个过程无需人为干预。资源利用率也较好。

        当然，MMM集群套件也有一定的缺点：首先MMM架构需要多个节点、多个IP,对服务器数量有要求（这是一种说法，个人认为不会存在此类情况，MySQL从节点一般要求不要超过8个，否则数据复制的压力太大，影响数据库性能，所以MySQL集群的服务器数量不会太多）；其次，MMM方案在读、写非常繁忙的业务系统下表现不是很稳定，可能会出现复制延时、切换失效等问题。因此，MMM方案并不太适应于对数据安全性要求很高，并且读、写频繁的环境中。

        Monitor节点是个单点，可以结合Keepalived实现高可用。

2.3读写策略

        在一些双主方案中会提到双主双写，对数据库的写操作进行了负载均衡处理，但是双主双写的方式弊端很大，采用时要慎重。主要问题为：

• ID冲突

        在A主库写入，当A数据未同步到B主库时，对B主库写入，如果采用自动递增容易发生ID主键的冲突。可以采用MySQL自身的自动增长步长。但是自动步长的方式看上去就不靠谱，等于是将数据库的数量，扩展受限。不单单是ID，数据表的唯一索引、或者用了非ID的主键，都会存在冲突问题。

• 更新丢失

        同一条记录在两个主库中进行更新，会发生前面覆盖后面的更新丢失。

        所以，没有特别的需求场景，建议使用双主单写的方式，同一时间只有一个节点写入，不会产生数据冲突。

三、主备模式

        读写都在主机上，备机只复制主机的数据，如果主机出现故障，备机替代主机。在主机状态正常的情况下，备机不对外提供服务。

优点：搭建简单、使用简单，主备之间只有数据同步，不需要考虑别的情况。

缺点：备机只用来备份，浪费了备机这台服务器的资源。

主机发生故障时如何切换：

        1.人工切换，人工切换时效性差，主机故障一般机率很小，突然间出现事故，操作人员未必能熟练的按步骤顺利操作完成。

        2.引入中间件，例如ZooKeeper、keepalived，由中间件来监控状态，做故障转移操作。一般情况下会采用这种方式。

四、主从模式

4.1实现原理

        可以写主读从，读写分离，一主多从的情况下可以分担数据库的读压力。如果主机故障，可以选择一台从机替换主机，继续提供服务。

优点：充分利用了资源，从机对外提供读操作。而且在主机挂了的时候，如果没任命新机主之前，读操作还是能用的。

缺点：

        1.客户端需要多个判断，也就是不同操作需要发放给不同服务器，需要增加读写分离的路由处理逻辑。

        2.主从延迟，读操作分配给从库，就会存在数据同步的延迟问题，主库完成了写，由于存在延迟，在读数据的时候没有读到，需要在业务逻辑中针对同步延迟做相应的处理。

4.2MHA方式

        MHA（Master High Availability）是由日本人yoshinorim开发的一款成熟且开源的MySQL高可用程序，它实现了MySQL主从环境下MASTER宕机后能够自动进行单次故障转移的功能，其本身由perl语言编写，安装方便使用简单。

        MHA由MHA Node（数据节点）、MHA Manager（管理节点）两部分组成。MHA Node运行在每台MySQL服务器上。MHA Manager可以单独部署在一台独立的机器上，管理多个Master-Slave集群。        

        MHA也可以扩展到如下的多个集群：

        MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。MHA Node 主要作用是切换时处理二进制日志，确保切换尽量少丢数据。

优点：

        1.可以进行故障的自动检测和转移;
        2.可扩展性较好，可以根据需要扩展MySQL的节点数量和结构;
        3.相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低。

缺点：

        1.至少需要三节点，相对于双节点需要更多的资源;
        2.逻辑较为复杂，发生故障后排查问题，定位问题更加困难;
        3.数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险;
        4.可能因为网络分区发生脑裂现象。

4.3其他方式

4.3.1Zookeeper+proxy

        Zookeeper使用分布式算法保证集群数据的一致性，使用zookeeper可以有效的保证proxy的高可用性，可以较好的避免网络分区现象的产生。

优点：

1. 较好的保证了整个系统的高可用性，包括proxy、MySQL;
2. 扩展性较好，可以扩展为大规模集群;

缺点：

1. 数据一致性仍然依赖于原生的mysql半同步复制;
2. 引入zk，整个系统的逻辑变得更加复杂;

4.3.2 MySQL cluster

        MySQL cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。

优点：

1. 全部使用官方组件，不依赖于第三方软件；
2. 可以实现数据的强一致性；

缺点：

1. 国内使用的较少；
2. 配置较复杂，需要使用NDB储存引擎，与MySQL常规引擎存在一定差异；
3. 至少三节点；

4.3.3 Galera

        基于Galera的MySQL高可用集群， 是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。

优点：

1. 多主写入，无延迟复制，能保证数据强一致性；
2. 有成熟的社区，有互联网公司在大规模的使用；
3. 自动故障转移，自动添加、剔除节点；

缺点：

1. 需要为原生MySQL节点打wsrep补丁
2. 只支持innodb储存引擎
3. 至少三节点；

五、扩展知识：VIP与脑裂

VIP的工作原理是：

• 为当期主机配置一个虚拟网卡，如eth0:0，该网卡绑定了唯一的MAC地址和虚拟IP地址VIP

• 局域网内的主机欲与该VIP通信时，先通过ARP协议取到该VIP对应的MAC地址，再将VIP与MAC地址的对应关系缓存在其主机上

• 后续通信时，使用上一步骤取到的MAC作为报文的MAC地址

VIP切换的原理是，

• 将旧master绑定的虚拟网卡注销掉

• 在新的master注册新的虚拟网卡（产生了新的MAC地址）

• 通知局域网节点更新VIP与MAC的对应关系，后续通信采用新MAC地址

        脑裂的原因，在于旧master节点没有正常将VIP摘掉，这时局域网机器通过ARP获取VIP的MAC时，就可能取到旧的MAC地址，导致与旧master通信。什么情况会出现这种情况呢？旧master由于上层交换机故障，未与manager节点正常通信，此时VIP是没有摘除掉的，过了一段时间上层交换机恢复了就会导致此问题。