精华内容
下载资源
问答
  • 数据库高可用方案

    2019-03-27 16:41:52
    高可用数据库可以通过将写操作放在主数据库节点上进行,将读操作分担到若干从库上,来提升读操作吞吐量,进而提升读写效率。 1.读写分离其实就是将数据库分为了主从库,一个主库用于写数据,多个从库完成读数据的...

     

    高可用数据库是由一系列数据库构成的总体系统,在任何时刻,至少有一个节点可以接受用户的请求并提供数据库服务。

    高可用数据库的优点

    第一,方便读写分离。

    高可用数据库可以通过将写操作放在主数据库节点上进行,将读操作分担到若干从库上,来提升读操作吞吐量,进而提升读写效率。

    1.读写分离其实就是将数据库分为了主从库,一个主库用于写数据,多个从库完成读数据的操作,主从库之间通过某种机制进行数据的同步,是一种常见的数据库架构。

    2数据库分组架构解决什么问题?

    大多数互联网业务,往往读多写少,这时候,数据库的读会首先称为数据库的瓶颈,这时,如果我们希望能够线性的提升数据库的读性能,消除读写锁冲突从而提升数据库的写性能,那么就可以使用“分组架构”(读写分离架构)。

    用一句话概括,读写分离是用来解决数据库的读性能瓶颈的。

    3.为什么不使用缓存呢?

    缓存的使用成本要比从库少非常多;缓存的开发比较容易,大部分的读操作都可以先去缓存,找不到的再渗透到数据库。当然,如果我们已经运用了缓存,但是读依旧还是瓶颈时,就可以选择“读写分离”架构了。简单来说,我们可以将读写分离看做是缓存都解决不了时的一种解决方案。

    当然,缓存也不是没有缺点的

    对于缓存,我们必须要考虑的就是高可用,不然,如果缓存一旦挂了,所有的流量都同时聚集到了数据库上,那么数据库是肯定会挂掉的。

    4.读写分离不使用的瓶颈

    对于常见的数据库瓶颈是什么呢?

    其实是数据容量的瓶颈。例如订单表,数据量只增不减,历史数据又必须要留存,非常容易成为性能的瓶颈,而要解决这样的数据库瓶颈问题,“读写分离”和缓存往往都不合适。

    大部分的互联网业务,数据量都非常大,单库容量最容易成为瓶颈,当单库的容量成为了瓶颈,我们希望提高数据库的写性能,降低单库容量的话,就可以采用水平切分了。

    而有少部分程序员,会没有分析数据库的性能瓶颈是什么,就贸贸然的使用“读写分离”,殊不知“水平切分”才是正道。

     

    第二,变更不停服。

    当整个高可用数据库架构或主节点升级时,可以让高可用数据库先进行主库切换,备用节点替换原主节点提供数据库服务,当主节点升级完毕后,再将主从库服务切换回来,这样能有效避免系统升级或变更时对用户服务质量产生影响。

    第三,备份不影响服务性能。

    高可用数据库架构包含多个从库,在不影响主节点服务性能的情况下,能非常方便地实现数据的容灾备份。

     

    典型高可用数据库架构

    按照数据同步方式,可以将业界主流高可用架构分为四种:共享存储方案、操作系统实时数据块复制、数据库级别的主从复制、高可用数据库集群。每一种数据同步方式可以衍生出不同架构。

    方案一:共享存储

    共享存储指若干DB服务使用同一份存储,一个为主DB,其它为备用DB。若主服务崩溃,则系统启动备用DB,成为新的主DB,继续提供服务。一般共享存储采用比较多的是SAN/NAS方案。

     

    (图:共享存储)

    虽然该方案的优点是没有数据同步的问题,但也有一些限制,如对于共享存储的实时性和网络性能有较高要求。而随着硬件性能的不断提升,将计算存储分离、和DB深度结合的共享存储亦是高可用数据库未来发展趋势之一。

     

    方案二:操作系统实时数据块复制

     

    这一方案的典型场景是DRBD,可以理解为远程的RAID1。如下图所示,左侧数据库写入数据以后,立即同步到右侧的存储设备当中。如果左边数据库崩溃,系统可以直接激活右边的数据库存储设备,启动新的数据库服务,实现容灾切换。

    (图:操作系统实时数据块复制)

     

    这个方案的缺点也比较明显,如系统只能有一个数据副本提供服务,无法实现读写分离;另外,如果系统崩溃,主库进程中断,容灾切换后需要在挂掉的数据库上做数据库崩溃恢复,系统需要的容灾恢复时间较长。

     

    方案三:数据库主从复制

     

    这种方案是最经典的数据同步模式,系统采用一个主库和多个从库方式,实现原理主要是基于日志的主从复制,主库操作以日志的形式发送给各个从库,从库接收到日志后进行数据备份。

    优点是一个主库可以连接多个从库,能很方便地实现读写分离,同时因为每个备库都在运行中,所以备库里的数据基本都是热数据,容灾切换也非常快。

    不过,这个方案也并非完美无缺,如容灾切换时,从库一定要同步完最新数据以后才能升级为主库,否则极有可能导致数据丢失。针对这些问题,业界也正在研发对应的改进技术。

    方案四:数据库高可用集群

    前三种方案主要通过日志的复制模式实现高可用,第四种方案则基于一致性算法来做数据同步,数据库提供多节点一致性同步机制,利用该机制构建多节点同步集群。这种方式比较经典的案例包括MGR(MySQL Group Replication)和Galera等,近期业内也有一些类似尝试,如使用一致性协议算法,自研高可用数据库架构等。

     

    (图:数据库高可用集群)

     

    如上图所示,五个节点构建成了一个一致性的同步集群,客户端可以读写其中的任一节点,其它节点都能进行数据同步,因此理论上每个节点都可以进行读写操作。这种方式的容灾实现也比较简单,假设第二个节点出现故障,系统只需要断开客户端对第二个节点的访问路径,其它节点照常访问即可,这也是业界近年来比较流行的高可用集群方案。

    参考:https://baijiahao.baidu.com/s?id=1610050327068432075&wfr=spider&for=pc

     

    展开全文
  • MYSQL数据库高可用方案探究 MySQL作为最关键的应用数据存储中心,如何保证MySQL服务的可靠性和持续性,是我们不得不细致考虑的一个问题。当master宕机的时候,我们如何保证数据尽可能的不丢失,如何保证...

    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,维护难度较大。

    posted on 2017-03-18 23:49  v.e.n.u.s 阅读( ...) 评论( ...) 编辑 收藏

    转载于:https://www.cnblogs.com/jx270/p/6576852.html

    展开全文
  • 一个系统可能包含很多模块,如数据库、前端、缓存、搜索、消息队列等,每个模块都需要做到高可用,才能保证整个系统的高可用。对于数据库服务而言,高可用的实现可能更加复杂,对用户的服务可用,不仅仅是能访问,还...

    一个系统可能包含很多模块,如数据库、前端、缓存、搜索、消息队列等,每个模块都需要做到高可用,才能保证整个系统的高可用。对于数据库服务而言,高可用的实现可能更加复杂,对用户的服务可用,不仅仅是能访问,还需要有正确性保证,因此讨论数据库的高可用方案时,在容灾之外,还要同时考虑方案中数据一致性问题。

    本文将通过介绍一些业界主流的数据库高可用架构、每种方案的特性和优缺点,以及数据库高可用架构的自动化运维实现,讲讲数据库高可用容灾方案设计与实现,希望抛砖引玉,和大家一起讨论。

    一、高可用数据库概述

    什么是高可用数据库?

    高可用数据库是由一系列数据库构成的总体系统,在任何时刻,至少有一个节点可以接受用户的请求并提供数据库服务。大多数数据库架构中,有一个主节点处理主要请求,还有若干备用节点用于容灾切换,当主节点不能提供服务时,备用节点成为主节点继续提供服务,用以保证整个系统的可用和稳定。

     

     

     

    高可用数据库有很多优点:

    第一,方便读写分离。数据库请求当中,一般读操作的请求次数远大于写操作,高可用数据库可以通过将写操作放在主数据库节点上进行,将读操作分担到若干从库上,来提升读操作吞吐量,进而提升读写效率; 第二,变更不停服。当整个高可用数据库架构或者主节点升级时,可以让高可用数据库先进行主库切换,让备用节点替换原主节点提供数据库服务,当主节点升级完毕后,再将主从库服务切换回来,这样能有效避免系统升级或变更时对用户服务质量产生影响; 第三,备份不影响服务性能。高可用数据库架构包含多个从库,在不影响主节点服务性能的情况下,能非常方便地实现数据的容灾备份。

    一般,高可用数据库地架构设计时,也需要考虑三个问题:

    第一,如何同步各数据库之间的节点数据?同步需要保证切换后的数据库是最新数据,以及在切换过程中数据不会丢失,同时还要考虑同步过程对主库和备库的影响。 第二,高可用数据库的容灾切换如何进行?架构不同容灾切换的复杂度也不一样,且切换以后需要保证主、从库数据的一致性,这可能需要开发者在设计之初就尽量优化和简化容灾切换逻辑。 第三,如何提高高可用的运维效率?

    二、业界典型高可用数据库架构

    分享一个技术交流的大群,群公告里面有很多关于架构层面的底层原理的分析和讲解,群里活跃度还可以,可以在里面交流学习,资料共享自己有好的资料也可以分享群号是:838498680

    按照数据同步方式,我们可以将业界主流的高可用架构划分成四种:第一种,共享存储方案;第二种,操作系统实时数据块复制;第三种,数据库级别的主从复制;第四种,高可用数据库集群。每一种数据同步方式可以衍生出不同的架构。

    方案一:共享存储

    共享存储指若干DB服务使用同一份存储,一个为主DB,其他的为备用DB,若主服务崩溃,则系统启动备用DB,成为新的主DB,继续提供服务。一般共享存储采用比较多的是SAN/NAS方案。

     

     

     

    这种方案的优点是没有数据同步的问题,但也有一些限制,如对于共享存储的实时性和网络性能有较高要求。因为共享存储一般是通过网络来访问存储当中的数据,在网络性能较差的情况下,数据库的性能也无法达到令人满意的效果。不过,随着硬件性能的不断提升,将计算存储分离、和DB深度结合的共享存储亦是高可用数据库未来发展的趋势之一。

    方案二:操作系统实时数据块复制

    这个方案的典型场景是DRBD,可以把它理解为远程的RAID1,如下图所示,左侧数据库写入数据以后立即同步到右侧的存储设备当中。如果左边数据库崩溃,系统可以直接激活右边的数据库存储设备,启动新的数据库服务,实现容灾切换。

     

     

     

    这个方案同样有一些问题,如系统只能有一个数据副本提供服务,无法实现读写分离;另外,如果系统崩溃,主库进程中断,容灾切换后需要在挂掉的数据库上做数据库崩溃恢复,系统需要的容灾恢复时间较长。

    方案三:数据库主从复制

    这种方案我认为是最经典的数据同步模式,系统采用一个主库和多个从库方式,其实现原理主要是基于日志的主从复制,主库操作以日志的形式发送给各个从库,从库接收到日志后进行数据备份。这种方式的好处是一个主库可以连接多个从库,能很方便地实现读写分离,同时,因为每个备库都在运行中,所以备库里面的数据基本上都是热数据,容灾切换也非常快。

     

     

     

    不过,这个方案也并非完美无缺,如容灾切换时,从库一定要同步完最新数据以后才能升级为主库,否则极有可能发生数据丢失的情况。针对传统主从架构的一些问题,业界也逐渐研发出对应的改进技术。

    改进技术一:双主架构

    问题:经典主从架构里面,原主库崩溃恢复的过程中,新的数据无法及时同步到该数据库当中,原主库恢复后,需要重新设置为从库,并将容灾过程中的数据重新同步进行。

    改进措施:为了保证容灾后的数据一致性,业界对这种架构做了一些改进,其中一种改进措施就叫双主架构,如下图所示,双主架构一般会选择两个DB做一对主库,这两个DB之间互相为对方的从库,无论往哪个DB写入数据,另一个都会自动同步。容灾时系统只需要把流量从左边切换到右边,容灾后数据同步依旧自动进行,这样,就保证了容灾后原主库的数据一致性。

     

     

     

    改进技术二:日志自动寻址

    问题:容灾备份时,当某一从库提升为主库后,其他备库需要自动定位新主库的日志同步点,同步新主库的日志。早期数据库日志中,MySQL是通过文件名加上文件的偏移量进行寻址,因此,主库的自动定位并不好实现。

    改进措施:为了解决此问题,MySQL提供了一种叫做GTID的全局事务标志技术,一个事务对应一个ID,所有的日志都带有唯一的标识符,主从库切换后,其余从库只要根据新主库的日志ID,就可以辨别新的日志同步点,然后根据这个日志同步数据,这对于搭建一主库多从库的架构来说寻址非常便捷。

     

     

     

    改进技术三:异步复制改进

    问题:默认情况下,MySQL的复制是异步的,主库将新生成的日志发送给各从库后,无需等待从库的ack回复(从库将接收到的日志写进relay log后,才会回复ack),直接就认为这次DDL/DML成功了。但在极端情况下,如主库刚提交日志,其他从库还没有接收到相关日志时,数据库发生故障,此时,该日志的内容就会全部丢失。

    改进措施:半同步复制机制。半同步复制是指主库在将新生成的日志发送给各从库前,需发送日志到一个(默认)从库,等待从库返回ack信息后,主库再提交日志发送给各从库,这就防止了上述情况下的数据丢失。半同步复制是一种提升数据一致性的有效方式,也是比较关键的技术。

    方案四:数据库高可用集群

    前面三种方案主要是通过日志的复制模式实现高可用,第四种方案则是基于一致性算法来做数据的同步,数据库提供多节点一致性同步机制,利用该机制构建多节点同步集群。这种方式比较经典的案例包括MGR(MySQL Group Replication)和Galera等,最近业内也有一些类似的尝试,如使用一致性协议算法,自研高可用数据库的架构等。

     

     

     

    以上示意图有五个节点,他们之间是构建成了一个一致性的同步集群,客户端可以读写其中的任何一个节点,任意一节点写入,其他节点都能够将数据进行同步,因此,理论上每个节点都可以进行读写操作。这种方式的容灾实现也比较简单,假设第二个节点出现故障,系统只需要断开客户端对第二个节点的访问路径,其他节点照常访问就可以了,这也是业界近年来比较流行的高可用集群方案。

    UCloud高可用数据库解决方案UDB

    UCloud对比了业内的各解决方案的优劣点,综合了原生MySQL兼容,不同版本、不同应用场景的覆盖等多种因素,最终选择采用基于数据库主从复制的方式实现高可用架构,并在原架构基础上,使用双主架构、半同步复制、采用GTID等措施进行了系列优化,保证数据一致性的同时,实现日志的自动寻址。

     

     

     

    如上图所示,最底层为数据层,使用了双主架构,主库与备主库之间通过半同步的方式实现数据同步,整个数据层是双主架构+半同步架构的模式。中间层有一个代理服务器Proxy,Proxy将流量导入到双主数据库的主节点,架构使用了GTID的模式,方便从库自动寻址。

    系统的容灾切换也非常简单,数据库崩溃前,Proxy将流量导到主DB上,发生容灾以后,只需要把Proxy从左边Master导到右边的Slave,即可快速完成切换。

     

     

     

    三、高可用数据库的自动化运维

    自动化运维的重点方向

    分享一个技术交流的大群,群公告里面有很多关于架构层面的底层原理的分析和讲解,群里活跃度还可以,可以在里面交流学习,资料共享自己有好的资料也可以分享群号是:838498680

    自动化运维是高可用数据库中的难点,因为企业业务不一定只有一个数据库,可能需要同时管理十几个甚至上百个数据库,如果每一个数据库都配置一个高可用数据库架构,系统则需要保证其中任何一个发生问题以后都可以进行容灾,这无疑给运维带来了极大挑战。

    那么,如何同时管理大量高可用数据库,让他们都可以进行容灾呢?这里有一些自动化运维方向的思路:1、容灾切换自动化;2、高可用数据库运行状况监控;3、健康状况自动检查和问题修复。

    1、容灾切换自动化。要实现容灾切换的自动化,首先需要考虑两个问题:

    第一,怎样准确判断需要容灾。这是实现自动容灾的基础和前提,它需要结合实际情况讨论和判断。如发生网络波动时,可能有一段时间发现无法连上主库,实际上几秒钟以后整个业务系统又恢复了,如果这时候数据库做容灾的话代价比较大,且容灾后还可能会有额外的风险。所以需要在前期准确判断是否需要容灾,并保证在最需要容灾的时候及时容灾; 第二,容灾切换时,备库数据尽量和主库数据保持一致,否则,就会带来数据丢失的问题。

     

     

     

    针对上述问题,MySQL已经有比较常用方案供参考,老牌的如MHA,还有一种比较新的方案叫Orchestrator,如果大家自己搭建数据库,可以考虑采用这两种方案。

    2、健康状况自动检查。健康状况检查需要通过自动监控搭配告警来做,高可用容灾中,最关心的还是高可用数据库的主库和备库数据是否一致,一般情况,导致主从库数据不一致的主要是两点:

    第一,复制有没有正常进行,如发送日志时主库与备库之间的连接突然断掉,这时候需要系统时常扫描主备库是否异常; 第二,主从延时,如果主从之间的数据延迟较大,那么切换数据库时也会比较麻烦,这方面也可以考虑使用业内比较常用的监控模块如Prometheus等工具定期采集,发现异常状况后及时调整。

     

     

     

    第三,异常情况自适应调整。以主从延迟为例,一般来说可能是CPU的问题或者IO的问题等,如果是IO的问题,一种办法是将IO调高,这是一种比较好的解决方案,如果IO调高以后发现还是无法降低延时,可以在从库把日志的持久化等级暂时性调低。当然,如果主从之间延迟过大,完全无法调整为正常水平,这时候就要考虑通过一些手段重做从库。

    UDB:海量高可用数据库自动化运维

    UDB拥有海量的高可用数据库,在自动化运维和管理方面,UDB采用的是高可用容灾集中式自动化管理的方式,通过自研的自动容灾逻辑,进行大规模、高并发的DB自动化容灾。同时,UDB的运维体系还可以做到自动化的问题探测以及问题修复,如自动拉起DB、恢复服务,自动恢复数据同步,自适应流量控制等。此外,UDB还会配合一些高效运维工具和巡检工具做更深层次的问题的发现和解决。

     

     

     

    在UDB高可用运维当中,有几点经验可以跟大家分享:

    第一,日常需要做例行巡检,保证高可用数据库的健康。主从延时是导致高可用数据库无法容灾的关键原因之一,这一点一定要在日常运维工作中重视起来; 第二,定期容灾演练很有必要。容灾演练就是在平台上跑自己的容灾逻辑,我们需要在不同场景下做切换,看数据有没有丢失、是否保持了数据的一致性等等,因为线上环境非常复杂,可能会有各种莫名其妙的问题导致切换逻辑在发生切换以后结果不一致,所以要通过定期演练把各种可能性降到最低; 第三,高可用切换需要记录日志,并且在切换失败的时候马上告警。切换日志可以做事后复盘分析,看这个DB是什么时候崩溃做的容灾。进入告警后可以保证第一时间介入并解决,缩短整个DB崩溃对用户的影响时间。

     

     

     

    四、总结

    高可用架构是数据库运行稳定必不可少的一部分,设计架构时要考虑诸多问题,如数据是否同步、高可用自动切换、自动化运维等等。前面讲解了四种基于数据库同步的数据库高可用架构,如果是在云环境下,推荐使用UDB云数据库这样的产品一键完成上述配置,帮助减轻业务的运维压力。


     

    展开全文
  • 数据库高可用综述

    2020-03-17 15:11:18
    数据高可用综述 一、 发展前景以及需求分析 伴随着计算机和因特网的快速发展,数据库成了计算机信息系统的核心基础部分,广泛应用于金融、企业、能源、电信、政府等重点行业,随着数据量和业务量的不断高速增长,以及...

    数据库高可用综述

    一、 发展前景以及需求分析

    伴随着计算机和因特网的快速发展,数据库成了计算机信息系统的核心基础部分,广泛应用于金融、企业、能源、电信、政府等重点行业,随着数据量和业务量的不断高速增长,以及高并发访问等问题的出现,使得传统的单机数据库已经难以满足需求,提高数据库系统性能和可用性已成为亟待解决的问题,高可用性数据库也因此受到人们的广泛关注。在这个信息爆炸的时代,互联网得到了迅速地普及,尤其是互联网上的商业服务的迅猛发展,许多行业对计算机服务系统的高可用性的要求日益增高。如果服务器很长一段时间停止工作将会导致许多用户需求转向企业的竞争对手,这不仅仅会给企业带来资产损失,还可能会让企业失去了客户的信任,进而可能失去大量的潜在客户,继而承担巨大的经济损失。
    许多人认为,当前的数据库技术已经非常的成熟安全,及时做好备份,发生故障时可以保证万无一失,可是,实际上并没有那么简单,几乎所有的数据库系统故障解决方案,都达不到集群系统这样具有良好的高可用性。
    总的来说,对于目前的数据库而言,提高处理速度、数据高可用性、安全性和扩展性,都是急于要解决的问题。数据库的高可用性已经成为判断数据库系统性能高低的最重要的标准,数据库是用来存储最终应用的结果,因此数据库是整个商业智能解决方案中最重要的组成部分。现如今,计算机被应用到各行各业,使得数据库技术得到了高速发展。日常生活中的一些信息,企业生产销售信息都保存在计算机的数据库里,这些数据一旦由于系统损坏,造成大量丢失,将会给企业带来重大的经济损失。
    

    二、 数据库高可用原理

    高可用是一种系统,在经过专门的设计之后,可以让系统的可用性从99.9%上升至99.999%,从而减少了系统停机的时间。一般可用性系统每年停机时间为8.8小时,而高可用性系统每年停机时间仅5.3分钟,相较而言,系统服务的高度可用性得到了保证。与此同时,高可用性系统尽可能的缩短了因日常维护、突发情况所导致的停机时间。实现高可用主要通过以下三种方式:
        1.双机热备方式
        工作原理:该方式需要主机和备用机,称为“双机”,其中的一台主机处于工作状态,备用机处于监控准备状态。当主机出现宕机的情况时,备用机便接管主机的工作,等到主机维修至正常状态时,备用机再将工作传递回主机。主机与备用机间交接工作时所用的切换方式由使用者设定,交接的数据通过共享存储的方式保证其完整性和一致性。但是,由于主机一般不存在经常性宕机的情况,因此备用机长期处于监控准备状态,也就是不工作的状态,就导致了资源的浪费。
        2.双机双工方式
        工作原理:该方式需要两台主机,二者同时运行着各自的工作,与此同时,随时监控着对方的工作状态。当其中一台主机出现宕机的情况,另一台主机则直接接管出现宕机情况的主机的工作,并且要保证工作的质量。因此,该方式对两台主机的性能要求较高,要有一定的性能冗余,才不会在接管另一台主机的工作时也出现宕机的情况。两台主机接管工作时的数据都存放在共享存储中。
        3.集群系统方式
        工作原理:该方式有多台主机同时工作,当其中一台主机出现宕机情况时,其他的主机则直接接管它的工作,在该主机修复完成后,系统会自动给它分配新的任务。相较于以上两种方式,该方式的不同之处就在于,交接出去的工作不会再传递回来,该主机将接收新的工作。
    

    三、 数据库高可用功能

    高可用性是系统的一个特性,保证系统能在足够长的时间内提供指定程度的服务等级。再细化一下,可以说是在有限的故障条件下,提供一定等级的稳定服务.。对于应用层来说,根据业务特点可以很方便地设计成无状态的服务,在大多数互联网公司中,在业务层的最上层使用动态DNS、LVS、HAProxy等负载均衡组件,配合Docker和Kubernetes实现弹性伸缩,能够很容易实现应用服务的高可用。而数据库能能够做到高可用性的关键就在其有着消除单点问题、自动故障恢复、在线扩容、在线表结构变更、数据量大的解决方案等几个特殊性的功能,拿在线扩容举例,随着数据库的数据量越来越大,Scale是不可避免的问题。对于数据库来说,技术层面最大的追求就在于如何不停服务地对数据库节点进行Scale操作,这是非常有挑战性的事情。以中间件/Proxy方案来说,很多时候不得不提前对数据量进行规划,把扩容作为重要的计划来做,从DBA到运维到测试到开发人员,很早之前就要做相关的准备工作,真正扩容时为了保证数据安全,经常会选择停服务来保证没有新的数据写入,新的实例数据同步后还要做数据的一致性校验。当然业界大公司有足够雄厚的技术实力,可以采用更自动化的方案,将扩容停机时间尽量缩短(但很难缩减到0),但大部分中小互联网公司和传统企业依然无法避免较长时间的停服务问题。TiDB完全实现了在线的弹性扩容,主要基于Placement Driver的调度和Raft算法。
    

    四、主要技术以及适应场景

    数据库高可用是一个复杂的系统工程,其基本技术主要有: HADR、 HACMP、 数据复制,存储层容灾和DPF高可用。在不同场景,不同的业务连续性级别下,可以组合使用这几种技术,以实现从存储,网络,系统,数据库到应用的高可用技术。
    

    (一)SQL复制和Q复制

    技术简介
    SQL 复制捕获源表的更改并使用 CD 表来存储已经提交的事务性数据,然后从 CD 表中读取这些更改并将它们复制到相应的目标表。 SQL 复制可以应用在各种需要的环境,包括容量补偿,给数据仓库输送数据以及审计更改历史记录。用户可以选择相隔一段时间或仅在一段时间内复制。通过连续时间内的复制,应用程序可以捕捉到实时的数据。Q 复制可以在很短的时间内复制大量的数据。 Q 复制将捕获源表的更改并将已提交的事务转化为消息。Q 复制不使用 CD 表,当 Q 复制读取到数据后,将消息通过 MQ 消息队列发送到目标。目标系统将会从队列中读取消息并将消息转化为相应的事务提交到目标表。目前 SQL 复制支持非 DB2 数据源到 DB2 以及 DB2 到非 DB2 数据源的复制,而 Q 复制只支持 DB2 到非 DB2 数据源的复制。

    适用场景
    SQL复制主要应用于相同局域网内。Q复制远程好一点,因为在网络比较差的时候,WebSphere MQ可以缓存一段时间数据。Q复制一般结合HADR比较多,用于实现数据远程异地复制(比如中国烟草总公司容灾中心)。

    (二) HACMP

    技术简介
    Hacmp(High Availability Cluster Multi-Processing)双机热备份软件的主要功能是提高客户计算机系统及其应用的可靠性,而不是单台主机的可靠性。HACMP群集可以按几种方式配置以满足不同类型的处理要求。并行访问模式适合于所有处理器多必须在相同工作负载下运行并共享相同数据的环境。在交互备份模式中,处理器共享工作负载并互相备份。闲置备用设备允许用一个节点备份群集器中的其他节点

    适用场景
    Cascading用于主备机硬件性能有较大差别的环境,节约成本,这个对于不差钱的运营商、航空、银行、政府绝对不会采用。Rotating适用于对可用性要求较高的场景,电信行业的数据业务,增值业务,彩铃等产品多采用这种方式。

    (三)DB2 HADR

    技术简介
    HADR全称为High Availability Disaster Recovery ,一个HADR环境需要两台数据库服务器:主数据库服务器(primary)和备用数据库服务器(standby)。当主数据库中发生事务操作时,会同时将日志文件通过TCP/IP协议传送到备用数据库服务器,然后备用数据库对接受到的日志文件进行重放(Replay),从而保持与主数据库的一致性。当主数据库发生故障时,备用数据库服务器可以接管主数据库服务器的事务处理。此时,备用数据库服务器作为新的主数据库服务器进行数据库的读写操作,而客户端应用程序的数据库连接可以通过自动客户端重新路由(Automatic Client Reroute)机制转移到新的主服务器。当原来的主数据库服务器被修复后,又可以作为新的备用数据库服务器加入HADR。通过这种机制,DB2 UDB实现了数据库的灾难恢复和高可用性,最大限度的避免了数据丢失。

    适用场景
    HADR,是IBM DB2数据库上的数据库级别的高可用性数据复制机制,最初被应用于Informix数据库系统中,IBM收购Informix之后,这项技术就应用到了新的DB2发行版中。HADR有一主一备数据库,在9.7之前备机不可读,9.7之后备机可读可以降低主数据库的负担。
    在数据专线带宽足且稳定的情况下,在要求主备完全数据无损的时候,推荐用同步方式传送,或者能容忍一定少量的损失,可以用准同步,但是推荐在在生产中心和同城的灾备中心之间(LAN或者MAN),如果在1000公里以上带宽和时延都没什么保障的话,最好还是用异步的方式,如果更差或者对OLTP的实时性要求较高还可以用超级异步,当然这对流水的损失要有一定的容忍度。HADR有一个弱点就是不能进行数据压缩和加密,如果没有VPN就麻烦了,但是HADR可以集成第三方的SSH软件。而DG本身就集成了SSH进行压缩和加密功能。HADR最要命的是不能支持异构数据库的复制,当然这个也不是他的主要场景。

    五、高可用架构

    (一)共享储存方案
    在共享储存架构当中若干个数据库共享一个存储,其中一个数据库为主,其它的为备用数据库,当主数据库宕机,系统会切换从数据库接管业务,成为新的主数据库。这个架构不存在数据同步的问题,但是对存储和网络有较高的要求。

    (二)操作系统实时数据块复制
    这里有一个明显的缺点,就是系统只允许一个副本提供服务,无法实现读写分离。此外,当系统宕机,主数据库的进程被中断,切换后需要对宕机的数据库进行数据恢复,需要的时间较长。

    (三)数据库级别的主从复制
    通过一个主数据库和若干个从数据库,实现主数据库将操作日志发送给各个从数据库,从数据库依据接收到的日志进行数据备份。这样有利于读写分离,同时从数据库当中的热数据能够实现容灾切换及时性。但是还是得注意,在从数据库升级为主数据库之前,一定要完成最新数据同步,否则容易导致数据丢失。

    (四)数据库高可用集群
    前三种方式是通过数据库日志复制来实现高可用,高可用集群则是通过一致性算法来实现数据的同步,通过数据库多节点一致性同步机制实现多节点同步集群的构建。该方案每个节点都能够进行读写操作,当用户读取其中任一节点数据时,其它节点能够进行数据同步。通过这种方式实现数据容灾也很简单,当其中一节点发生故障,只需断开对该节点的访问,其他节点照常即可。
    高可用数据库的优势在于能够实现读写分离,在主数据节点上进行写操作,从数据库分担读操作,从而提升读操作吞吐量和写操作的效率。其次高可用数据库能够有效避免系统升级或者变更时带来的对业务的影响。另外,高可用数据库包含多个从库,在保障主节点性能的情况下,能够有效实现数据的容灾备份要求。不同架构的数据库,其容灾切换的难易程度也不一样。为了保障切换主从数据库后数据的一致性,需要在架构设计前期就考虑到容灾切换的优化。
    数据存储高可用的方案本质都是通过将数据复制到多个存储设备,通过数据冗余的方式来实现高可用。常见的高可用架构有主备、主从、主从切换、主主等接下来我们聊聊每种架构的优缺点。

    一、主备架构
    1、 基本架构拓扑图如下
    在这里插入图片描述
    整体架构简单,几乎所有的数据库都提供了主备复制的功能,例如Mysql、Oracle、MongoDB等。在这种架构中备库主要承担数据备份的作用,不参与实际业务读写操作,如果把备机改成主机需要人工操作。

    2、优缺点分析 主备架构的优点就是简单,具体表现有:
    对于客户端来说,不需要感知备机的存在,即使灾难恢复后,原来的备机被人工干预修改为主机,客户端只需要简单修改连接地址即可,应用架构不需要做任何改动;主机和备机只需要进行数据复制,不需要进行状态判断和主备切换这类复杂操作。这种架构的缺点也比较明显:备机主要是用于数据备份,如果应用架构没有读写分离设计时会造成成本浪费故障后需要人工干预,无法自动恢复,而人工处理效率又比较低,恢复过程也容易出错。

    二、主从架构
    主从架构与主备架构只有一字之差,但是对于实际应用架构差距却很大。在主备架构中备库不参与业务操作,而在主从架构中从库是需要参与业务操作的,应用架构需要做读写分离,将写操作写入主库,而读操作从从库读。
    1、主从基本架构拓扑图如下
    在这里插入图片描述
    2、优缺点分析 这种架构在少量写和大量读时非常有用。可以把读分摊到多个备库上,减少主库的压力,直到从库给主库造成了太大的负担,或者主从之间的带宽成为瓶颈为止。
    相比于主备架构,
    它有如下优点:
    (1)在主库故障时,读操作相关业务可以继续运行
    (2)从库对外提供读能力,发挥了硬件的性能
    (3)可以为不同的角色提供不同的从库
    缺点:
    (1)主从架构中从库需要提供读业务,如果主从复制延迟大,数据会出现不一致情况;
    (2)应用架构需要做修改,一般会加入读写分离,复杂度比主备高;
    (3)故障后需要人工干预,无法自动恢复,而人工处理效率又比较低,恢复过程也容易出错。

    三、主从切换
    上面两种架构都存在两个共同问题:
    (1)主库故障后,无法进行写操作
    (2)主库出了问题后需要人工干预才能将从库切换到主库,而人工切换又可能出现不及时或者切换故障的问题。

    基于以上两个问题我们需要一个能自动切换的架构,当主库出了故障后能自动将从库切换成主库,无需运维人员干预。要实现主从切换架构必须要考虑一个关键点:必须要有一个机制能监测到数据库节点的运行状态,以此来决定是否切换。这种架构我们一般会引入一个第三方中介,数据库节点定时向第三方中介汇报自己的状态信息;或者第三方中介定时去数据库节点拉取数据库状态;
    在这里插入图片描述
    优点:解决了人工干预的问题,大大减少了故障时间,一定程度上保护了运维人员的人生安全
    缺点:架构复杂,引入了第三方中介后又需要保证第三方中介的高可用。这里推荐大家了解一下mysql的MHA架构,或者使用ZK、Keepalived自己搭建主从切换架构。

    四、主主架构
    主主架构又叫主主复制,两台数据库都是主库,互相将数据复制给对方,客户端可以挑选任意一台数据库进行读写操作。
    在这里插入图片描述相比于主从切换,主主架构有如下优点:
    (1)两台数据库都是主库,不存在切换的概念
    (2)客户端无需区分不同角色的主机,随便将读写操作发给哪台数据库。
    (3)架构简单

    但是允许向两台主数据库写入是一件很危险的事:

    AB两台数据库采用自增长主键,A库插入用户后id是1,B库插入用户后id也是1,数据冲突

    同时对数据库数据进行更新会出现大问题,加入AB库的表tb都有1个字段col,数值为1。如A库执行 update tb set col = col +1,B库执行update tb set col = col * 2,最终执行完一台数据的值变成了4,另一台数据库的值变成了3,而且没有任何复制错误,一旦出了问题需要好久才能定位。所以主主架构必须要保证数据能够双向复制,对数据的设计有严格的要求,一般适用于那些临时性,可丢失、可覆盖的数据场景。

    展开全文
  • 几种常见Mysql数据库高可用方案

    千次阅读 2020-09-21 15:22:47
    1.概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: ...关于对高可用的分级在这里我们不做详细的讨论,这里只讨论常用高可用方案的优缺点以及高可用方案的选型。 2.高可用方案
  • 方案一:双机高可用方案 1.数据库架构图 2.特点 一台机器A作为读写库,另一台B作为备份库;A库故障后B库作为读写库;A库恢复后A作为备库。 3.开发说明 此种情况下,数据源配置中的数据库IP地址,可采用虚拟的...
  • MYSQL数据库的主从切换

    千次阅读 2019-02-27 13:37:49
     MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司的youshimaton(现就职于 Facebook公司...是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件...
  • DM 主备集群搭建步骤(自动切换模式) 1、 首先先创建两个数据库实例,作为预留主备机; ./dminit path=/home/dmdba/dmdbms/data 2、两个实例创建完毕之后都通过前台启停一遍; ./dmserver /home/dmdba/dmdbms/data/...
  • MySQL MGR+ Consul之数据库高可用方案最佳实践 背景说明: 基于目前存在很多MySQL数据库单点故障,传统的MHA,PXC等方案VIP或者DNS切换的方式可以实现、基于数据库的数据强一致性...
  • 一.什么是高可用性 高可用性=可靠性,它的本质就是通过技术和工具提高可靠性,尽可能长时间保持数据可用和系统运行,实现高可用性的原则,首先要消除单点故障,其次通过冗余机制实现...3.当业务发生数据库切换的时候,
  • SQL Server使用日志传送,可以自动将主服务器的事务日志备份发送到一个或多个辅助数据库上。事务日志备份分别应用于每个辅助数据库。 可选的第三个服务器实例(称为“监视服务器”)记录备份和还原操作的历史记录及...
  • mysql数据库高可用高扩展性架构方案实施 浅谈数据库架构瓶颈_互联网公司从初期到后期的数据库架构拓展     生产环境架构方案及实施文档 Heartbeat+DRBD+MySQL高可用 根据评委老师的建议,...
  • 数据库高可用实现二1 数据库高可用实现(二)1.1 当前数据库服务存在问题1.1.1 现在的架构设计1.1.2 主库宕机影响1.1.3 改进策略1.1.4 配置互为主从1.1.5 主从测试1.2 MyCat1.2.1 介绍1.2.2 MyCat安装1.2.3 编辑...
  • (1)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,...
  • 越来越多的方法被尝试用来解决分布式数据一致性的问题,如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等,本文介绍MySQL数据库的几种常见高可用方案。 一、概述 我们在考虑MySQL数据库...
  • 今天主要讲一下关于mysql读写分离rw...然后就是介绍一下官方提供的mysql-router工具,以及如何使用。 开班第二十八天: 今天的课程大纲: 关于golang(GO语言)的基本认识和配置 mysql读写
  • MySQL数据库的高可用方案总结

    千次阅读 2018-09-09 20:37:29
    这篇文章主要针对MySQL数据库的高可用方案进行详细总结,高可用架构对于互联网服务基本是标,本文是对各种方案的总结,感兴趣的小伙伴们可以参考一下   可用架构对于互联网服务基本是标配,无论是应用服务还是...
  • 在信息时代,数据有着比人们更大的力量,数据库的价值可见一斑,数据库的存在为人们提供了更快的查询,那么为了更好地做到数据库的高可用,保证持续提供服务,简化DBA操作,节省数据库故障切换的时间,故开发此...
  • 越来越多的方法被尝试用来解决分布式数据一致性的问题,如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等,本文介绍MySQL数据库的几种常见高可用方案。   一、概述 我们在考虑MySQL...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 11,403
精华内容 4,561
关键字:

数据库高可用切换