快捷搜索:
来自 网络数据库 2019-06-20 08:28 的文章
当前位置: 67677新澳门手机版 > 网络数据库 > 正文

高可用性手艺总结,高可用本事概述

三.  镜像

       应用场景:

              要求高服务可用性。

              要求实现自动故障转移。 

              确保数据的完整。

         优点:

              根据业务可实现同步和异步镜像。

              快速的故障转移恢复。低硬件成本。

         要求:

              主体服务器。

              镜像服务器。

              见证服务器。

 

四. 故障转移群集

  应用场景:
    硬件故障转移。
    服务故障转移。
    人工故障或各种其它原因等。
  优点:
    根据业务进行灵活的群集拓扑结构
    快速且自动故障转移
  缺点:
    群集非活跃节点浪费硬件资源
    群集节点间共用的共享存储,仍然存在潜在的单点故障隐患。
    没有负载能力,不是提升性能的技术。

        要求

              基于windows故障转移

 

依靠什么来决定使用哪一种高可用性技术?

       很多企业都需要他们的全部或部分数据高可用,比如说在线购物网站,在线商品数据库必7*24小时在线,否则在竞争激烈的市场环境下,宕机时间就意味着流失客户和收入。再比如说,一个依赖于SQL Server的呼叫中心,如果数据库宕机,则所有的呼叫员都只能坐在那里回复客户“对不起,系统故障”,这也是很难接受的。

       当然,在一个理想的世界中,所有的关键数据都会时刻在线,但在现实世界中,会存在各种各样的原因导致数据库不可用,由于无法预估灾难出现的时间和形式,需要提前采取措施来预防各种突发情况,因此SQL Server提供了多种高可用性技术,这些技术主要包括:集群、复制、镜像、日志传送、AlwaysOn可用性组以及其它诸如文件组备份还原、在线重建索引等单实例的高可用性技术。使用何种高可用性技术并不是随意挑一个熟悉技术直接使用,而是要基于业务和技术综合考虑。因为没有一项单独的技术可以实现所有的功能。如何根据具体的业务和预算采用这些技术,就是所谓的高可用性策略。

在设计高可用性策略时应该首先考虑下述因素:

  • RTO(Recovery Time Objective)-也就是恢复时间目标,意味着允许多少宕机时间,通常用几个9表示,比如说99.999%的可用性意味着每年的宕机时间不超过5分钟、99.99%的可用性意味着每年的宕机时间不超过52.5分钟、99.9%的可用性意味着每年的宕机时间不超过8.75小时。值得注意的是,RTO的计算方法要考虑系统是24*365,还是仅仅是上午6点到下午9点等。您还需要注意是否维护窗口的时间在算在宕机时间之内,如果允许在维护窗口时间进行数据库维护和打补丁,则更容易实现更高的可用性。
  • RPO(Recovery Point Objective)-也就是恢复点目标,意味着允许多少数据损失。通常只要做好备份,可以比较容易的实现零数据损失。但当灾难发生时,取决于数据库损坏的程度,从备份恢复数据所需要的时间会导致数据库不可用,这会影响RTO的实现。一个早期比较著名的例子是某欧美的银行系统,只考虑的RPO,系统里只存在了完整备份和日志备份,每3个月一次完整备份,每15分钟一次日志备份,当灾难发生时,只能够通过完整备份和日志备份来恢复数据,因此虽然没有数据丢失,但由于恢复数据花了整整两天时间,造成银行系统2天时间不可用,因此流失了大量客户。另外一个相反的例子是国内某在线视频网站,使用SQL Server作为后端关系数据库,前端使用了No-SQL,定期将No-SQL的数据导入关系数据库作为备份,当灾难发生时最多允许丢失一天的数据,但是要保证高可用性。

    预算 –RTO和RPO统称为SLA(服务水平协议),设计高可用性策略时,要根据业务来衡量满足何种程度的SLA,这要取决于预算以及衡量不同SLA在故障时所造成的损失。SLA并不是越高越好,而是要基于业务需求,通常来说,在有限的预算之下很难实现很高的SLA,并且即使通过复杂的架构实现较高的SLA,复杂的架构也意味着高运维成本,因此需要在预算范围之内选择合适的技术来满足SLA。

因此,综合来说,可以通过几个接单的问题确定高可用性的大框架:

  • 股东能够接受的宕机时间是多少?
  • 管理人员能够接受的宕机时间是多少?
  • 为高可用性方案提供的预算是多少?
  • 宕机导致的损失是每小时是多少钱?

 

  五 总结 (不包含 always on 且是sql 2005版的总结)图片来自微软讲师 借鉴下。哈哈

    图片 1

    图片 2

 

  

 

小结

 

本篇文章阐述了高可用性的基本概念、SLA的概念、SQL Server中所支持的不同种类的高可用性功能以及设计一个高可用性策略所需的步骤。值得注意的是,虽然本文仅仅讲述了数据库层面的高可用性,但高可用性不仅仅是DBA的事,还包括系统运维人员、网络管理人员、开发人员、管理人员等不同角色的共同协作,才能够更好的满足SLA。

二. 日志传送log shipping(备份-->复制-->恢复)   

       应用场景:
    多台主从服务器定时备份同步。
    负载均衡、提供副本只读。
  优点:
    实现简单。
  要求:
    必须是完整备份模式。
    主服务器、辅助服务器、监视服务器的备份文件夹必须有读写权限。
    sql agent代理必须启动。

SQL Server中所支持的高可用特性

    SQL Server中所支持的高可用性功能与版本息息相关,企业版支持所有的高可用性功能,这些功能包括:

  • l 故障转移集群
  • l 数据库镜像
  • l 事务日志传送
  • l 数据库快照
  • l 高可用性升级
  • l 热加载内存
  • l 在线索引操作
  • l 数据库部分在线(只还原了主文件组或主文件组和额外的NDF文件)

    具体何种版本支持哪些高可用特性,请参阅:,值得注意的是免费的Express版本可以作为数据库镜像的见证服务器,从而节省了成本。

故障转移集群

       故障转移集群为整个SQL Server实例提供高可用性支持,这意味着在集群上某个节点的SQL Server实例发生了硬件错误、操作系统错误等会故障转移到该集群上的其它节点。通过多个服务器(节点)共享一个或多个磁盘来实现高可用性,故障转移集群在网络中出现的方式就像单台计算机一样,但是具有高可用特性。值得注意的是,由于故障转移集群是基于共享磁盘,因此会存在磁盘单点故障,因此需要在磁盘层面部署SAN复制等额外的保护措施。最常见的故障转移集群是双节点的故障转移集群,包括主主节点和主从节点。

 

缺点:辅助节点不可用,数据单点。

事务日志传送

       事务日志传送提供了数据库级别的高可用性保护。日志传送可用来维护相应生产数据库(称为“主数据库”)的一个或多个备用数据库(称为“辅助数据库”)。发生故障转移之前,必须通过手动应用全部未还原的日志备份来完全更新辅助数据库。日志传送具有支持多个备用数据库的灵活性。如果需要多个备用数据库,可以单独使用日志传送或将其作为数据库镜像的补充。当这些解决方案一起使用时,当前数据库镜像配置的主体数据库同时也是当前日志传送配置的主数据库。

    事务日志传送可用于做冷备份和暖备份的方式。

 

 缺点:日志还原时不能读取数据,严格意义上不属于热备份。

数据库镜像

       数据库镜像实际上是个软件解决方案,同样提供了数据库级别的保护,可提供几乎是瞬时的故障转移,以提高数据库的可用性。数据库镜像可以用来维护相应生产数据库(称为“主体数据库”)的单个备用数据库(或“镜像数据库”)。 
因为镜像数据库一直处于还原状态,但并不会恢复数据库,因此无法直接访问镜像数据库。但是,为了用于报表等只读的负载,可创建镜像数据库的数据库快照来间接地使用镜像数据库。数据库快照为客户端提供了快照创建时对数据库中数据的只读访问。每个数据库镜像配置都涉及包含主体数据库的“主体服务器”,并且还涉及包含镜像数据库的镜像服务器。镜像服务器不断地使镜像数据库随主体数据库一起更新。 
    数据库镜像在高安全性模式下以同步操作运行,或在高性能模式下以异步操作运行。在高性能模式下,事务不需要等待镜像服务器将日志写入磁盘便可提交,这样可最大程度地提高性能。在高安全性模式下,已提交的事务将由伙伴双方提交,但会延长事务滞后时间。数据库镜像的最简单配置仅涉及主体服务器和镜像服务器。在该配置中,如果主体服务器丢失,则该镜像服务器可以用作备用服务器,但可能会造成数据丢失。高安全性模式支持具有自动故障转移功能的备用配置高安全性模式。这种配置涉及到称为“见证服务器”的第三方服务器实例,它能够使镜像服务器用作热备份服务器。从主体数据库至镜像数据库的故障转移通常要用几秒钟的时间。

    数据库镜像可用于做暖备份和热备份。

 缺点:最多只支持两个节点,辅助节点可用性差。

复制

      复制严格来说并不算是一个为高可用性设计的功能,但的确可以被应用于高可用性。复制提供了数据库对象级别的保护。复制使用的是发布-订阅模式,即由主服务器(称为发布服务器)向一个或多个辅助服务器或订阅服务器发布数据。复制可在这些服务器间提供实时的可用性和可伸缩性。它支持筛选,以便为订阅服务器提供数据子集,同时还支持分区更新。订阅服务器处于联机状态,并且可用于报表或其他功能,而无需进行查询恢复。SQL Server 提供四种复制类型:快照复制、事务复制、对等复制以及合并复制。

 缺点:非高可用功能,常用于读写分离,维护成本较高。

AlwaysOn可用性组

       AlwaysOn可用性组是SQL Server 2012推出的新功能。同样提供了数据库级别的保护。它取数据库镜像和故障转移集群之长,使得业务上有关联的数据库作为一个可用性组共同故障转移,该功能还拓展了数据库镜像只能1对1的限制,使得1个主副本可以对应最多4个辅助副本(在SQL Server 2014中,该限制被拓展到8个),其中2个辅助副本可以被作为热备份和主副本实时同步,而另外两个异步辅助副本可以作为暖备份。此外,辅助副本还可以被配置为只读,并可用于承担备份的负载。

    正因为如此,数据库镜像在SQL Server 2012中被标记为“过时”。

优点:微软较综合的方案,可回避故障转移群集、镜像、复制、日志传送几种技术的缺点。

缺点:SQL Server2012版本才能使用,无法自动实现负载均衡,需要自己配置读或写字符串。 

 

Moebius负载均衡集群

    

 

         Moebius® for SQL Server 是格瑞趋势专门针对Microsoft SQL Server开发的综合集群平台,基于SQL Server的内核实现,核心程序宿主在SQL Server的内核之中,该集群可实现数据库的负载均衡及横向扩展;保证数据库的可用性;保证多份冗余数据的实时同步。

Moebius集群,可以实现SQL语句一级的负载均衡;同时将自动故障监测、虚拟IP及失败转移技术融入其中,满足企业对高可用系统建设的要求;数据复制时,采用了同步和异步两种复制模式,可实现数据在多台服务器间实时同步,保证事务的一致性和完整性,支持远距离复制;Moebius集群具有带宽占用少、同步效率高、数据实时性高、数据一致性保障好的特点。

优点:第三方较综合的方案,可回避故障转移群集、镜像、复制、日志传送几种技术的缺点。

缺点:大批量写入操作(类似采集系统)数据同步会有性能消耗。

 

一.  复制Replication(快照、事务、合并)   

      应用场景:
    负载均衡、提供副本读,写操作。
    分区将历史数据复制到其它表中。
    授权,将数据提供它人使用。
    数据合并。
    故障转移。
  优点:
    实现简单。
    数据同时同步,几乎达到镜像。
    可以实现对某些表,或表数据过滤进行复制。
  缺点:
    不适合做高可用,因为整个库复制影响性能。
    不支持故障自动切换。
  要求:
    必须有主键的表才能做复制。

       自从SQL Server 2005以来,微软已经提供了多种高可用性技术来减少宕机时间和增加对业务数据的保护,而随着SQL Server 2008,SQL Server 2008 R2,SQL Server 2012的不断发布,SQL Server中已经存在了满足不同场景的多种高可用性技术。

本文由67677新澳门手机版发布于网络数据库,转载请注明出处:高可用性手艺总结,高可用本事概述

关键词: