MySQL数据库的⾼可⽤⽅案总结
⾼可⽤架构对于互联⽹服务基本是标配，⽆论是应⽤服务还是数据库服务都需要做到⾼可⽤。虽然互联⽹服务号称7*24⼩时不间断服务，但多多少少有⼀些时候服务不可⽤，⽐如某些时候⽹页打不开，百度不能搜索或者⽆法发微博，发等。⼀般⽽⾔，衡量⾼可⽤做到什么程度可以通过⼀年内服务不可⽤时间作为参考，要做到3个9的可⽤性，⼀年内只能累计有8个⼩时不可服务，⽽如果要做到5个9的可⽤性，则⼀年内只能累计5分钟服务中断。所以虽说每个公司都说⾃⼰的服务是7*24不间断的，但实际上能做到5个9的屈指可数，甚⾄根本做不到，国内互联⽹巨头BAT(百度，阿⾥巴巴，腾讯)都有因为故障导致的停服问题。对于⼀个系统⽽⾔，可能包含很多模块，⽐如前端应⽤，缓存，数据库，搜索，消息队列等，每个模块都需要做到⾼可⽤，才能保证整个系统的⾼可⽤。对于数据库服务⽽⾔，⾼可⽤可能更复杂，对⽤户的服务可⽤，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的⾼可⽤⽅案时，⼀般会同时考虑⽅案中数据⼀致性问题。今天这篇⽂章主要讨论MySQL数据库的⾼可⽤⽅案，介绍每种⽅案的特性以及优缺点，本⽂是对各种⽅案的总结，希望抛砖引⽟，和⼤家⼀起讨论。
1.基于共享存储的⽅案SAN
⽅案介绍：SAN(Storage Area Network)简单点说就是可以实现⽹络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使⽤共享存储时，服务器能够正常挂载⽂件系统并操作，如果服务器
挂了，备⽤服务器可以挂载相同的⽂件系统，执⾏需要的恢复操作，然后启动MySQL。共享存储的架构如下:
property是什么意思啊优点:
1.可以避免存储外的其它组件引起的数据丢失。
2.部署简单，切换逻辑简单，对应⽤透明。
3.保证主备数据的强⼀致。
限制或缺点:
1.共享存储是单点，若共享存储挂了，则会丢失数据。
2.价格⽐价昂贵。
2.基于磁盘复制的⽅案 DRBD
⽅案介绍：DRBD(Distributed Replicated Block Device)是⼀种磁盘复制技术，可以获得和SAN类似的效果。DBRD是⼀个以linux内核模块⽅式实现的块级别同步复制技术。它通过⽹卡将主服务器的每个块复制到另外⼀个服务器块设备上，并在主设备提交块之前记录下来。DRBD与SAN类似，也是有⼀个热备机器，开始提供服务时会使⽤和故障机器相同的数据，只不过DRBD的数据是复制存储，不是共享存储。DRBD的架构图如下：
优点：
1.切换对应⽤透明
2.保证主备数据的强⼀致。
限制或缺点：
1.影响写⼊性能，由于每次写磁盘，实质都需要同步到⽹络服务器。
2.⼀般配置两节点同步，可扩展性⽐较差
3.备库不能提供读服务，资源浪费
3.基于主从复制(单点写)⽅案
前⾯讨论的两种⽅案分别依赖于底层的共享存储和磁盘复制技术，来解决MYSQL服务器单点和磁盘单点的问题。⽽实际⽣产环境中，⾼可⽤更多的是依赖MySQL本⾝的复制，通过复制为Master制作⼀个或多个热副本，在Master故障时，将服务切换到热副本。下⾯的⼏种⽅案都是基于主从复制的⽅案，⽅案由简单到复杂，功能也越来越强⼤，实施难度由易到难，各位可以根据实际情况选择合适的⽅案。
3.1.keepalived/heartbeat⽅案介绍：
keepalived是⼀个HA软件，它的作⽤是检测服务器(web服务器，DB服务器等)状态，检查原理是模拟⽹络请求检测，检测⽅式包括
HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK等。对于DB服务器⽽⾔，主要就是IP，端⼝(TCP_CHECK)，但这可能不够(⽐如DB服务器ReadOnly)，因此keepalived也⽀持⾃定义脚本。keepalived通过监听来确认服务器的状态，如果发现服务器故障，则将故障服务器从系统中剔除。keepalived的⾼可⽤架构如下图，分别在主、从服务器上安装keepalived的软件，并配置同样的VIP，VIP层将真实IP屏蔽，应⽤服务器通过访问VIP来获取DB服务。当Master故障
时，keepalived感知，并将Slave提升主，继续提供服务对应⽤层透明。
优点：
1. 安装配置简单
2. Master故障时，Slave快速切换提供服务，并且对应⽤透明。
限制或缺点：
1.需要主备的IP在同⼀个⽹段。
2.提供的检测机制⽐较弱，需要⾃定义脚本来确定Master是否能提供服务，⽐如更新⼼跳表等。
3.⽆法保证数据的⼀致性，原⽣的MySQL采⽤异步复制，若Master故障，Slave数据可能不是最新，导致数据丢失，因此切换时要考虑Slave延迟的因素，确定切换策略。对于强⼀致需求的场景，可以开启(semi-sync)半同步，来减少数据丢失。
4.keepalived软件⾃⾝的HA⽆法保证。
3.2.MHA⽅案介绍：MHA(Master High Availability)是⼀位⽇本MySQL⼤⽜⽤Perl写的⼀套MySQL故障切换⽅案，来保证数据库的⾼可⽤，MHA通过从宕机的主服务器上保存⼆进制⽇志来进⾏回补，能在最⼤程度上减少数据丢失。MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA可以单独部署在⼀台独⽴的机器上管理多个master-slave集，MHA Node运⾏在每台My
SQL服务器上，主要作⽤是切换时处理⼆进制⽇志，确保切换尽量少丢数据。MHA Manager会定时探测集中的master节点，当master出现故障时，它可以⾃动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应⽤程序完全透明。MHA的架构如下：
MHA failover过程：
a.检测到 Master 异常，进⾏⼀系列判断，最后确定 Master 宕掉；
b.检查配置信息，罗列出当前架构中各节点的状态；
c.根据定义的脚本处理故障的 Master，VIP漂移或者关掉mysqld服务；
d.所有 Slave ⽐较位点，选出位点最新的 Slave，再与 Master ⽐较并获得 binlog 的差异，copy 到管理节点；
e.从候选节点中选择新的 Master，新的 Master 会和位点最新的 Slave 进⾏⽐较并获得 relaylog 的差异；
f.管理节点把 binlog 的差异 copy 到新 Master，新 Master 应⽤ binlog 差异和 relaylog 差异，最后获得位点信息，并接受写请求(read_only=0)；
g.其他 Slave 与位点最新的 Slave 进⾏⽐较，并获得 relaylog 的差异，copy 到对应的 Slave；
h.管理节点把 binlog 的差异 copy 到每个 Slave，⽐较 Exec_Master_Log_Pos 和 Read_Master_Log_Pos，获得差异⽇志；
i.每个Slave应⽤所有差异⽇志，然后 reset slave 并重新指向新 Master；
j.新 Master reset slave 来清除 Slave 信息。
优点：
1. 代码开源，⽅便结合业务场景⼆次开发
2. 故障切换时，可以修复多个Slave之间的差异⽇志，最终使所有Slave保持数据⼀致，然后从中选择⼀个充当新的Master，并将其它Slave指向它。
3. 可以灵活选择VIP⽅案或者全局⽬录数据库⽅案(更改Master IP映射)来进⾏切换。
缺点：
1.⽆法保证强⼀致，因为从故障Master上保存⼆进制⽇志并不总是可⾏，⽐如Master磁盘坏了，或者SSH认证失败等。
2.只⽀持⼀主多从架构，要求⼀个复制集中必须最少有三台数据库服务器，⼀主⼆从，即⼀台充当master，⼀台充当备⽤master，另外⼀台充当从库。
编程猫不让退费怎么办3.采⽤全局⽬录数据库⽅案切换时，需要应⽤感知变化，因此对应⽤不透明，因此要保持切换对应⽤透明，依然依赖于VIP。
4.不适⽤于⼤规模集部署，配置⽐较复杂。
5.MHA管理节点本⾝的HA⽆法保证。
3.3.基于zookeeper的⾼可⽤⽅案介绍：
从前⾯的讨论可以看到，⽆论是keepalived⽅案还是MHA⽅案，都⽆法解决HA软件⾃⾝的⾼可⽤问题，因为HA本⾝是单点。那么如果将HA也引⼊多个副本呢？那么⼜带来新的问题，1.HA软件之间如何保证强同步。2.如何确保不会有多个HA同时进⾏切换动作。这两个问题实质都分布式系统⼀致性问题，为此，可以为HA软件引⼊类似Paxos，Raft这样的分布式⼀致性协议，保证HA软件的可⽤性。zooKeeper是⼀个典型的发布/订阅模式的分布式数据管理与协调框架，通过zookeeper中丰富的数据节点类型进⾏交叉使⽤，配合watcher事件通知机制，可以⽅便地构建⼀系列分布式应⽤涉及的核⼼功能，⽐如：数据发布/订阅，负载均衡，分布式协调/通知，集管
理，Master选举，分布式锁和分布式队列等。zookeeper是⼀个很⼤话题，⼤家可以google去更多的信息，我这⾥主要讨论zookeeper如何解决HA⾃⾝可⽤性问题。架构图如下：
图中每个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.确认异常后，则进⾏切换。
我们再看看这种架构下，是否能保证HA⾃⾝的⾼可⽤
(1).如果HA-client本⾝挂了，MySQL节点正常？
HA-Client管理的MySQL节点⽆法与zookeeper保持⼼跳，zk服务将节点删除，HA会感知到这种变化，准备尝试⼀次切换，切换前，会进⾏复检，复检时发现MySQL节点是OK的，则不会切换。
(2).MySQL节点与zookeeper的⽹络断了，那么表现如何？eclipse导入整个项目
由于HA-Client与节点在同⼀台主机，因此HA-client⽆法再定时向zk汇报⼼跳，zk会将对应的MySQL节点信息删除，HA尝试复检，依然失败，则进⾏切换。
(3).HA挂了，表现如何？
由于HA⽆状态，并且有多个副本，因此⼀个HA挂了，不会对整个系统造成影响。
优点：
1. 保证了整个系统的⾼可⽤
2. 主从的强⼀致依赖于MySQL本⾝，⽐如半同步，或者外围⼯具的回补策略，类似MHA。
3. 扩展性⾮常好，可以管理⼤规模集。layout怎么读
缺点：
1.引⼊zk，整个系统变得复杂。
4.基于Cluster(多点写)⽅案
第3节讨论的⽅案基本是⽬前业内使⽤的主流⽅案，这类⽅案的特点是，单点写。虽然我们可以借助中间件进⾏分⽚(sharding)，但是对于同⼀份数据，依然只允许⼀个节点写，从这个⾓度来说，上⾯的⽅案是伪分布式。下⾯讨论的两种⽅案算是真正分布式，同⼀个数据理论上可以在多个节点写⼊，类似于Oracle的RAC，EMC的GreenPlum这种分布式数据库。在MySQL领域，主要提供了2种解决⽅案：基于Galera的PXC和NDB Cluster。MySQL Cluster实现基于NDB存储引擎，使⽤很多局限性，⽽PXC是基于innodb引擎，虽然也有局限性，但由于⽬前innodb使⽤⾮常⼴泛，所以有⼀定的参考价值。⽬前据我所知，去哪⼉公司在他们的⽣产环境中使⽤了PXC ⽅案。PXC(Percona XtraDB Cluster)的架构图如下：
优点：
1.准同步复制
2.多个可同时读写节点，可实现写扩展，较分⽚⽅案更进⼀步
3.⾃动节点管理
4.数据严格⼀致
mysql无法连接到服务器5.服务⾼可⽤
缺点：
1.只⽀持innodb引擎
2.所有表都要有主键
3.由于写要同步到其它节点，存在写扩⼤问题
4.⾮常依赖于⽹络稳定性，不适⽤于远距离同步
5.基于中间件proxy的⽅案
准确地来说，中间件与⾼可⽤没有特别⼤的关系，因为切换都是在数据库层完成，但引⼊中间层后，使得对应⽤更透明。在引⼊中间件之前，所有的⽅案，基本都依赖于VIP漂移机制，或者不依赖于VIP⼜不能保证对应⽤透明。通过加⼊中间件层，可以同时实现对应⽤透明和⾼可⽤。此外中间层还可以做sharding，⽅便写扩展。proxy的⽅案很多，⽐如mysql⾃带的mysql-proxy和fabric，阿⾥巴巴的cobar和tddl等。我们以fabric为例，其架构图如下:
应⽤都请求 Fabric 连接器，然后通过使⽤ XML-RPC 协议访问 Fabric 节点， Fabric 节点依赖于备⽤存储 (backing store)，⾥⾯存储整个 HA 集的元数据信息。连接器读取 backing store 的信息，然后将元数据缓存到 cache，这样做的好处就是减少每次建⽴连接时与管理节点交互所带来的开销。Fabric 节点可管理多个 HA Group，每个HA Group ⾥有⼀个 Primary 和多个 Secondary(slave)，当 Primary 异常的时候会从 Secondary 中选出最合适的节点提升为新 Primary，其余 Secondary 都将重
新指向新Primary。这些都是⾃动操作，对业务是⽆感知的，HA 切换之后还需要通知连接器更新的元数据信息。
优点：
1.切换对应⽤透明
2.可扩展性强，⽅便分⽚扩展
3.可以跨机房部署切换
缺点：
1.是⼀个⽐较新的组件，没有很多实际应⽤场景
2.没有解决强⼀致问题，主备强⼀致性依赖于MySQL⾃⾝(半同步)，以及回滚回补机制。
总结
设置下拉菜单
以上介绍了⽬前MySQL⼏种典型的⾼可⽤架构，包括基于共享存储⽅案，基于磁盘复制⽅案和基于主从复制的⽅案。对于主从复制⽅案，分别介绍了keepalived，MHA以及引⼊zookeeper的⽅案。对于每
种⽅案，都从持续可⽤，数据强⼀致性，以及切换对应⽤的透明性进⾏说明。个⼈觉得基于MySQL复制的⽅案是主流，也⾮常成熟，引⼊中间件和引⼊zookeeper虽然能将系统的可⽤性做地更好，可⽀撑的规模更⼤，但也对研发和运维也提出了更⾼的要求。因此，在选择⽅案时，要根据业务场景和运维规模做抉择。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。