AlwaysOn 可用性组方案

Posted 2020-08-22

AlwaysOn 可用性组方案

1.可用性组

“可用性组”（Availability Group，简称 AG）针对一组离散的用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。一个可用性组支持一组主数据库以及多组对应的辅助数据库。

每组可用性数据库都由一个“可用性副本”承载。有以下两种类型的可用性副本：

（1）一个“主副本”

    主副本用于承载主数据库。主副本使一组主数据库可用于客户端的读写连接。

（2）多个“辅助副本”

 辅助副本承载一组辅助数据库并作为可用性组的潜在故障转移目标。主副本将每个主数据库的事务日志记录发送到每个辅助数据库。每个辅助副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。

可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。

 

下图显示一个可用性组，该可用性组包含一个主副本和四个辅助副本。支持最多八个辅助副本，包括一个主副本和两个同步提交辅助副本，其中1个主副本和另一个辅助副本之间可以设置为自动故障转移。

 

2. 数据同步与故障转移

“数据同步”的过程实现在数据库级别，主数据库与每个连接的辅助数据库独立进行数据同步。因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。

 

可用性组在可用性副本级别进行故障转移。可用性副本仅在数据库级别提供冗余 － 针对一个可用性组中的该组数据库。但是，故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。

部署 AlwaysOn 可用性组需要一个 WSFC 群集。给定可用性组的每个可用性副本必须位于相同 WSFC 的不同节点上。WSFC 为每个可用性组创建一个资源组，然后监视此资源组，以便评估主副本的运行状况从而决定何时进行故障转移。

 

 

3. 可用性组的优势

   可用性组具有以下优势：

（1）与 FCI 相比，可用性组不依赖于共享存储。

（2）辅助副本数量最多可达到8个（SQL Server 2012 限制为4个）。

（3）辅助副本可以直接提供只读访问。

（4）“数据同步”延迟时间已经极大地缩短，甚至可以“同步提交”。而且可用性组的辅助副本在还原事务日志时不需要断开客户端的已有连接。

（5）提供 VNN 和虚拟 IP 地址，供客户端透明访问。

 

4. 可用性组的不足

   可用性组具有以下不足：

（1）SQL Server 2012 和 SQL Server 2014 必须在企业版中才能启用此功能，增加了用户的投入成本。SQL Server 2016 允许标准版启用“Basic 可用性组”，如果需要全部功能也需要使用企业版。

（2）在部署可用性组的过程中，集中了日志传送、数据库镜像和 FCI 的大部分功能与属性，增加了部署的复杂程度。

 

5. 可用性组互操作性

   AlwaysOn 可用性组与数据库镜像都不支持跨数据库事务和分布式事务。这是因为无法保证事务的原子性和完整性，可能出现逻辑上的不一致。

   AlwaysOn 可用性组与数据库镜像实际上使用相同的数据同步机制（包括使用相同的端点、进程等），因此，这两种技术不可以混合部署。

   在 AlwaysOn 可用性组中仍然可以使用包含的数据库、数据库加密、数据库快照、全文索引、FILESTREAM 功能等。在部署时需要注意各节点对某些共享资源（文件夹、网络磁盘等）的访问权限，以及考虑指定网络资源时使用虚拟网络名称作为计算机名。

 

 

补充说明：

###读写分离####

读写分离并不是数据库自有的功能，因为客户端的连接字符串就已经指定了目标数据库，SQL Server 数据库引擎不会主动在客户端的请求中筛选哪些是只读访问，更不会将只读访问重定向到另一个 SQL Server 实例。

AlwaysOn 可用性组提供了只读路由访问，如果客户端的连接字符串申明了只读单身，那么 AlwaysOn 可用性组侦听器可以根据只读路由表的顺序将连接重定向到只读副本。

读写分离是最初级的负载平衡方案，实现的功能只是将一些只读访问（例如，报表查询，备份等）定向到只读副本，而且必须在设计应用程序时就要考虑如何分摊只读访问。

 

根据只读副本的数据更新的延迟需求，可以考虑采用同步提交（例如，AlwaysOn可用性组）、异步提交（例如，AlwaysOn可用性组、数据库镜像、日志传送、复制等）等解决方案。

 

###分布式系统的 CAP 理论###

数据库的负载平衡是基于分布式架构进行设计的，因此需要了解分布式领域的 CAP 理论。

CAP 理论证明任何分布式系统只可以同时满足以下二点，没法三者兼顾。

◆ C（Consistency）：一致性被称为原子对象，任何的读写都应该看起来是“原子“的，或串行的。写后面的读一定能读到前面写的内容。所有的读写请求都好像被全局排序。

◆ A（Availability）：对任何非失败节点都应该在有限时间内给出请求的回应。（请求的可终止性）

◆ P（Partition Tolerance）：允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失。

 

根据 CAP 理论，架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。其中，关系数据库的 ACID 模型要求的强一致性就以牺牲性能和高可用性为代价，因此很难进行分区，通常部署为“单活”模式，即只能有1个活动节点（CAP理论中的“分区”概念）。如果没有要求强一致性，则可以部署多个活动节点，即“多活”模式。

 

根据具体的业务需求和逻辑结构，可以单独或组合使用负载平衡方案，从而实现满意的性能目标。例如：一家电商的网站，在线订单模块允许少量的数据不一致性（可以通过在线排队等手段进行二次处理；或者通过客服热线进行善后工作），可以考虑 A+P 模式，优先实现性能目标；在线支付模块必须使用 C+A 模式，保证强一致性，以及实现高可用；消息管理、查询统计等模块由于不需要及时响应，则可以考虑 C+P 模式。

 

###Alwayson优点###

  支持最多五个可用性副本。 “可用性副本”是可用性组的实例化，此可用性组由特定的 SQL Server 实例承载，该实例维护属于此可用性组的每个可用性数据库的本地副本。 每个可用性组支持一个主副本和最多四个辅助副本。   

   支持替代可用性模式，如下所示：异步提交模式。 此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。同步提交模式。 此可用性模式相对于性能而言更强调高可用性和数据保护，为此付出的代价是事务延迟时间增加。 一个给定的可用性组可支持最多三个同步提交可用性副本（包括当前主副本）。    

   支持几种形式的可用性组故障转移：自动故障转移、计划的手动故障转移（通常简称为“手动故障转移”）和强制的手动故障转移（通常简称为“强制故障转移”）。    

   利用只读连接访问，与副本的只读连接可以在此副本作为辅助副本运行时访问和读取其数据库。 当副本作为辅助副本运行时，对副本的数据库执行备份操作。通过使用活动辅助功能，可更好地利用辅助硬件资源，从而提高 IT 效率并降低成本。 此外，通过将读意向应用程序和备份作业转移到辅助副本，有助于提高针对主副本的性能。    

   支持每个可用性组的可用性组侦听器。 “可用性组侦听器”是一个服务器名称，客户端可连接到此服务器以访问 AlwaysOn 可用性组的主副本或辅助副本中的数据库。 可用性组侦听器将传入连接定向到主副本或只读辅助副本。 侦听器在可用性组故障转移后提供快速应用程序故障转移。

   关于alwayson的相关术语解释

可用性组 (availability group)：一个容器，用于一组共同实现故障转移的数据库（“可用性数据库”）。   

可用性数据库 (availability database)：属于可用性组的数据库。 对于每个可用性数据库，可用性组将保留一个读写副本（“主数据库”）和一个到四个只读副本（“辅助数据库”）。    

主数据库 (primary database)：可用性数据库的读写副本。    

辅助数据库 (secondary database)：可用性数据库的只读副本。    

可用性副本 (availability replica)：可用性组的实例化，该可用性组由特定的 SQL Server 实例承载，并维护属于该可用性组的每个可用性数据库的本地副本。 存在两种类型的可用性副本：一个“主副本”和一至四个“辅助副本”。    

主副本 (primary replica)：可用性副本使主数据库可用于来自客户端的读写连接，还用于将每个主数据库的事务日志记录发送到每个辅助副本。    

辅助副本 (secondary replica)：维护各可用性数据库的辅助副本的可用性副本，充当可用性组的潜在故障转移目标。 或者，辅助副本可以支持对辅助数据库进行只读访问，并支持对辅助数据库创建备份。    

可用性组侦听器 (availability group listener)：一个服务器名称，客户端可连接到此服务器以访问 AlwaysOn 可用性组的主副本或辅助副本中的数据库。 可用性组侦听器将传入连接定向到主副本或只读辅助副本。    

详情参考：http://technet.microsoft.com/zh-cn/library/hh510230.aspx

Alwayson故障转移群集实例

  作为 SQL Server AlwaysOn 产品/服务的一部分，AlwaysOn 故障转移群集实例利用 Windows Server 故障转移群集 (WSFC) 功能通过冗余在服务器实例级别（故障转移群集实例 (FCI)）提供了本地高可用性。 FCI 是在 Windows Server 故障转移群集 (WSFC) 节点上和（可能）多个子网中安装的单个 SQL Server 实例。 在网络上，FCI 表现得好像是在单台计算机上运行的 SQL Server 实例，但它提供了从一个 WSFC 节点到另一个 WSFC 节点的故障转移（如果当前节点不可用）。   

详情参考：http://technet.microsoft.com/zh-cn/library/ms189134.aspx

  Alwayon可用性组概述

详情参考：http://technet.microsoft.com/zh-cn/library/ff877884.aspx

  Alwayson可用性组入门

建议大家在部署时候，参考入门的步骤进行配置。   

详情参考：http://technet.microsoft.com/zh-cn/library/gg509118.aspx

参考链接：http://543925535.blog.51cto.com/639838/1341805/

本文出自 “一万小时定律” 博客，请务必保留此出处http://daisywei.blog.51cto.com/7837970/1881161