MySQL 同步复制及高可用方案、原理及架构图
相关链接:《MySQL主从复制原理与部署过程详解》
MySql
作为应用程序的数据存储服务,要实现MySql
数据库的高可用。必然要使用的技术就是数据库的复制,如果主节点出现故障可以手动的切换应用到从节点,这点相信运维同学都是知道,并且可以实现的。但是这种情况只是手动的切换,对可用性有要求的业务需要分别实现主库和从库的高可用,保障在数据库出现宕机的情况下,可以自动实现数据库的故障转移,保障应用的可用性和用户体验。
本文将会对一些常用的数据库高可用方案进行介绍,根据你不同的场景,选择合适的高可用方案即可。
1.MMM
高可用方案
1.1Mysql-MMM
介绍
MMM(Master-Master replication managerfor Mysql
,Mysql主主复制
管理器)是一套灵活的脚本程序,基于perl
实现,用来对mysql replication
进行监控和故障迁移,并能管理mysql Master-Master
复制的配置(同一时间只有一个节点是可写的)。
1.2.组件
**mmm_mond
**:监控进程,负责所有的监控工作,决定和处理所有节点角色活动。此脚本需要在监管机上运行。
**mmm_agentd
**:运行在每个mysql
服务器上的代理进程,完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。
mmm_control
:一个简单的脚本,提供管理mmm_mond
进程的命令。
mysql-mmm
的监管端会提供多个虚拟IP(VIP
,包括一个可写VIP
,多个可读VIP
,通过监管的管理,这些IP
会绑定在可用mysql
之上,当某一台mysql
宕机时,监管会将VIP
迁移至其他mysql
。
在整个监管过程中,需要在mysql
中添加相关授权用户,以便让mysql
可以支持监理机的维护。授权的用户包括一个mmm_monitor
用户和一个mmm_agent
用户,如果想使用mmm
的备份工具则还要添加一个mmm_tools
用户。
1.3.架构图
正常工作时:
主节点故障时:
1.4 MMM
优点
(1)高可用性,扩展性好,出现故障自动转移,对于主主同步,在同一时间只提供一台数据库写操作,保证数据的一致性。
(2)配置简单,容易操作。
1.5MMM
缺点
(1)需要一台备份服务器,浪费资源
(2)需要多个虚拟IP
(3)agent可能意外终止,引起裂脑。
2.MHA
介绍
MHA(Master High Availability)
目前在MySQL
高可用方面是一个相对成熟的解决方案,它由日本DeNA
公司youshimaton
(现就职于Facebook
公司)开发,是一套优秀的作为MySQL
高可用性环境下故障切换和主从提升的高可用软件。在MySQL
故障切换过程中,MHA
能做到在0~30秒
之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA
能在最大程度上保证数据的一致性,以达到真正意义上的高可用。
2.1MHA
架构介绍
该软件由两部分组成:MHA Manager
(管理节点)和MHA Node
(数据节点)。MHA Manager
可以单独部署在一台独立的机器上管理多个master-slave
集群,也可以部署在一台slave
节点上。MHA Node
运行在每台MySQL
服务器上,MHA Manager
会定时探测集群中的master
节点,当master
出现故障时,它可以自动将最新数据的slave
提升为新的master
,然后将所有其他的slave
重新指向新的master
。整个故障转移过程对应用程序完全透明。
在MHA
自动故障切换过程中,MHA
试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失(配合mysql
半同步复制效果更佳),但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh
访问,MHA
没法保存二进制日志,只进行故障转移而丢失了最新的数据。使用MySQL 5.5
的半同步复制,可以大大降低数据丢失的风险。MHA
可以与半同步复制结合起来。如果只有一个slave
已经收到了最新的二进制日志,MHA
可以将最新的二进制日志应用于其他所有的slave
服务器上,因此可以保证所有节点的数据一致性。
注意:目前MHA
主要支持一主多从的架构,要搭建MHA
,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master
,一台充当备用master
,另外一台充当从库,因为至少需要三台服务器,出于机器成本的考虑,淘宝也在该基础上进行了改造,目前淘宝TMHA
已经支持一主一从。
2.2MHA
架构图
正常工作时架构图:
主库down
机时架构:
2.3.故障转移过程
(1)从宕机崩溃的master
保存二进制日志事件(binlog events)
;
(2)识别含有最新更新的slave
;
(3)应用差异的中继日志(relay log)
到其他的slave
;
(4)应用从master
保存的二进制日志事件(binlog events)
;
(5)提升一个slave
为新的master
;
(6)使其他的slave
连接新的master
进行复制;
(7)在新的master
启动vip
地址,保证前端请求可以发送到新的master
。
2.4MHA
优点
(1)不需要备份服务器
(2)不改变现有环境
(3)操作非常简单
(4)可以进行日志的差异修复
(5)可以将任意slave提升为master
2.5MHA
缺点
(1)需要全部节点做ssh
秘钥
(2)MHA
出现故障后配置文件会被修改,如果再次故障转移需要重新修改配置文件。
(3)自带的脚本还需要进一步补充完善,且用perl
开发,二次开发困难。
3.DRBD+(heartbeat,corosync)
3.1方案简介
本方案采用Heartbeat
或者corosync
双机热备软件来保证数据库的高稳定性和连续性,数据的一致性由DRBD
这个工具来保证(如果可以尽量放到分布式存储上面)。默认情况下只有一台mysql
在工作,当主mysql
服务器出现问题后,系统将自动切换到备机上继续提供服务,当主数据库修复完毕,又将服务切回继续由主mysql
提供服务。
3.2组件
Heartbeat,corosync
作为心跳检测机制,监控primary
节点的状态。当主节点宕掉之后,迅速提升secondary
节点为新的主节点,并切换IP
;
**drbd
**负责数据同步。
3.3架构图
3.4数据同步过程
mysql
进行刷盘时,会通过不同的sync
方式,最终将数据写入disk
;
drbd
收到刷盘成功的信息后,将对应的磁盘块位置,和变更动作,通过网络传递至secondary
节点;
secondary
的drbd
接收到变更信息后,将这些信息落盘。
3.5切换过程
前提:secondary
节点的mysql
服务不启动;
heartbeat
检测到primary
的mysql
服务停止,则摘掉IP
、umount
掉数据盘、将primary
切换为secondary
;
在原来的secondary
上,提升drbd
同步为primary
,挂载数据盘,启动mysql
服务、绑定IP
;
从库跟着IP
和端口自动进行迁移。
3.6方案优点
(1)历史悠久、安全性高、稳定性高、可用性高、出现故障自动切换。
(2)数据一致性强。
3.7方案缺点
(1)需要一台备份服务器,浪费资源。
(2)不方便扩展。
(3)无论drbd
还是headbetart
,corosync
都可能发生裂脑。
4.Mysql route
介绍
4.1什么是mysql route
MySQL Router
是处于应用client
和dbserver
之间的轻量级代理程序,它能检测,分析和转发查询到后端数据库实例,并把结果返回给client
。是mysql-proxy
的一个替代品。其架构图和功能如下。
(1)Router
实现读写分离,程序不是直接连接数据库IP
,而是固定连接到mysql router
。MySQL Router
对前端应用是透明的。应用程序把MySQL Router
当作是普通的mysql
实例,把查询发给MySQL Router
,而MySQL Router
会把查询结果返回给前端的应用程序。
(2)从数据库服务器故障,业务可以正常运行。由MySQL Router
来进行自动下线不可用服务器。程序配置不需要任何修改。
(3)主数据库故障,由MySQL Router
来决定主从自动切换,业务可以正常访问。程序配置不需要做任何修改。
4.2读写分离原理
MySQL Router
接受前端应用程序请求后,根据不同的端口来区分读写,把连接读写端口的所有查询发往主库,把连接只读端口的select
查询以轮询方式发往多个从库,从而实现读写分离的目的。读写返回的结果会交给MySQL Router
,由MySQL Router
返回给客户端的应用程序。
4.3Mysql router
用途
MySQL Router
的主要用途是读写分离,主主故障自动切换,负载均衡,连接池等。
4.4Mysql router
主主故障自动切换的坑
Mysql router
主主故障切换功能经过测试没有问题,但是有一个比较大的坑需要注意,主库发生切换之后,从库的连接的master
服务器地址不会发生改变,需要自己写脚本进行判断。
4.5优点
(1)基于DAL
层实现mysql
的高可用。
(2)可以同时实现主主故障切换和读写分离。
(3)插件式架构允许用户进行额外的功能扩展。
4.6缺点
(1)高可用功能需要进一步完善:存在主库切换之后,从库不会自动切换主库地址的坑。
(2)读写情况使用不同端口,需要修改应用程序。
5.mysql Cluster
国内用的非常少,主要因为一下三点:
(1)需要更改存储引擎
(2)付费
(3)国内几乎没有使用案例
优点:
高可用,可用率达99.999%