数据库的高可用方案
一、概述
单机部署谈不上高可用,因为单点故障问题。高可用都是多个节点的。、
二、主从半同步复制
主从同步过程:主从复制有三个线程: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储存引擎;至少三节点;