SQL Server HA - 高可用性解决方案解决方案概述

“AlwaysOn”一词至少在 SQL Server 2008 中已经出现，表示 SQL Server 可以持续地提供服务。但是当时“AlwaysOn”技术并没有提供管理界面（通过 Windows 管理工具进行管理），所以这个字样鲜为人知。 尽管 SQL Server 2012 在 SSMS 中出现了“AlwaysOn”专用管理工具，但是其只能管理 AlwaysOn 可用性组，导致常被误解为 AlwaysOn 只有（或者等同于）可用性组这一种技术。 SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”。客户通过使用 AlwaysOn 技术，可以提高应用程序可用性，并且通过简化高可用性的部署和管理方面的工作，获得更好的硬件投资回报。

高可用性解决方案概述

1　可用性

　　可用性是指在某个考察时段内，系统能够正常运行的概率或者时间占有率的期望值。。通常用以下公式进行计算，值越大则表明系统宕机时间越少。

 

 

 

 

例如，对于一个 24*365 运行的业务系统，99.999% 的可用性表示每年宕机时间不超过 5 分钟。当然，正常预定的维护时间（即窗口）一般不计入宕机时间。例如，营业时间仅限于从上午7点到晚上10点（即7*15）的业务系统，在下班后进行停机维护的时间不算在宕机时间之内。

　　高可用性（High-Availability）是一系列的技术总和，用来减少宕机时间和增加对业务数据的保护。

　　在规划高可用性方案时需要综合考虑以下两个因素：

● RTO（Recovery Time Objective，即目标恢复时间）

　　RTO 表示业务系统每次容忍多少宕机时间。如果业务停顿时间过长，损失自然也会增加。对于特别重要的业务系统，可能需要同时使用多种技术确保在发生故障时能够迅速恢复业务。

● RPO（Recovery Point Objective，即目标恢复点）

　　RPO 表示容忍多少数据丢失。通常只要做好备份，就可以使数据不丢失。但当灾难发生时，从备份进行恢复的操作会导致数据库在现阶段不可用；如果恢复的时间特别长，业务停顿所造成的损失可能比丢失少量数据更严重。特别对于数据量非常大的数据库，更需要预先考虑到恢复时间和数据丢失之间的权重而制定充足的预案。

　　通常 RTO 与 RPO 两者之间存在冲突，需要根据业务需求、投资规模等多方面因素来权衡，从而制订服务水平协议（Service Level Agreement，简称 SLA）。

2　AlwaysOn 高可用性解决方案

　　“AlwaysOn”一词至少在 SQL Server 2008 中已经出现，表示 SQL Server 可以持续地提供服务。但是当时“AlwaysOn”技术并没有提供管理界面（通过 Windows 管理工具进行管理），所以这个字样鲜为人知。

　　尽管 SQL Server 2012 在 SSMS 中出现了“AlwaysOn”专用管理工具，但是其只能管理 AlwaysOn 可用性组，导致常被误解为 AlwaysOn 只有（或者等同于）可用性组这一种技术。

　　SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”。客户通过使用 AlwaysOn 技术，可以提高应用程序可用性，并且通过简化高可用性的部署和管理方面的工作，获得更好的硬件投资回报。

　　SQL Server AlwaysOn 在以下2个级别提供了可用性。

● 数据库级可用性

　　AlwaysOn 可用性组（Availability Group，简称 AG）是SQL Server 2012 引入的新特性，它允许将一组数据库（一个或多个用户数据库）传送到最多4个只读副本。SQL Server 2014 将只读副本的数量提升到8个。

　　AG 可以是一种“热备份”技术。在同步提交模式下，主副本的数据被同步更新到其他辅助副本，主副本与辅助副本之间可以保持实时同步。当系统监测到主副本发生故障时，辅助副本可以立即成为新的主副本。

　　由于这是一个数据库级的技术，因此在 SSMS 中提供了管理和配置界面。

 

 

 

● 实例级可用性

　　AlwaysOn 故障转移群集实例（Failover Cluster Instance，简称 FCI）可以在多个16个节点之间实现故障转移（Failover）。企业版最多支持16个节点，标准版只支持2个节点）

　　FCI 是一种“冷备份”技术。辅助节点并不从主节点同步数据，唯一的一份数据被保存在共享存储（群集共享磁盘）中。当主节点发生故障时，辅助节点提升为主节点并获取共享存储中的数据，然后才在这个新的主节点服务器中启动 SQL Server 服务。

　　SQL Server 2012 对 FCI 技术做了一些改进，例如，可以不使用群集共享磁盘而使用共享文件夹，可以将 tempdb 配置在本地驱动器。

　　由于这是一个实例（服务器）级的技术，因此 SQL Server 没有为它提供单独的管理界面，而是在 Windows 管理工具中的“故障转移群集管理器”界面中进行管理和配置，

 

 

 

3　其它高可用性解决方案

● 数据库镜像

　　数据库镜像是 SQL Server 2005 SP1 正式引入的一项数据库级的高可用性技术。

　　镜像可以是一种“暖备份”技术。主体服务器与镜像服务器同时运行着 SQL Server 服务，镜像服务器从主体服务器获得备份数据后立即进行还原，从而实现了镜像服务器的数据更新。镜像服务器同时也会获得少量的元数据，当主体服务器发生故障时，镜像服务器可迅速加载所需的所有元数据，然后成为新的主体服务器。

　　数据库镜像技术存在着许多不足，SQL Server 2012 的联机手册就已经申明将在未来的版本中取消镜像技术。

● 日志传送

　　日志传送依赖于传统的 Windows 文件复制技术与 SQL Server 代理。

　　主服务器定期产生一个备份文件，辅助服务器再定期通过访问 Windows 文件夹从而读取并复制这些备份文件然后定期恢复到本地的数据库。实际上，日志传送技术只是分别在主服务器和辅助服务器上实现了自动备份与自动还原而已。

● 其它辅助技术

　　对数据库进行备份，当出现故障时，手动将数据还原到服务器，使得数据库重新联机，这也可以算作实现高可用性的一种技术手段。

　　复制（Replication）并不算是一个高可用性解决方案，只是它的功能可以实现高可用性。复制通过“发布-订阅”模式，由主服务器向辅助服务器发布数据，使这些服务器间实现可用性。

4　各项技术的综合对比

下表将 SQL Server 常用的高可用性解决方案进行综合对比。

 

对比项目	AlwaysOn故障转移群集	AlwaysOn可用性组	数据库镜像	日志传送
副本数量	无	最多8个	1个	无限制
副本的可用性 （只读访问）	不适用	可以	创建快照，然后访问快照	“备用模式”时可以访问
对外统一IP地址	是	是	各自独立的IP地址	各自独立的IP地址
自动故障转移	可以	可以	可以（需要有见证服务器）	不可以
故障转移单元	实例	一组数据库	单个数据库	不适用

 

5　同步提交与异步提交

AlwaysOn 可用性组、数据库镜像等解决方案需要为主数据库建立一个或多个“热备用”或“温备用”的辅助副本，因此需要在主数据库和备用副本之间传送数据。

　　在主数据库和备用副本之间进行数据更新，有以下两种模式。

◆ 同步提交模式

　　同步提交时，需要经过一系列的过程。

（1）主数据库在将事务日志写入文件的同时就传送给辅助数据库。然后主数据库等待辅助数据库的回应。

（2）辅助数据库收到了来自主数据库的事务，写入本地事务日志文件（固化），然后发送确认信息给主数据库。

（3）主数据库收到辅助数据库发来的确认信息，结束等待状态，继续运行。

（4）主数据库在遇到检查点时才将缓存中的“脏页”回写到数据文件；辅助数据库根据收到的事务在本地进行重做（Re-do）。

 

同步提交模式可以保证时刻拥有着一模一样的副本，因此具有极高的安全性。但是辅助服务器接收事务日志、写入事务日志文件和发送确认信息这一系列过程也会带来一定程度的延迟，从而影响到主数据库的性能。

　　由于同步提交对性能影响较大，因此 SQL Server 仅允许单向的同步提交（从一个主副本单向同步到多个辅助副本）。而且，SQL Server 严格限制了同步提交的副本数量，AlwaysOn 可用性组的一个主副本最多可以同时向 2 个辅助副本实现同步提交，其他副本则使用异步提交模式。。

◆ 异步提交模式

　　异步提交时，主数据库将事务发送给辅助数据库后，无需等待而直接继续运行。

　　异步提交模式消除了主数据库的等待状态，因此这种提交模式对性能几乎没有影响。但是辅助数据库可能遇到更新数据失败的情况（例如，因网络故障导致未接受主数据库的事务，或写入本地事务日志日志文件时遇到错误），而此时主数据库如果发生故障则可能造成数据丢失。

　　SQL Server 2014 最多允许 AlwaysOn 可用性组拥有 8 个辅助副本，其中同步提交的副本数量不能超过2个。

 

本文来自云海天，作者：古道轻风，转载请注明原文链接：https://www.cnblogs.com/88223100/p/SQL_Server_HA-High_Availability_Solutions_Solution_Overview.html