mysql高可用架构

高可用



 

高可用(High Availabiltity)

  • 应用提供持续不间断(可用)的服务的能力
  • 系统高可用性的评价通常用可用率表示

造成不可用的原因

  • 硬件故障(各种)
  • 预期中的系统软硬件维护
  • 软件缺陷(应用代码,服务程序都可能存在bug)
  • 攻击,泄露,认为失误...等安全事件
  • 对于系统来说,不可用时间是各关键组件不可用时间的总和.....

提高可用性的主要手段

  • 冗余,Redundancy
  • 关键软硬件通过备用冗余避免故障时长时间的不可用
  • 数据软件,硬件,存储的数据,都需要通过冗余确保故障时可替换

mysql高可用常见方案:

  • 数据库服务在冗余实现上有其特殊性
    • 数据:服务"有状态"与数据冗余
    • 数据库可用性考虑两部分:数据可用性,服务可用性;
  • 实现方式多种多样,同一种数据也会有多种实现方案
  • 可用性目标循序渐进
    • 任何故障都不会造成数据丢失->可以较快速恢复服务(高可用)

高可用方案



 

1.mysql--基于共享存储的单活方案(不常用)

  • SAN,方案比较昂贵;因此不常用;
  • 且数据库备用机,只是机器活着,但是没有没有起mysql服务;
    • 因为大部分共享存储或数据库是不允许同一份数据被不同数据使用的;
  • 本地数据通过RAID等手段保证数据安全

2.基于存储复制的数据冗余单活(不常用)

  • 存在一定浪费,备用机器一直不在用,等待主机挂掉,才会使用备用机;
  • 而且DRBD(两台机器间通过网络,备份数据),不是100%的保证数据不丢失;

3.基于集群提交通信协议的多主复制(一定场景适用)

基于主从复制的高可用方案


 

4.基于Mysql主从复制(常用,普适)

  • 备库,在线上也会提供服务,避免浪费;
  • 而主从复制,也保证了数据不会丢失。

mysql主从复制高可用方案需要改进的问题

  1. 主从服务器各自有IP地址,发生主从切换后应用需要修改重启;

    • 如何让应用快速找到从库;VIP/DNS
  2. 人工判断主库是否故障再发起切换需要花较多时间
    • 如何自动探知;监控探知并自动VIP/DNS;
  3. 主从复制存在客观延迟,切换后可能造成事务数据丢失。
    • 由于网络延时,如何避免数据丢失。

1.为了避免应用人工修改切换IP,引入VIP(virtual ip)漂移方案:

方案二:

DNS,应用服务器,使用域名;

平时,将域名注册在主库上,而主库挂掉,将域名注册到从库就可以了;

2.为了减少人工介入处理的时间开销引入自动探活处理机制

高可用中间层与RDS

  • VIP/DNS解决 应用切换问题
  • 监控和管理服务器解决自动判断故障切换和VIP/DNS漂移
  • VIP/DNS管理+探活+主从关系切换 = 高可用中间层
    • 透明切换管理+靠谱数据探活+使用切换 = 高可用中间层
  • 云环境+高可用中间层+底层数据库=一种PaaS=基本RDS、

高可用中间层

  • MHA
    • 自动选择复制延迟最小的从节点并试图补全日志(但大部分主机故障下行不通)
    • 通常要求两从以上,会进行主从关系切换
    • 不提供VIP管理方案
  • MMM
    • 提供了基本的VIP管理功能
    • 适合双主配置的一对主机,不会主动切换主从关系
    • 不支持主从数据延迟判断和补全

一般使用MHA,开源;

3.mysql主从复制延迟

为什么日志传输延迟

为什么主从复制,主从库会数据不一致;

解决方案:

mysql半同步技术:

主库一次commit,要等到主库持久化完成,以及从库也持久化完成,才给主键放回commit成功。

但是问题:

主库等待从库的时间是不可控的;

主库发现从库写不进去了,可以等待几秒,之后主库复制自动降级成异步复制;但这也可能导致数据不一致;

较完善的mysql高可用方案

  • 半同步复制+高可用中间层+VIP管理方案
  • 高可用中间层=靠谱探活+主从切换+使用VIP管理的接口

例如:

  • 半同步复制+MHA(高可用中间层)+Keeplive(VIP管理方案)
  • 半同步复制+RDS

总结


  • 高可用指标至少3个9目标4个9
  • 高可用核心就是使用冗余
  • 数据库高可用两个部分
    • 数据可用性--数据有状态
    • 服务可用性
  • 高可用方案
    • 基于共享存储SAN的单活方案
      • SAN,设备昂贵
      • 单活,备用机浪费,因为同一份数据不能被不同mysql实例使用;
      • 本地数据可以通过RAID等手段保证
    • 基于DRBD存储复制的数据冗余单活
      • 基于SAN方案的改进,不使用SAN设备
      • 单活,备用机浪费
      • DRBD基于两台机器间通过网络备份数据,数据不能100%保证
    • 多主复制--mysql cluster
  • 基于mysql主从复制(常用,普适)
    • 备份,在线上可提供只读服务,避免浪费;
    • 主从复制,也保证了数据不会丢失
  • 基于mysql主从复制的问题
    • 主从服务器各有IP地址,发生主从切换后应用需要修改重启;
      • 使用VIP(virtual IP)/DNS管理方案,当发生切换是,只需要将VIP从主库漂移到从库,对应用来说是透明的。
    • 人工判断主库是否故障,在发起切换需要时间长
      • 使用监控服务器,自动靠谱探知+自动主从切换
    • 主从复制存在客观延迟,切换后可能造成事务数据丢失
      • 使用半同步复制技术,但也要考虑到从库宕机,主库应该自动降级成异步复制;
    • 解决问题后的mysql高可用方案
      • VIP管理方案+高可用中间层+半同步复制
  • 高可用中间层
    • VIP/DNS管理+靠谱探活+主从关系切换=高可用中间层
    • 云环境+高可用中间层+底层数据库=一种paas=基本RDS
    • MHA/MMM
  • MHA
    • 自动选择复制延迟最小的从节点并试图补全日志(主机故障下行不通)
    • 自动探活
    • 自动主从切换
    • 不提供VIP管理方案,但提供使用VIP方案的接口
时间: 2024-10-09 07:35:40

mysql高可用架构的相关文章

15、 Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节

15. Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节 参考自:http://oldboy.blog.51cto.com/2561410/1240412 heartbeat和keepalived应用场景及区别 很多网友说为什么不使用keepalived而使用长期不更新的heartbeat,下面说一下它们之间的应用场景及区别: 1.对于web,db,负载均衡(lvs,haproxy,nginx)等,heartbeat和keepalived都可以实现 2.lvs最好和keepa

MySQL 高可用架构在业务层面的应用分析

MySQL 高可用架构在业务层面的应用分析 http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&idx=1&sn=f9a0d03dd9a1cf3b3575c0241291e421&scene=22&srcid=seLU5tmZumKLzwVBIHzM#rd http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&am

MySQL高可用架构之MHA (未完,待续)

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

mysql高可用架构谁能提供具体实践实例!!!

mysql高可用架构目前只查到4中解决方案,如下所示,但是没有具体实践,看到本博客的大神们,能不能给我提供一些实践的实例,谢谢!!!!! 1  Lvs+keeplived+mysql 的方案 单点写入读负载均衡主主同步高可用方案 2 Heartbeat 高可用MySQL 主主同步方案 3 Heartbeat+DRBD+mysql 高可用方案 4 MMM 高可用 mysql 方案

整个MHA+keepalived+lvs+mysql高可用架构配置说明

整个MHA+keepalived+lvs+mysql高可用架构配置说明1.1. 环境简介1.1.1.vmvare虚拟机,系统版本CentOS7.5 x86_64位最小化安装,mysql的版本5.7.21,1.1.2.虚拟机器的ssh端口均为默认22,1.1.3.虚拟机的iptables全部关闭,1.1.4.虚拟机的selinux全部关闭,1.1.5.虚拟机服务器时间全部一致 ntpdate 0.asia.pool.ntp.org1.1.6.3台机器的ssh端口为22**1.2.此次试验采用的是3

mysql高可用架构设计

主要介绍:复制功能介绍.mysql二进制日志.mysql复制拓扑.高可用框架.单点故障.读写分离和负载均衡介绍等 mysql复制功能提供分担读负载 复制解决的问题 实现在不同服务器上的数据分布 利用二进制日志增量进行 不需要太多的带宽 但是使用基于行的复制在进行大批量的更改时会对带宽带来一定得压力,特别是跨IDC环境下进行复制 实现在不同服务器上的数据分布 实现数据读取的负载均衡 需要其他组件配合完成 利用DNS轮询的方式把程序的读连接到不同的备份数据库, 使用LVS,haproxy这样的代理方

探索MySQL高可用架构之MHA(7)

-----构建mysql高可用系列(共9篇) 上一篇文章介绍了本次架构的keepalive读写分离! 本篇文章主要介绍本次架构中的mha安装部分! 关于MHA MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于 Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在 0~30秒之内自动完成数据库的故

探索MySQL高可用架构之MHA(4)

-----构建mysql高可用系列(共9篇) 上一篇文章介绍了本次架构中的Mysql源码安装.本篇文章主要介绍本次架构中的ABBB复制. 首先我们先介绍什么是MySql AB复制???? AB复制又称主从复制,实现的是数据同步.如果要做MySQL AB复制,数据库版本尽量保持一致.如果版本不一致,从服务器版本高于主服务器,但是版本不一致不能做双向复制. MySQL AB复制有什么好处呢? a.解决宕机带来的数据不一致,因为MySQL AB复制可以实时备份数据. b.减轻数据库服务器压力,这点很容

探索MySQL高可用架构之MHA(6)

-----构建mysql高可用系列(共9篇) 上一篇文章介绍了本次架构的Atlas读写分离! 本篇文章主要介绍本次架构中的keepalive部分! 什么是Keepalived呢???? keepalived是一款c语言写的实现在linux系统上实现负载均衡和高可用的软件.它遵从于GNU是一款优秀的开源软件.keepalived观其名可知,保持存活,在网络里面就是保持在线了,也就是所谓的高可用或热备,用来防止单点故障的发生. 两个关键词的解释 负载均衡 keepalived内置了对ipvs函数的调

MySQL 高可用架构之MMM

简介 MMM(Master-Master replication manager for MySQL)是一套支持双主故障切换和双主日常管理的脚本程序.MMM使用Perl语言开发,主要用来监控和管理MySQL Master-Master(双主)复制,虽然叫做双主复制,但是业务上同一时刻只允许对一个主进行写入,另一台备选主上提供部分读服务,以加速在主主切换时刻备选主的预热,可以说MMM这套脚本程序一方面实现了故障切换的功能,另一方面其内部附加的工具脚本也可以实现多个slave的read负载均衡. M