浅谈SQL Server中的高可用性(1) 高可用性概览

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

在文章开始之前,我首先简单概述一下以什么来决定使用哪一种高可用性技术。

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

很多企业都需要他们的全部或部分数据高可用,比如说在线购物网站,在线商品数据库必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。

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

股东能够接受的宕机时间是多少?

管理人员能够接受的宕机时间是多少?

为高可用性方案提供的预算是多少?

宕机导致的损失是每小时是多少钱?

冷备份、暖备份和热备份

根据主机和备机之间同步数据的程度,备份可以分为三种情况,分别为冷备份、暖备份和热备份。

冷备份:也就是所谓的备份,备用服务器被配置用于接受主服务器的数据,当出故障时,手动将数据还原到主数据库,或是重新配置程序的连接字符串或权限来使得备份数据库上线。

暖备份:主服务器数据会不停的将日志传送到备用服务器(间隔不定,可以是15分钟,30分钟,1分钟等等),在这方式下,主服务器到备份服务器通常是异步更新,所以不能保证主服务器和备份服务器数据一致。此外,该方案通常不会实现自动故障监测和故障转移。

热备份:主服务器的数据自动在备份服务器上进行同步,大多数情况下都会包含自动的故障监测和故障转移,并且能够保证主服务器和备份服务器的数据一致性。

随着冷备份到暖备份到热备份,成本会直线上升。

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

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

l 故障转移集群

l 数据库镜像

l 事务日志传送

l 数据库快照

l 高可用性升级

l 热加载内存

l 在线索引操作

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

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

时间: 2024-12-22 04:16:50

浅谈SQL Server中的高可用性(1) 高可用性概览的相关文章

浅谈SQL Server中的快照

原文:浅谈SQL Server中的快照 简介     数据库快照,正如其名称所示那样,是数据库在某一时间点的视图.是SQL Server在2005之后的版本引入的特性.快照的应用场景比较多,但快照设计最开始的目的是为了报表服务.比如我需要出2011的资产负债表,这需要数据保持在2011年12月31日零点时的状态,则利用快照可以实现这一点.快照还可以和镜像结合来达到读写分离的目的.下面我们来看什么是快照.   什么是快照     数据库快照是 SQL Server 数据库(源数据库)的只读静态视图

浅谈SQL Server中的高可用性(2) 文件与文件组

在谈到SQL Server的高可用性之前,我们首先要谈一谈单实例的高可用性.在单实例的高可用性中,不可忽略的就是文件和文件组的高可用性.SQL Server允许在某些文件损坏或离线的情况下,允许数据库依然保持部分在线,从而保证了高可用性. 文件和文件组 有关文件和文件组的基本概念,有很多文章已经阐述过了.这里我只是提一下,文件组作为SQL Server访问文件的一个抽象层而存在.因此SQL Server上所做的操作不是直接针对文件,而是针对文件组. 使用多个文件组和文件不仅仅是为了分散IO和提高

浅谈SQL Server中的三种物理连接操作(性能比较)_MsSql

在SQL Server中,我们所常见的表与表之间的Inner Join,Outer Join都会被执行引擎根据所选的列,数据上是否有索引,所选数据的选择性转化为Loop Join,Merge Join,Hash Join这三种物理连接中的一种.理解这三种物理连接是理解在表连接时解决性能问题的基础,下面我来对这三种连接的原理,适用场景进行描述. 嵌套循环连接(Nested Loop Join) 循环嵌套连接是最基本的连接,正如其名所示那样,需要进行循环嵌套,嵌套循环是三种方式中唯一支持不等式连接的

浅谈SQL Server中的三种物理连接操作(性能比较)

在SQL Server中,我们所常见的表与表之间的Inner Join,Outer Join都会被执行引擎根据所选的列,数据上是否有索引,所选数据的选择性转化为Loop Join,Merge Join,Hash Join这三种物理连接中的一种.理解这三种物理连接是理解在表连接时解决性能问题的基础,下面我来对这三种连接的原理,适用场景进行描述. 嵌套循环连接(Nested Loop Join) 循环嵌套连接是最基本的连接,正如其名所示那样,需要进行循环嵌套,嵌套循环是三种方式中唯一支持不等式连接的

浅谈SQL Server中统计对于查询的影响分析_MsSql

而每次查询分析器寻找路径时,并不会每一次都去统计索引中包含的行数,值的范围等,而是根据一定条件创建和更新这些信息后保存到数据库中,这也就是所谓的统计信息. 如何查看统计信息 查看SQL Server的统计信息非常简单,使用如下指令: DBCC SHOW_STATISTICS('表名','索引名') 所得到的结果如图1所示.         图1.统计信息 统计信息如何影响查询     下面我们通过一个简单的例子来看统计信息是如何影响查询分析器.我建立一个测试表,有两个INT值的列,其中id为自增

浅谈SQL Server中统计对于查询的影响

简介 SQL Server查询分析器是基于开销的.通常来讲,查询分析器会根据谓词来确定该如何选择高效的查询路线,比如该选择哪个索引.而每次查询分析器寻找路径时,并不会每一次都去统计索引中包含的行数,值的范围等,而是根据一定条件创建和更新这些信息后保存到数据库中,这也就是所谓的统计信息. 如何查看统计信息 查看SQL Server的统计信息非常简单,使用如下指令: DBCC SHOW_STATISTICS('表名','索引名') 所得到的结果如图1所示. 图1.统计信息 统计信息如何影响查询 下面

浅谈SQL Server中统计对于查询的影响分析

而每次查询分析器寻找路径时,并不会每一次都去统计索引中包含的行数,值的范围等,而是根据一定条件创建和更新这些信息后保存到数据库中,这也就是所谓的统计信息. 如何查看统计信息 查看SQL Server的统计信息非常简单,使用如下指令: DBCC SHOW_STATISTICS('表名','索引名') 所得到的结果如图1所示. 图1.统计信息 统计信息如何影响查询 下面我们通过一个简单的例子来看统计信息是如何影响查询分析器.我建立一个测试表,有两个INT值的列,其中id为自增,ref上建立非聚集索引

谈一谈SQL Server中的执行计划缓存(下)

原文:谈一谈SQL Server中的执行计划缓存(下) 简介     在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法.   将执行缓存考虑在内时的流程     上篇文章中提到了查询优化器解析语句的过程,当将计划缓存考虑在内时,首先需要查看计划缓存中是否已经有语句的缓存,如果没有,才会执行编译过程,如果存在则直接利用编译好的执行计划.因此,完整的过程如图1所示. 图1.将计划缓存考虑在内的过程      

谈一谈SQL Server中的执行计划缓存(上)

原文:谈一谈SQL Server中的执行计划缓存(上) 简介     我们平时所写的SQL语句本质只是获取数据的逻辑,而不是获取数据的物理路径.当我们写的SQL语句传到SQL Server的时候,查询分析器会将语句依次进行解析(Parse).绑定(Bind).查询优化(Optimization,有时候也被称为简化).执行(Execution).除去执行步骤外,前三个步骤之后就生成了执行计划,也就是SQL Server按照该计划获取物理数据方式,最后执行步骤按照执行计划执行查询从而获得结果.但查询