mysql高可用架构了解
转自:https://www.cnblogs.com/gomysql/p/3675429.html,https://www.cnblogs.com/gomysql/p/3671896.html
https://cloud.tencent.com/developer/article/1031542
1.MHA
MHA(Master High Availability),是MySQL高可用性环境下故障切换和主从提升的高可用软件。能做到在0~30秒之内自动完成数据库的故障切换操作,在最大程度上保证数据的一致性,以达到真正意义上的高可用。两部分组成:
- MHA Manager(管理节点);MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。
- MHA Node(数据节点);MHA Node运行在每台MySQL服务器上。
MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。
MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失。但有风险,如果原主服务硬件故障(InnoDB数据文件损坏)或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失了最新的数据,可以与半同步复制结合起来,降低数据丢失的危险。
目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当从库。
MHA工作原理:
(1)从宕机崩溃的master保存二进制日志事件(binlog events);
(2)识别含有最新更新的slave;通过对比slave之间I/O线程读取master binlog的位置,选取最接近的slave做为latest slave。
(3)应用差异的中继日志(relay log)到其他的slave;其它slave通过与latest slave对比生成差异中继日志。【这一步是保证所有slave先对齐?】
(4)在最新的slave上应用从master保存的二进制日志事件(binlog events);
(5)提升一个slave为新的master;
(6)使其他的slave连接新的master进行复制;在其它slave上应用相应的差异中继日志并开始从新的master开始复制。
缺点:
- 需要在各个节点间打通ssh信任,这对某些公司安全制度来说是个挑战,因为如果某个节点被黑客攻破的话,其他节点也会跟着遭殃;
- 高可用依赖于vip(虚拟ip)的方案,譬如采用keepalive来达到vip的切换,但是keepalive会限制切换的主机必须在一个网段,对于跨机房不在一个网段的服务器来说,就无法支持了。
2.MMM
MMM(Master-Master replication manager for MySQL),双主复制,支持双主故障切换和双主日常管理的脚本程序。虽然叫做双主复制,但是业务上同一时刻只允许对一个主进行写入,另一台备选主上提供部分读服务,以加速在主主切换时刻备选主的预热。MMM无法完全的保证数据一致性,但可最大程度的保证业务可用性。
做到高可用,但由于双主所以无法强一致?