五大常见的MySQL高可用方案

五大常见的MySQL高可用方案如下：

1. 主从或主主半同步复制

概述：使用双节点数据库，搭建单向或者双向的半同步复制。在MySQL 5.7及以后的版本中，由于引入了lossless replication、logical多线程复制等新特性，使得MySQL原生半同步复制更加可靠。
架构：通常会和proxy、keepalived等第三方软件同时使用，用于监控数据库的健康状态并执行管理命令。
优点：
架构简单，使用原生半同步复制作为数据同步的依据。
双节点，没有主机宕机后的选主问题，直接切换即可。
需求资源少，部署简单。
缺点：
完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证。
需要额外考虑haproxy、keepalived等的高可用机制。

2. 半同步复制优化

概述：在原有半同步复制的基础上进行优化，使半同步复制的机制更加可靠。
优化方案：
双通道复制：当半同步复制发生超时时，复制断开。再次建立复制时，同时建立两条通道，一条用于半同步复制，另一条用于异步复制以追补落后数据。
binlog文件服务器：搭建两条半同步复制通道，其中一条连接文件服务器的通道在正常情况下不启用。当主从的半同步复制发生网络问题退化后，启动该通道。
优点：
双节点，需求资源少，部署简单。
架构简单，没有选主的问题。
相比于原生复制，优化后的半同步复制更能保证数据的一致性。
缺点：
需要修改内核源码或者使用mysql通信协议，需要对源码有一定的了解并能做一定程度的二次开发。
依旧依赖于半同步复制，没有从根本上解决数据一致性问题。

3. 高可用架构优化

概述：将双节点数据库扩展到多节点数据库或多节点数据库集群，可以选择一主两从、一主多从或多主多从的集群架构。
常见方案：
MHA+多节点集群：MHA Manager定时探测集群中的master节点，当master出现故障时，自动将最新数据的slave提升为新的master，并将所有其他的slave重新指向新的master。
zookeeper+proxy：使用zookeeper保证proxy的高可用性，避免网络分区现象的产生。
优点：
可以进行故障的自动检测和转移。
可扩展性较好，可以根据需要扩展MySQL的节点数量和结构。
多节点架构的高可用性通常优于双节点架构。
缺点：
至少需要三节点，相对于双节点需要更多的资源。
逻辑较为复杂，发生故障后排查和定位问题更加困难。
数据一致性仍然依赖于原生的MySQL半同步复制，存在数据不一致的风险。
可能因为网络分区发生脑裂现象。

4. 共享存储

概述：共享存储实现了数据库服务器和存储设备的解耦，通过磁盘数据同步的手段来保证数据的一致性。
常见方案：
SAN共享存储：允许存储设备和处理器（服务器）之间建立直接的高速网络连接，实现数据的集中式存储。
DRBD磁盘复制：基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像。
优点：
两节点即可，部署简单，切换逻辑简单。
很好地保证数据的强一致性。
不会因为MySQL的逻辑错误发生数据不一致的情况。
缺点：
需要考虑共享存储的高可用性。
价格昂贵（SAN）。
对IO性能影响较大（DRBD）。
从库不提供读操作（DRBD）。

5. 分布式协议

概述：分布式协议可以很好地解决数据一致性问题。
常见方案：
MySQL Cluster：官方集群部署方案，使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。
Galera：基于Galera的MySQL高可用集群，是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。
Paxos（POAXS）：Paxos算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。
优点：
全部使用官方组件（MySQL Cluster），不依赖于第三方软件。
可以实现数据的强一致性。
多主写入，无延迟复制（Galera、Paxos）。
有成熟的社区和互联网公司在大规模使用（Galera）。
自动故障转移，自动添加、剔除节点（Galera、Paxos）。
缺点：
国内使用较少（MySQL Cluster）。
配置较复杂，需要使用NDB存储引擎（MySQL Cluster），与MySQL常规引擎存在差异。
需要为原生MySQL节点打wsrep补丁（Galera）。
只支持InnoDB存储引擎（Galera、Paxos）。
至少三节点（MySQL Cluster、Galera、Paxos）。

以上五大方案各有优缺点，选择时需根据具体业务需求、资源限制和技术团队能力进行综合考虑。

热门标签