Mysql数据库高可用方案

数据库的高可用方案

一、概述

单机部署谈不上高可用，因为单点故障问题。高可用都是多个节点的。、

二、主从半同步复制

主从同步过程：主从复制有三个线程：master(binlog dump thread)、slave（IO thread、SQL thread）

• master binlog，主从复制的基础是master所有的变更记录到binlog日志文件
• master binlog dump thread，当binlog有变动时，dump thread读取其内容并发生给slave从节点
• slave IO thread接受binlog内容，并将其写入到relay log 中继文件中
• slave SQL thread 读取relay log 文件内容对数据更新进行重放，最终保证主从数据库的一致性

注意主从节点使用binlog 文件+position 偏移量来定位主从同步位置，从节点会保存已经接收的偏移量，如果slave从节点宕机重启，则会自动从偏移位置发起同步。

全同步复制：master写入binlog后强制同步日志到从库，所有从库执行完成后才返回给客户端
半同步复制：从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库确认就认为写操作完成

通常会和proxy、keepalived等第三方软件同时使用，即可以用来监控数据库的健康，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。

优点：架构、部署比较简单，主机宕机直接切换即可。
缺点：完全依赖于半同步复制，半同步复制退化为异步复制，无法保证数据一致性。

注意：半同步复制机制是可靠的，可以保证数据一致性的。但是如果网络发生波动，半同步复制发生超时会切换为异步复制，异复制是无法保证数据的一致性的。

三、双通道复制

针对半同步复制方案，可以在半同复制的基础上优化一下，尽可能保证半同复制。如双通道复制方案

优点：这种方案架构、部署也比较简单，主机宕机也是直接切换即可。比方案1的半同步复制，更能保证数据的一致性。
缺点：需要修改内核源码或者使用mysql通信协议，没有从根本上解决数据一致性问题。

四、数据库集群–主从从集群

在主从双节点数据库扩展为在主从从集群

优点：保证了整个系统的高可用性，扩展性也较好，可以扩展为大规模集群。
缺点：数据一致性仍然依赖于原生的mysql半同步复制；

五、 共享存储

共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。

DRBD磁盘复制

当本地主机出现问题，远程主机上还保留着一份相同的数据，即可以继续使用，保证了数据的安全。

优点：部署简单，价格合适，保证数据的强一致性
缺点：对IO性能影响较大，从库不提供读操作

六、pxc强一致性方案

分布式协议可以很好解决数据一致性问题。常见的部署方案就是MySQL cluster，它是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。

注意：NDB存储引擎是MYSQL的集群存储引擎。对于这个存储引擎，MYSQL服务器实际上变成了一个其他进程的集群客户端。 集群节点会处理彼此间的通信，从而在内存中实现对表的管理。为了是实现冗余，表会在集群进程之间被复制。内存存储提供了高性能，而集群机制提供了高可用性。

优点：不依赖于第三方软件，可以实现数据的强一致性；
缺点：配置较复杂；需要使用NDB储存引擎；至少三节点；