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版本能够做为数据库镜像的见证服务器，从而节省了成本。

故障转移集群

    故障转移集群为整个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 Server中提供的高可用性技术以后，咱们再来看一下高可用性策略的设计。高可用性策略的规划能够分为四个阶段：

收集需求

    决定高可用性策略的第一步无疑是收集业务需求来创建SLA。文中以前所述的RTO和RPO是最关键的部分，在此基础之上为可用性需求创建切实可行的指望，并基于该指望创建切实可行的高可用性策略。

评估限制

    评估限制不只仅指的评估是SQL Server中不一样的高可用性技术中的限制，还包括那些非技术的限制。若是只有几万元的预算，却要作基于异地数据中心和SAN复制的高可用方案，那无疑是痴人说梦。另外一个非技术限制是运维人员的水平，一般来讲，复杂的架构意味着须要更高技能的运维人员。其它一些非技术限制包括数据中心的可用磁盘空间、电源供给和空调是否能知足须要，以及实现该可用性策略所须要的时间。

    技术限制则包括不一样高可用性的功能与限制，不一样SQL Server版本所支持的功能以及CPU个数以及内存大小等。强烈建议在实施高可用性策略以前，首先参阅微软MSDN网站上不一样SQL Server版本和功能的限制。

选择技术

    在收集完需求并评估限制以后，接下来就是选择本文前面所述的技术或技术组合来知足SLA的需求。若是所选技术没法知足SLA，则能够很容易的报告出是因为什么限制没法知足SLA，从而能够申请缺乏的资源或在SLA上作出妥协。

测试、验证并文档化

    在高可用性策略一开始实施的时候就须要通过严格的测试和验证，从而确保当前的可用性策略可以知足SLA。但当高可用性策略上线以后，也要按期进行测试和验证来确保当前的策略在数据增加、业务或需求变动的状况下依然能够知足SLA。同时，要把可用性解决方案的配置、故障转移的方法和灾难恢复计划同时文档化，以便于出现故障或是将来调整高可用性策略时有迹可循。

 

小结

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