MySQL 同步复制及高可用方案总结

标签: mysql linux centos | 发表时间:2019-10-15 15:41 | 作者:民工哥
出处:https://segmentfault.com/blogs

1.前言

mysql作为应用程序的数据存储服务,要实现mysql数据库的高可用。必然要使用的技术就是数据库的复制,如果主节点出现故障可以手动的切换应用到从节点,这点相信运维同学都是知道,并且可以实现的。但是这种情况只是手动的切换,对可用性有要求的业务需要分别实现主库和从库的高可用,保障在数据库出现down机的情况下,可以自动实现数据库的故障转移,保障应用的可用性和用户体验。

本文将会对一些常用的数据库高可用方案进行介绍,根据你不同的场景,选择合适的高可用方案即可。

2.MMM高可用方案

2.1.Mysql-MMM介绍

MMM(Master-Master replication managerfor Mysql,Mysql主主复制管理器)是一套灵活的脚本程序,基于perl实现,用来对mysql replication进行监控和故障迁移,并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)。

2.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用户。

2.3.架构图

正常工作时:

主节点故障时:
微信图片_20191015154036.png

2.4.MMM优点

(1)高可用性,扩展性好,出现故障自动转移,对于主主同步,在同一时间只提供一台数据库写操作,保证数据的一致性。
(2)配置简单,容易操作。

2.5.MMM缺点

(1)需要一台备份服务器,浪费资源
(2)需要多个虚拟IP
(3)agent可能意外终止,引起裂脑。

3.MHA介绍

MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。

3.1.MHA架构介绍

该软件由两部分组成: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已经支持一主一从。

3.2.MHA架构图

正常工作时架构图:
微信图片_20191015154220.png

主库down机时架构:
微信图片_20191015154249.png

3.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。

3.4.MHA优点

(1)不需要备份服务器
(2)不改变现有环境
(3)操作非常简单
(4)可以进行日志的差异修复
(5)可以将任意slave提升为master

3.5.MHA缺点

(1)需要全部节点做ssh秘钥
(2)MHA出现故障后配置文件会被修改,如果再次故障转移需要重新修改配置文件。
(3)自带的脚本还需要进一步补充完善,且用perl开发,二次开发困难。

4.DRBD+(heartbeat,corosync)

4.1.方案简介

本方案采用Heartbeat或者corosync双机热备软件来保证数据库的高稳定性和连续性,数据的一致性由DRBD这个工具来保证(如果可以尽量放到分布式存储上面)。默认情况下只有一台mysql在工作,当主mysql服务器出现问题后,系统将自动切换到备机上继续提供服务,当主数据库修复完毕,又将服务切回继续由主mysql提供服务。

4.2.组件

Heartbeat,corosync作为心跳检测机制,监控primary节点的状态。当主节点宕掉之后,迅速提升secondary节点为新的主节点,并切换IP;
drbd负责数据同步

4.3.架构图
微信图片_20191015154253.jpg

4.4.数据同步过程

mysql进行刷盘时,会通过不同的sync方式,最终将数据写入disk;
drbd收到刷盘成功的信息后,将对应的磁盘块位置,和变更动作,通过网络传递至secondary节点;

secondary的drbd接收到变更信息后,将这些信息落盘;

4.5.切换过程

前提:secondary节点的mysql服务不启动;

heartbeat检测到primary的mysql服务停止,则摘掉IP、umount掉数据盘、将primary切换为secondary;

在原来的secondary上,提升drbd同步为primary,挂载数据盘,启动mysql服务、绑定IP;

从库跟着IP和端口自动进行迁移;

4.6.方案优点

(1)历史悠久、安全性高、稳定性高、可用性高、出现故障自动切换。
(2)数据一致性强

4.7.方案缺点

(1)需要一台备份服务器,浪费资源
(2)不方便扩展
(3)无论drbd还是headbetart,corosync都可能发生裂脑

5.Mysql route介绍

5.1.什么是mysql route

MySQL Router是处于应用client和dbserver之间的轻量级代理程序,它能检测,分析和转发查询到后端数据库实例,并把结果返回给client。是mysql-proxy的一个替代品。其架构图和功能如下。
微信图片_20191015154257.png

(1)Router实现读写分离,程序不是直接连接数据库IP,而是固定连接到mysql router。MySQL Router对前端应用是透明的。应用程序把MySQL Router当作是普通的mysql实例,把查询发给MySQL Router,而MySQL Router会把查询结果返回给前端的应用程序。

(2)从数据库服务器故障,业务可以正常运行。由MySQL Router来进行自动下线不可用服务器。程序配置不需要任何修改。

(3)主数据库故障,由MySQL Router来决定主从自动切换,业务可以正常访问。程序配置不需要做任何修改。

5.2.读写分离原理

MySQL Router接受前端应用程序请求后,根据不同的端口来区分读写,把连接读写端口的所有查询发往主库,把连接只读端口的select查询以轮询方式发往多个从库,从而实现读写分离的目的。读写返回的结果会交给MySQL Router,由MySQL Router返回给客户端的应用程序。

5.3.Mysql router用途

MySQL Router的主要用途是读写分离,主主故障自动切换,负载均衡,连接池等。

5.4.Mysql router主主故障自动切换的坑

Mysql router主主故障切换功能经过测试没有问题,但是有一个比较大的坑需要注意,主库发生切换之后,从库的连接的master服务器地址不会发生改变,需要自己写脚本进行判断。

5.5.优点

(1)基于DAL层实现mysql的高可用。
(2)可以同时实现主主故障切换和读写分离。
(3)插件式架构允许用户进行额外的功能扩展。

5.6.缺点

(1)高可用功能需要进一步完善:存在主库切换之后,从库不会自动切换主库地址的坑。
(2)读写情况使用不同端口,需要修改应用程序。

6.mysql Cluster

国内用的非常少,主要因为一下三点:
(1)需要更改存储引擎
(2)付费
(3)国内几乎没有使用案例

优点:
高可用,可用率达99.999%

6.1.结束语

上面的高可用方案,只是我自己比较熟悉的,而且也是应用比较多的。mysql毕竟发展了有20多年了,各种高可用方案还是很多的,其他的高可用方案各位钥匙有兴趣,可以自己研究。

版权申明:作者:西门飞冰,一名90后it男,一直在北京工作,热爱运动,热爱冒险,热爱旅行。由作者原创投稿,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意,谢谢。

关注 民工哥技术之路 微信公众号对话框回复关键字:1024 可以获取一份最新整理的技术干货:包括系统运维、数据库、redis、MogoDB、电子书、Java基础课程、Java实战项目、架构师综合教程、架构师实战项目、大数据、Docker容器、ELK Stack、机器学习、BAT面试精讲视频等。

相关 [mysql 同步 复制] 推荐:

MySQL半同步复制(Semisynchronous Replication)

- - IT技术博客大学习
MySQL5.5引入了半同步复制(Semi-synchronous Replication),以下是对于半同步复制的认知和理解:. 半同步启动需要主从两端都需要加载安装各自对应的semi模块,从库端支持半同步功能的数量至少一台;主库端当一个事务成功提交后,并不及时反馈给前端用户,该线程会被临时block,等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt(回执确认),这时主库线程才返回给当前session告知操作完成,半同步复制并不关心在从库一端该事务是否都被执行并被提交完成.

MySQL中的半同步复制

- - 学习日志
MySQL当前存在的三种复制模式有:异步模式、半同步模式和组复制模式. 注意:MySQL复制模式没有“同步复制”这一项的,文章中只是为了读者方便理解半同步复制的概念才介绍了同步复制概念 https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html.

MySQL的主从复制、半同步复制、主主复制详解

- - 学习笔记
复制其最终目的是让一台服务器的数据和另外的服务器的数据保持同步,已达到数据冗余或者服务的负载均衡. 一台主服务器可以连接多台从服务器,并且从服务器也可以反过来作为主服务器. 主从服务器可以位于不同的网络拓扑中,由于mysql的强大复制功能,其复制目标可以是所有的数据库,也可以是某些数据库,甚至是某个数据库中的某些表进行复制.

MySQL 同步复制及高可用方案总结

- - SegmentFault 最新的文章
mysql作为应用程序的数据存储服务,要实现mysql数据库的高可用. 必然要使用的技术就是数据库的复制,如果主节点出现故障可以手动的切换应用到从节点,这点相信运维同学都是知道,并且可以实现的. 但是这种情况只是手动的切换,对可用性有要求的业务需要分别实现主库和从库的高可用,保障在数据库出现down机的情况下,可以自动实现数据库的故障转移,保障应用的可用性和用户体验.

JAVA通过Gearman实现MySQL到Redis的数据同步(异步复制)

- - 企业架构 - ITeye博客
MySQL到Redis数据复制方案. 无论MySQL还是Redis,自身都带有数据同步的机制,像比较常用的 MySQL的Master/Slave模式 ,就是由Slave端分析Master的binlog来实现的,这样的数据复制其实还是一个异步过程,只不过当服务器都在同一内网时,异步的延迟几乎可以忽略.

mysql主从复制

- - SQL - 编程语言 - ITeye博客
从库的配置,mysql5.5不支持配置文件的配置了,问了数据库的人,用命令行指定. 修改从库的配置 #default-storage-engine = InnoDB #修改 default-storage-engine = blackhole server-id = 11215004 #新增 replicate-do-db = test log-bin = mysql-bin #新增 binlog_format = row.

MySQL 双活同步复制的四种方案_咸鱼的梦想专栏-CSDN博客_mysql双机同步复制

- -
对于数据实时同步,其核心是需要基于日志来实现,是可以实现准实时的数据同步,基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束. 基于MySQL原生复制主主同步方案  . 这是常见的方案,一般来说,中小型规模的时候,采用这种架构是最省事的. 两个节点可以采用简单的双主模式,并且使用专线连接,在master_A节点发生故障后,应用连接快速切换到master_B节点,反之也亦然.

同步mysql数据到hive

- - ITeye博客
地址为:http://archive.cloudera.com/cdh/3/下载相应版本,如sqoop-1.2.0-CDH3B4.tar.gz. 地址为:http://archive.cloudera.com/cdh/3/,版本可以为hadoop-0.20.2-CDH3B4.tar.gz. 3.解压 sqoop-1.2.0-CDH3B4.tar.gz ,hadoop-0.20.2-CDH3B4.tar.gz 到某目录如/home/hadoop/,解压后的目录为.

MySQL主从复制配置

- - 天空极速
在实际企业应用环境当中,单台MySQL数据库是不足以满足日后业务需求的. 譬如服务器发生故障,没有备份服务器来提供服务的话,业务就得停止. 使用MySQL主从复制的好处有:. 1、采用主从服务器这种架构,稳定性得以提升. 如果主服务器发生故障,我们可以使用从服务器来提供服务;. 2、在主从服务器上分开处理用户的请求,可以提升数据处理效率;.