Mysql高可用架构方案

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。

[toc]

Mysql 介绍

Mysql是典型的开源关系型数据库,是许多网站、应用程序、企业软件产品的首选数据库。

Mysql特性:

  • 易于使用,功能强大,支持事务、触发器、存储过程
  • 管理工具多种多样且功能丰富
  • 可以作为千万级数据管理的大型数据库
  • 采用GPL开源协议,允许自由修改源码并应用到商业系统中
  • Mysql的InnoDB事务性存储引擎符合事务ACID模型,能保证完整、可靠地进行数据地存储

高可用结构

  • 主从模式

  • MHA

  • MMM

  • MGR

主从模式

主从模式介绍

主从模式是最基本的Mysql高可用架构,一台服务器作为Master节点,若干服务器作为Slave节点。只有Master处理写数据请求,读请求可仅由Slave节点处理,也可让Master、Slave同时处理。

Master和Slave通过主从复制技术保持数据一致,即Master节点将数据同步给Slave节点。

当Master发生故障的时候,从Slave中选举一个新的Master。

主从模式具备高可用的基础是主从复制技术。

主从复制技术

  • 当Master 数据发生变更(新增、删除、修改)时,Master将变更日志写入二进制日志文件 binlog
  • Slave启动单独线程(I/O线程)与Master建立网络连接,从Master的binlog中获取变更日志
  • Slave的I/O线程捕获到数据变更日志后,按照顺序保存到中继日志文件 relay log
  • Slave启动单独线程(Sql线程)从relay log 中读取日志并执行,使Slave 库的数据和Master一致

主从复制.png

主从模式注意事项

Mysql 5.5之前主从复制为异步方式,Master 提交事务不需要经过Slave 们的确认,那么就会有这种极端情况:

  • Slave 读取Master 的binlog失败了
  • Slave 处理relay log 失败了
  • Slave 执行Sql语句失败了
  • 等......

类似的极端情况将导致数据不一致。所以在Mysql 5.5 主从复制提供了半同步的方式,具体来说就是增加了ACK确认的机制,当Slave接收到binlog 后,会给Master 发送一条确认消息,Master在接收到ACK确认消息之后才会提交事务。半同步方式可以提高数据的一致性,但是Master在写入数据的时候需要等待Slave的确认,所以性能会有所下降。

复制风暴问题,来考虑这样一种更加极端的情况,一个Master ,10个Slave , 这种情况下基于主从复制技术,Master在写入数据前需要同时处理10个Slave的数据复制请求,这种情况下对于Master只能说是不堪重负,如果在加上“半同步机制”,写入性能将大打折扣,这种情况称之为复制风暴问题。解决这种问题的方法是,Master 仅处理一个Slave的主从复制,其它的Slave复制由Slave负责。

MHA(MasterHighAvailability)

MHA模式介绍

以主从模式为基础,接下来就该考虑如下问题了:

  • 如何检测节点故障
  • master节点故障之后如何重新选举

MHA就是在解决这两个问题的,理论上,MHA模式可以在10s-30s内完成主从集群的自动故障检测和自动主从切换。

MHA由两个部分组成:

  • MHA-Manager:负责自动检测Master是否故障,检查主从复制状态,执行自动主从切换等。需要单独服务器部署。
  • MHA-Node:负责修复主从数据的差异,通常和Mysql服务器实例绑定部署。

MHA工作流程

  • Manager 和 Master之间心跳,如果连续4次探测不到心跳,就认为该Master宕机了,Master实例绑定一个Node。
  • Manager 分析各个Slave的binlog,选择一个更接近Master数据的Slave作为备选Master,一个Slave实例分别绑定一个Node。
  • Slave的Node试图通过SSH访问Master所在服务器:
    • 如果可达,Slave的Node获取Master的binlog数据,若发现Master和Slave数据存在差异,会将差异数据主动复制到Slave,以保持主从数据一致。
    • 如果不可达,Node对比各个Slave的relay log 差异,并做差异数据补齐。
  • Manager将备选Master提升为Master。

MMM(Multi-MasterReplicationManagerForMysql)

MMM模式简单来说就是引入虚拟IP(vip)技术,这种架构下,一个集群中有两个Master和若干个Slave,当其中一个Master不可用的时候,MMM会指示vip切换到另外一个Master上面,同时会向所有的Slave发送更换Master的消息,之后主从复制将切换到新的Master。

此方案比较古老,不支持Mysql GTID ,并且社区活跃度不够,目前处于无人维护的状态。

MGR(MysqlGroupReplication)

MGR,Mysql组复制模式是Mysql5.7.17版本推出的高可用解决方案,具备如下特性:

  • 一致性高:数据复制基于分布式共识算法Paxos,可以保证多个节点数据的一致性
  • 容错性高:只要不是超过一半的节点宕机,就可以继续提供服务
  • 灵活性强:MGR支持单主模式和多主模式,单主模式下如果Master故障,Slave们会重新选举一个新的Master,多主模式下每一个Mysql节点都可以同时处理写请求

MGR要求至少由3个Mysql节点组成一个复制组,即一主两从,一个事务必须经过复制组内超过半数节点通过后才能提交。

如果在不同的Mysql节点上执行不同的写操作发生了事务冲突,那么先提交的事务先执行,后提交的事务被回滚。在多主模式下,由于每个Mysql节点都可以执行写请求,在写请求高并发的场景下发生事务冲突的概率会非常大,会造成大量事务回滚。

在单主模式下,MGR会自动为复制组选择一个Master负责写请求,如果复制组内超过一半节点与Master通信失败,就认为Master宕机了,这时会根据各个节点的权重和ID标识重新选主。

MGR更加适合一致性强,写并发量不大的场景下使用。

总结

本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
7天前
|
SQL 存储 缓存
【赵渝强老师】MySQL的体系架构
本文介绍了MySQL的体系架构,包括Server层的7个主要组件(Connectors、Connection Pool、Management Service & Utilities、SQL Interface、Parser、Optimizer、Query Caches & Buffers)及其作用,以及存储引擎层的支持情况,重点介绍了InnoDB存储引擎。文中还提供了相关图片和视频讲解。
【赵渝强老师】MySQL的体系架构
|
13天前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
12天前
|
关系型数据库 MySQL
mysql 5.7.x版本查看某张表、库的大小 思路方案说明
mysql 5.7.x版本查看某张表、库的大小 思路方案说明
37 5
|
17天前
|
Kubernetes 关系型数据库 MySQL
Kubernetes入门:搭建高可用微服务架构
【10月更文挑战第25天】在快速发展的云计算时代,微服务架构因其灵活性和可扩展性备受青睐。本文通过一个案例分析,展示了如何使用Kubernetes将传统Java Web应用迁移到Kubernetes平台并改造成微服务架构。通过定义Kubernetes服务、创建MySQL的Deployment/RC、改造Web应用以及部署Web应用,最终实现了高可用的微服务架构。Kubernetes不仅提供了服务发现和负载均衡的能力,还通过各种资源管理工具,提升了系统的可扩展性和容错性。
51 3
|
17天前
|
关系型数据库 MySQL
mysql 5.7.x版本查看某张表、库的大小 思路方案说明
mysql 5.7.x版本查看某张表、库的大小 思路方案说明
25 1
|
5天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
3天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
3天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
14 1
服务架构的演进:从单体到微服务的探索之旅
|
2天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
19 5
|
5天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
22 7

相关产品

  • 云数据库 RDS MySQL 版