SQL 数据库高可用

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

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

很多企 业都需要他们的全部或部分数据高可用,比如说在线购物网站,在线商品数据库必7*24小时在线,否则在 竞争激烈的市场环境下,宕机时 间就意味着流失客户和收入。

 

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

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

• 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。

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

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

• 故障转移集群

• 数据库镜像

• 事务日志传送

• 数据库快照

• AlwaysOn可用性组

• 热加载内存

• 在线索引操作

• 数据库部分在线(只还原 了主文件组或主文件组和额外的NDF文件)

 
故障转移集群

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

事务日志传送

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

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

数据库镜像

数据库 镜像实际上是个软件解决方案,同样提 供了数据库级别的保护,可提供 几乎是瞬时的故障转移,以提高 数据库的可用性。数据库 镜像可以用来维护相应生产数据库(称为“主体数据库”)的单个备用数据库(或“镜像数据库”)。

 

因为镜 像数据库一直处于还原状态,但并不会恢复数据库,因此无 法直接访问镜像数据库。但是,为了用 于报表等只读的负载,可创建 镜像数据库的数据库快照来间接地使用镜像数据库。数据库 快照为客户端提供了快照创建时对数据库中数据的只读访问。每个数 据库镜像配置都涉及包含主体数据库的“主体服务器”,并且还 涉及包含镜像数据库的镜像服务器。镜像服 务器不断地使镜像数据库随主体数据库一起更新。

 

数据库 镜像在高安全性模式下以同步操作运行,或在高 性能模式下以异步操作运行。在高性能模式下,事务不 需要等待镜像服务器将日志写入磁盘便可提交,这样可 较大程度地提高性能。在高安全性模式下,已提交 的事务将由伙伴双方提交,但会延 长事务滞后时间。数据库 镜像的最简单配置仅涉及主体服务器和镜像服务器。在该配置中,如果主体服务器丢失,则该镜 像服务器可以用作备用服务器,但可能 会造成数据丢失。高安全 性模式支持具有自动故障转移功能的备用配置高安全性模式。这种配置涉及到称为“见证服务器”的第三方服务器实例,它能够 使镜像服务器用作热备份服务器。从主体 数据库至镜像数据库的故障转移通常要用几秒钟的时间。

 

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

复制

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

AlwaysOn可用性组

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

 

sol_jc_sql3.jpg

 

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

 

具体何 种版本支持哪些高可用特性,请参阅:http://msdn.microsoft.com/zh-cn/library/cc645993.apx

 
您有任何想法和需求,请致电:

400-635-8089

相关解决方案

Related Solution

>
400-635-8089
友情链接:    大发彩票导航   众赢棋牌官方正版下载   天荣棋牌app   金得胜棋牌   拉手彩票计划