SQL Server关于AlwaysOn的理解

（一）SQL Server-AlwaysOn 技术：SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”

1、数据库级可用性-只读副本：SQL Server 2012-4个，SQL Server 2014-8个
a、每个节点都安装了本地的 SQL Server，可以不使用共享存储，但是数据库在每个节点上的磁盘文件夹必须是一致的。
b、主节点可读可写，其它辅助节点只可读。
c、全部节点都加入一个 Windows Fail-over Cluster 中。
可以为AlwaysOn可用性组配置一个侦听器（虚拟计算机）。客户端如果访问这个侦听器则可以实现read/write；客户端如果访问指定的辅助节点，可能实现read/write（如果该节点是主节点），或者只能read-only。

负载分离：
a、可以将一部分的read only请求发送到辅助副本：
1）第一种：修改应用程序，在客户端实现。例如，指定将read/write都指向AlwaysOn可用性组的侦听器（不赞成指向某个节点，因为无法确保某个节点可以write），将部分read only请求指向辅助副本。
2）第二种：为AlwaysOn可用性组配置只读路由：
脚本如下：
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'COMPUTER01' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'COMPUTER01' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.contoso.com:1433'));

连接字符串中添加只读意向：
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True

2、群集：实例级可用性-AlwaysOn 故障转移群集实例可以在最多16个节点（企业版才支持16个节点，标准版只支持2个节点）间实现故障转移（Fail-over）。
a、数据库必须位于共享存储。这可能是单一故障点。一旦共享存储崩溃了，SQL Server 服务将停止，数据将全部丢失。
b、任何时刻只有主节点提供 SQL Server 服务，其它节点的 SQL Server 服务（实例）处于“冷备”状态。当主节点的SQL Server服务发生故障时，才自动转移，然后由另一个备用节点继续提供服务。

（二）群集与侦听器
一、群集
1、 MSFC-Microsoft Failover Cluster：创建SQL Server群集之前，必须在Windows中实现一个MSFC，然后再将SQL Server安装成为MSFC中的一个“服务与应用程序”
2、节点：同一时间只能在其中一个节点（主节点）运行这个SQL Server实例
3、Fail-over：故障转移群集是用于获得高可用性的，而非用于实现负载平衡，只有在发生故障时才会转移，而不是负载平衡（Load Balance）
4、仲裁-节点配置方式：仲裁需要使用投票机制，得票超过半数的节点才能成为主节点。
　Windows Server 2003-2个节点加1个仲裁磁盘。
　Windows Server 2008则推荐使用节点多数（奇数个节点），当节点数量为偶数时才推荐添加一个仲裁磁盘。也就是说，Windows Server 2008 创建 Microfost Windows Cluster 时，仲裁磁盘（共享存储）并不是必须的。

二、侦听器
侦听器在MSFC中被称为虚拟网络名称（Virtual Network Name）
MSFC自身就有一个侦听器，客户端可以直接访问这个侦听器。对这个侦听器的访问被MSFC重定向到主节点。
1、MSFC的侦听器
2、SQL Server Cluster的侦听器
3、AlwaysOn可用性组的侦听器
a、访问AlwaysOn可用性组的侦听器
b、直接访问指定的节点

（三）共享磁盘
1、共享磁盘-在群集技术中可能会用到共享磁盘。这类磁盘可以被多个节点同时访问，但任一时间只有主节点对共享磁盘享有使用权。
2、使用共享磁盘的场景
a、在搭建MSFC时，如果是偶数个节点，那么可以添加一个仲裁磁盘，从而使投票时可以形成“多数”
b、SQL Server Cluster的数据磁盘
SQL Server Cluster的本质，是将所有的SQL Server数据库放在一个所有节点共享的磁盘上，当主节点Fail时，下一个节点通过获得共享磁盘的使用权，从而顺利启动SQL Server实例（服务）。

（四）故障转移
1、SQL Server 故障转移群集
实例级的故障转移—备用节点需要较长的时间启动SQL Server服务，然后读取共享磁盘上的数据，最后才接管旧节点上的客户端请求，有时候为了实现特定的目的，需要手动将服务从一个节点切换到另一个节点
2、AlwaysOn可用性组的故障转移
数据库级的故障转移—在故障转移之前，各节点的SQL Server服务已经开启，并且数据已经同步提交（节点之间实时同步）。因此数据库级的故障转移速度非常快（通常在10秒内完成）。也可以手动将主副本转移到新的节点。

（五）数据库镜像
数据库镜像是SQL Server 2005 sp1正式引入的一项数据库级的高可用性技术。
1、镜像的实现-镜像是主体服务器、镜像服务器和见证服务器（见证服务器为可选项）之间通过TCP5022端口进行实时通信从而实现数据同步或监控。
2、镜像的3种运行模式
a、高性能（异步）-主体服务器上的更改被异步传送给镜像服务器。由于是异步执行，因此对性能的影响很小
b、高安全（同步）-主体服务器上的更改被同步传送给镜像服务器，而且只有当这些更改同时主体和镜像服务器上完成之后主体服务器才可以继续下一个更改。
c、高可用（同步）-数据的更改模式与高安全模式时相同。此模式必须存在一台见证服务器，监控主体与镜像服务器的运行状态。如果主体服务器变得不可用，则见证服务器会控制自动故障转移到镜像服务器。
3、镜像的故障转移
a、服务器端-如果有见证服务器，则由见证服务器控制自动故障转移。也可以手动控制。
b、客户端-由于镜像技术没有采用MSFC作为底层，因此客户端直接连接在原来的主体服务器。
可以在客户端的连接字符串中添加镜像服务器的IP地址，那么客户端在连接主体服务器失败时会自动尝试连接镜像服务器。
添加连接字符器的方法，请参考 http://technet.microsoft.com/zh-cn/library/ms175484.aspx

4、镜像技术的不足

a、客户端不能连接到一个虚拟网络名称。
b、对于标准版的用户，镜像只能使用高安全（同步）模式，通常都会对性能带来很大的影响。一般在实现镜像之前都需要对数据库做一次性能调整与优化。
c、只能针对单个数据库。例如，SharePoint用户希望同时对一组数据库实现高可用，而镜像只能一个一个地对数据库实现。
d、镜像服务器上的数据库一直处于“正在还原”状态，只能通过创建快照才能实现只读访问。

（六）日志传送
1、日志传送的实现
日志传送依赖于传统的Windows技术与SQL Server代理。
a、为主数据库创建一个事务日志备份计划
b、为辅助数据库创建一个文件复制计划
c、为辅助数据库创建一个事务日志还原计划

2、事务日志还原的选项
a、无恢复模式—在这种模式时，辅助数据库在做事务日志还原时使用WITH NORECOVERY选项（未提交的事务没有被回滚），数据库一直处于“正在还原”状态，不可以访问。
b、备用模式—在这种模式时，辅助数据库在做事务日志还原时使用WITH STANDBY选项（将未提交的事务在一个临时文件中回滚）。数据库处于“只读，备用”状态，可以提供只读访问。

3、日志传送的优势：广泛地部署。辅助数据库可以提供只读访问，作为报表等应用程序的数据源。
4、日志传送的不足：不支持自动的故障转移。数据同步被拆分成3个步骤实现，因此会有较大的延时

（七）复制
复制是一个开发范畴的技术，但是也可以像日志传送一样作为高可用技术的一个后备选项。
1、复制的拓扑
2、复制的冲突处理
a、合并复制—合并复制允许存在冲突。当冲突发生时，合并复制将比较这些记录的时间戳，仅保留最新的记录（时间戳最后的那条记录）。
b、专用的写入区—一种方式是将read请求随机发送给任意一个数据库，而将write指定只写入发布服务器。另一种方式是设置专用的写入区，所有写入被事先隔离，从而避免冲突。
3、复制在负载均衡中的应用—在一些稍微容忍数据同步存在延迟的场合，复制可以作为负载均衡的手段。这种实现方法，其实质是通过复制实现分布式数据库。

（八）负载平衡

1、服务的类型
a、无状态的服务（stateless service）：对单次请求的处理，不依赖其他请求。
　　处理一次请求所需的全部信息都包含在这个请求里或者可以从外部获取（例如，数据库），服务本身不存储任何信息。
　　IIS（Web服务）可以设计成无状态的服务，可以实现池化（负载均衡），从而横向扩展。

b、有状态的服务（stateful service）：会在自身保存一些数据。先后的请求是有关联的，通常用于实现事务。数据库服务一般是有状态的服务。

2、区别
a、高可用—针对“有状态”的服务，其目标是为了减少硬件或软件故障造成的影响，保持业务的连续性，从而将用户可以察觉到的停机时间送到最少。
b、负载平衡—针对“无状态”的服务，其目标是通过对服务的“池化”（多个服务，形成一个“池”）使客户端的请求被分摊到多个服务

3、联系
a、高可用技术中兼具一部分的负载分摊功能。
b、负载均衡给客户端的感觉就像高可用技术一样，保持了业务的连续性。

4、SQL Server 负载分离示例
生产环境通常在设计时就要考虑到未来的数据增长，并且预留负载分离的接口。

巴特西

SQL Server关于AlwaysOn的理解

最新文章

热门文章