• MYSQL数据库高可用方案探究


    MySQL作为最关键的应用数据存储中心,如何保证MySQL服务的可靠性和持续性,是我们不得不细致考虑的一个问题。当master宕机的时候,我们如何保证数据尽可能的不丢失,如何保证快速的获知master宕机并进行相应的故障转移处理,都需要仔细考虑与规划。

    要保证MySQL数据不丢失,replication是一个很好的解决方案,而MySQL提供了一套强大的replication机制,replication能极大地提升数据安全,异步复制的方式也保证了sql读写性能不受太大影响。在大量企业长期的使用和实践中,已经形成多套可靠的mysql高可用方案,如: keepalived+replication,MHA, MMM, heartbeat+共享存储,mysql cluster等等。

    HA的三种工作方式:

    (1)主备方式

    工作原理:主机工作,备机处于准备状况;当主机宕机时,可以配置备机接管主机的一切工作,待主机恢复正常后,再按使用者的设定是否将服务切换到主机上运行,mysql自带的replication就是这样的一种工作方式。

    (2)双机互备方式

    工作原理:两台主机同时运行服务工作且相互检测服务可用性,当任一台主机宕机时,另一台主机立即接管它的一切工作,保证业务连续性和可靠性,该双机热备方式需要第三方HA软件的支持,如keepalived,heartbeat,以及ROSEHA等商业软件。

    (3)集群工作方式

    工作原理:多台主机一起工作,运行同样的一个或几个服务,各服务定义一个或多个备用主机或实行负载均摊,当某个主机故障时,运行在其上的服务就可以被其它主机接管,集群内任何一个主机宕机不影响业务的持续性。Mysql cluster 就是这样的集群工作方式。

    先介绍以下为几种常见的mysql高可用方案:

    方案一: 

    MYSQL+REPLICATION

    方案概述:

    MySQL复制基于主服务器在二进制日志中记录所有对数据库的更改(更新、删除等等)。因此,要进行复制,必须在主服务器上启用二进制日志 每个从服务器从主服务器接收二进制日志并保存到本地文件中,即中继日志。从服务器SQL线程读取中继日志并执行日志中包含的更新,从而使本地数据与主服务器保持一致。

    方案拓扑:

    image_thumb[1]

    优点:

    成本低、经济实惠、后期维护方便,整套系统架构简单,故障率低,便于实现读写分离。

    缺点:

    不能实现故障自动转移,需要人工干涉主从切换,更改应用层的数据库IP地址。

     

    方案二:

           MYSQL+KEEPALIVED/HEARTBEAT+共享存储

    方案概述:

    本方案是典型的双机热备架构,采用高可靠性的HA双机热备软件来保证数据库服务的稳定性及连续性。正常情况下两台mysql主机一台出于active状态,一台出于standby状态,HA软件维持一个VIP提供对外访问,当active主机出现问题宕机后,系统将自动切换到备机上继续提供服务,而整个过程只需要几秒到几十秒的时间即可完成,当mysql主机故障维修完毕后,服务可自动回切。本方案需共享存储的支持,所有mysql数据均保存在共享存储上。

    方案拓扑:

    image_thumb[5]

    优点

    维护简单,安全性、稳定性高,出现故障系统将自动切换,采用vip故障切换应用层无感知。

    缺点

    需要有共享存储设备,成本较高,双机热备不支持读写分离。

     

    方案三:

    MYSQL+MASTER-MASTER-REPLICATION+LVS/HAPROXY/NGINX


    方案简介:
    本方案基于mysql replication技术,采用master-master replication的双主复制模式,两台服务

    器都可读可写,都处于active状态,前端LVS(或HAPROXY或NGINX)代理并路由访问请求,将

    写请求(应用层实现读写分离)分发到server1,将读求分发到server2[或负载均衡到server1和

    server2],server1和server2互为主从,当任何一台发生故障时可双向实现故障转移,故障恢复可自

    动回切。


    方案拓扑:

    image_thumb[7]

    优点:
    秒级故障自动切换,可自动回切,采用固定ip故障切换应用层无感知,可实现读写分离。
    缺点:
    架构稍显复杂,后期有一定维护难度,包括其他master-master replication 架构的缺点。

    方案四:

    MYSQL+REPLICATION+MHA

    方案简介:
    MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库系统的高可用。
    在宕机的时间内(通常10—30秒内),完成故障切换,部署MHA,可避免主从一致性问题,不影
    响服务器性能,不改变现有部署,支持在线切换,从当前运行master切换到一个新的master上面,
    只需要很短的时间,此时仅仅阻塞写操作,并不影响读操作,便于主机硬件维护。在有高可用和数
    据一致性要求的系统上,MHA 提供了有用的功能,当master crash后,MHA自动识别slave间
    relay log events的不同,然后应用到不同的slave,最终所有slave都同步。

    方案拓扑:

    image_thumb[9]


    优点: 
    使用vip提供访问请求,有最好的数据一致性,master crash不会导致其它从库不一致性,故障自动
    快速切换,方案较为成熟,可实现一主多从,支持读写分离。
    缺点:    
    需3台及以上服务器,发生故障切转移后主程序自动退出,需排除故障后手动添加到ha集群再启动 MHA,维护难度较大。

  • 相关阅读:
    Android编译选项eng、user、userdebug的区别
    Linux 内核编码规范
    PLM之EVT、DVT、PVT、MP
    fastboot刷机的一般方法
    Android手机拨号测试项
    使用Genymotion安装APK出现错误INSTALL_FAILED_CPU_ABI_INCOMPATIBLE的解决办法
    三星手机列表拖动时出现诡异背景色的问题
    分享android ADT百度云盘下载地址
    关于互联网思维
    分享Nginx在Windows下的管理命令(bat文件)
  • 原文地址:https://www.cnblogs.com/jx270/p/6576852.html
Copyright © 2020-2023  润新知