SQLserver高可用专项方案.docx

SQL server高可用方案

一、高可用类型

●Always On 高可用性处理方案，需要sql server 版本在以上

SQL Server Always On 即“全方面高可用性和灾难恢复处理方案”。用户经过使用 Always On 技术，能够提升应用程序可用性，而且经过简化高可用性布署和管理方面工作。

SQL Server Always On 在以下2个等级提供了可用性。

*数据库级可用性

是一个“热备份”技术。在同时提交模式下，主副本数据被同时更新到其它辅助副本，主副本和辅助副本之间能够保持实时同时。当系统监测到主副本发生故障时，辅助副本能够立即成为新主副本。

*实例级可用性

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

当主节点发生故障时，辅助节点提升为主节点并获取共享存放中数据，然后才在这个新主节点服务器中开启 SQL Server 服务。

FCI 是一个“冷备份”技术。辅助节点并不从主节点同时数据，唯一一份数据被保留在共享存放（群集共享磁盘）中。

● 日志传送

日志传送依靠于传统 Windows 文件复制技术和 SQL Server 代理。

主数据库所做出任何数据改变全部会被生成事务日志，这些事务日志将定时备份。然后备份文件被辅助数据库所属实例复制到它当地文件夹，

最终事务日志备份在辅助数据库中进行恢复，从面实现在两个数据库之间异步更新数据。

当主数据库发生故障时，能够使辅助数据库变成联机状态。能够把每一个辅助数据库全部看成“冷备用”数据库

● 其它辅助技术

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

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

SQL server复制

定义及应用：数据库间复制和分发数据和数据库对象，然后在数据库间进行同时操作以维持一致性。 使用复制，能够经过局域网和广域网、拨号连接、无线连接和 Internet 将数据分配到不一样位置和分配给远程或移动用户

sql server复制分成三类：

事务复制通常见于需要高吞吐量服务器到服务器方案（包含：提升可伸缩性和可用性、数据仓库和汇报、集成多个站点数据、集成异类数据和减轻批处理负荷）。

合并复制关键是为可能存在数据冲突移动应用程序或分步式服务器应用程序设计。 常见应用场景包含：和移动用户交换数据、POS（消费者销售点）应用程序和集成来自多个站点数据。

快照复制用于为事务复制和合并复制提供初始数据集；在适合数据完全刷新时也能够使用快照复制。

二、高可用服务器配置：

假如只是需要复制方法，则搭建两台相同硬件配置和操作系统版本和补丁、相同数据库版本和补丁服务器即可

假如需要Always On 高可用方法，即出现故障后系统自动进行切换到备用服务器上，则需要3台(数据库主服务器、监听服务器、从服务器)相同硬件配置和操作系统版本和补丁、相同数据库版本和补丁服务器

三、多种实现方法对比

下表将 SQL Server 常见高可用性处理方案进行综合对比。

对比项目
Always On
Always On
日志传送

实例级
数据库级

副本数量
无
最多8个
无限制

副本可用性
不适用
能够
“备用模式”时能够访问

（只读访问）

对外统一IP地址
是
是
各自独立IP地址

自动故障转移
能够
能够
不能够

故障转移单元
实例
一组数据库
不适用

四、以上多种类型实现方法及优缺点

4.1 日志传送

4.1.1 实现方法

1. 为主数据库创建一个事务日志备份计划

2. 为辅助数据库创建一个文件复制计划

3. 为辅助数据库创建一个事务日志还原计划

4.1.2 优劣势

优点：

能够广泛地布署。经过在多个辅助服务器上配置多个辅助数据库，能够建立多个“冷备用”数据库。

辅助数据库能够提供只读访问，作为报表等应用程序数据源，从而将报表查询等只读访问负载分摊到一个或多个辅助服务器。

局限：

主数据库和辅助数据库分别属于不一样实例，辅助数据库只是被动地进行事务日志恢复，不主动识别主数据库状态，所以日志传送技术不支持自动故障转移。

主数据库和辅助数据库之间异步数据更新被拆分成3个独立步骤来实现，所以会有较大延时。

相关注意事项：

数据库备份进程和事务日志备份进程不能并发运行

 截断事务日志将断开日志链，从而造成日志传送无法正常工作

4.2 Always On 方法

4.2.1 应用方法

对于经过第三方共享磁盘处理方案 (SAN) 进行数据保护，提议你使用 Always On 故障转移群集实例。即实例级可用性

对于经过 SQL Server进行数据保护，提议您使用 Always On 可用性组。即数据库级可用性

在主数据库和备用副本之间传送数据。有同时提交和异步提交两种模式

4.2.1.1 同时提交方法

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

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

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

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

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

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

因为同时提交对性能影响较大，所以 SQL Server 仅许可单向同时提交（从一个主副本单向同时到多个辅助副本）。

而且，SQL Server 严格限制了同时提交副本数量，Always On 可用性组一个主副本最多能够同时向 2 个辅助副本实现同时提交，其它副本则使用异步提交模式。

4.2.1.2  异步提交模式

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

异步提交模式消除了主数据库等候状态，所以这种提交模式对性能几乎没有影响。不过辅助数据库可能碰到更新数据失败情况（比如，因网络故障造成未接收主数据库事务，或写入当地事务日志日志文件时碰到错误），而此时主数据库假如发生故障则可能造成数据丢失。

SQL Server 最多许可 Always On 可用性组拥有 8 个辅助副本，其中同时提交副本数量不能超出2个。

4.2.1.3 Always On 可用性组，--数据库级可用性

Always On 可用性组 是 SQL Server  中引入企业级高可用性和灾难恢复处理方案，可使一个或多个用户数据库可用性达成最高。

 Always On 可用性组 要求 SQL Server 实例驻留在 Windows Server 故障转移群集 (WSFC) 节点上。
“可用性组”（Availability Group，简称 AG）针对一组离散用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。一个可用性组支持一组主数据库和多组对应辅助数据库。
每组可用性数据库全部由一个“可用性副本”承载。有以下两种类型可用性副本：
（1）一个“主副本”
主副本用于承载主数据库。主副本使一组主数据库可用于用户端读写连接。
（2）多个“辅助副本”
辅助副本承载一组辅助数据库并作为可用性组潜在故障转移目标。主副本将每个主数据库事务日志统计发送到每个辅助数据库。每个辅助副本缓存事务日志统计（“硬化”日志），然后将它们应用到对应辅助数据库。
能够配置一个或多个辅助副本以支持对辅助数据库进行只读访问，而且能够将任何辅助副本配置为许可对辅助数据库进行备份。
可用性组优势
可用性组含有以下优势：
（1）和 FCI 相比，可用性组不依靠于共享存放。
（2）辅助副本数量最多可达成8个（SQL Server 限制为4个）。
（3）辅助副本能够直接提供只读访问。
（4）“数据同时”延迟时间已经极大地缩短，甚至能够“同时提交”。而且可用性组辅助副本在还原事务日志时不需要断开用户端已经有连接(需要确定现在使用JDBC驱动是否支持SQL SERVER 以上版本)。
（5）提供 VNN 和虚拟 IP 地址，供用户端透明访问。
可用性组不足
可用性组含有以下不足：
（1）在布署可用性组过程中，集中了日志传送、数据库镜像和 FCI 大部分功效和属性，增加了布署复杂程度。
（2）Always On 可用性组和数据库镜像全部不支持跨数据库事务和分布式事务。这是因为无法确保事务原子性和完整性，可能出现逻辑上不一致。
4.2.1.4 Always On 故障转移群集实例

Windows Server 故障转移群集（Windows Server Failover Cluster，简称 WSFC）由一组物理服务器（节点）组成，这些服务器包含类似硬件配置和相同软件配置
WSFC 服务能够监视由其托管角色（Windows Server 以前称为“服务和应用程序”）运行情况，并依据预设条件进行故障转移处理。
SQL Server 安装在 Always On 故障转移群集实例（Failover Cluster Instance，简称 FCI）每个节点上。不过，在开启过程中，SQL Server 服务不会自动开启，而是交由 WSFC 托管。
Always On FCI 介绍
对于数据库和日志存放，FCI 必需在 FCI 全部节点之间使用共享存放。共享存放形式能够为 WSFC 群集磁盘、SAN 上磁盘或 SMB 上文件共享。这么一来，当发生故障转移时，FCI 中全部节点全部会含有相同实例数据视图。
FCI 使用一个虚拟网络名称（Virtual Network Name，简称 VNN） 和虚拟 IP 地址，应用程序和用户端可使用同一 VNN（或虚拟 IP 地址）连接到 FCI。当发生故障转移时，VNN 会在新活动节点开启后注册到该节点。此过程对于连接到 SQL Server 用户端或应用程序是透明，能够最大程度地缩短出现故障时应用程序或用户端停机时间。
FCI 作为 WSFC 一个“角色”，在一个资源组中运行。群集中一次只有一个节点（活动节点）拥有该资源组。此节点拥有有资源包含：虚拟网络名称、虚拟 IP 地址、共享存放、SQL Server 数据库引擎服务、SQL Server 代理服务、SSAS（假如已安装）、一个文件共享资源（假如安装了 FILESTREAM 功效。
当活动节点出现故障（硬件故障、操作系统故障、应用程序或服务故障）或进行计划升级时，将根据以下次序进行故障转移过程。
（1）将缓冲区全部“脏页”写入磁盘。
（2）停止 FCI 活动节点上全部 SQL Server 对应服务。
（3）资源组全部权转移到 FCI 另一个节点，使其成为新活动节点。
（4）新活动节点开启 SQL Server 对应服务。
（5）用户端应用程序连接请求将自动定向到 VNN 新活动节点。  
 Always On FCI 优势
FCI 含有以下优势：
（1）自动故障转移 FCI 经过冗余在实例级提供保护。
（2）用户端透明连接
应用程序连接到 VNN（或虚拟 IP 地址），而无需知道目前活动节点。当发生故障转移时，VNN 会会自动切换到新活动节点。在故障转移过程中，无需重新配置应用程序和用户端。
 Always On FCI 不足
FCI 含有以下不足：
（1）单一故障点
FCI 必需在全部节点之间使用共享存放，这意味着共享存放有可能成为单个故障点。所以 FCI 依靠于共享存放拥有硬件处理方案来确保数据保护，但这种处理方案往往需要较高成本。
（2）资源利用率
任何时候 FCI 只有1个节点（活动节点）运行 SQL Server 服务，其它节点则处于“冷备用”状态，资源利用率较不高。
4.3复制应用

4.3.1快照复制
特定时刻状态分发数据，而不监视数据是否更新。 发生同时时，将生成完整快照并将其发送到订阅服务器。
当符合以下一个或多个条件时，使用快照复制本身是最适宜：
· 极少更改数据。
· 在一段时间内许可含有相对公布服务器已过时数据副本。
· 复制少许数据。
· 在短期内出现大量更改。
在数据更改量很大，但极少发生更改时，快照复制是最适宜。 比如，假如某销售组织维护一个产品价格列表且这些价格每十二个月要在固定时间进行一两次完全更新，那么提议在数据更改后复制完整数据快照。 对于给定一些类型数据，更频繁快照可能也比较适合。 比如，假如一天中在公布服务器上更新相对小表，但能够接收一定滞后时间，则能够在夜间以快照形式传输更改。
公布服务器上快照复制连续开销低于事务复制开销，因为不用跟踪增量更改。 不过，假如要复制数据集很大，那么若要生成和应用快照，将需要使用大量资源。 评定是否使用快照复制时，需要考虑整个数据集大小和数据更改频率。
和备份区分
先来看快照.
快照,其本质类似于数据库照片,也就是在某个特定时间点(创建快照时间点)给数据库拍个照放在那儿.不过这个照片是一个新数据库,能够应用SQL语句.
快照数据库里数据是不变.创建快照后,系统会对原数据库全部数据页做个标识,假如数据页在创建快照后被修改,会复制一个数据页出来,没有修改数据页则不会有快照(原数据库和快照数据库共用该数据页).
从这么来看,快照存在时间越长,对系统压力会越大(要维护改变数据页太多).
通常来说,快照用在数据库镜像机上,因为镜像机上数据库永远是Restoring状态,能够在某个特定时间点生成一个快照,这么就能够在镜像机上提供一个可访问数据库,用来为数据仓库提供数据源比较适宜.
再来看备份.
备份,其本质是一个副本.相当于在某个时间点把数据库里全部对象内容全部COPY一份,放到一个特定文件里(备份文件,通常是.bak).
这个文件不是一个数据库,不能直接应用SQL,必需先经过还原方法还原到一个数据库(能够是和原数据库名称一致,也能够是一个新数据库),以后才能访问里面数据.
因为备份结果是文件,这个文件能够被COPY走,或写入磁带(放到银行里),从而实现离线容灾.

4.3.2事物复制
事务复制通常从公布数据库对象和数据快照开始。 创建了初始快照后，接着在公布服务器上所做数据更改和架构修改通常在修改发生时（几乎实时）便传输给订阅服务器。 数据更改将根据其在公布服务器上发生次序和事务边界应用于订阅服务器，所以，在公布内部能够确保事务一致性。
事务复制通常见于服务器到服务器环境中，在以下多种情况下适合采取事务复制：
· 期望发生增量更改时将其传输到订阅服务器。
· 从公布服务器上发生更改，至更改抵达订阅服务器，应用程序需要这二者之间滞后时间较短。
· 应用程序需要访问中间数据状态。 比如，假如某一行更改了五次，事务复制将许可应用程序响应每次更改（比如，激发触发器），而不只是响应该行最终数据更改。
· 公布服务器有大量插入、更新和删除活动。
· 公布服务器或订阅服务器不是SQL Server 数据库（比如，Oracle）。
默认情况下，事务公布订阅服务器应视为只读，因为更改不会传输回公布服务器。 不过，事务复制确实提供了许可在订阅服务器上进行更新选项。
要求：
数据库恢复方法不能是简单模式，而且不能截断数据库日志，数据库表必需全部得有主键索引

4.3.3 合并复制
合并复制通常见于服务器到用户端环境中。 合并复制适适用于下列多种情况：
· 多个订阅服务器可能会在不一样时间更新同一数据，并将其更改传输到公布服务器和其它订阅服务器。
· 订阅服务器需要接收数据，脱机更改数据，并在以后和公布服务器和其它订阅服务器同时更改。
· 每个订阅服务器全部需要不一样数据分区。
· 可能会发生冲突，而且在冲突发生时，您需要含有检测和处理冲突能力。
· 应用程序需要最终数据更改结果，而不是访问中间数据状态。 比如，假如在订阅服务器和公布服务器进行同时之前，订阅服务器上行更改了五次，则该行在公布服务器上仅更改一次来反应最终数据更改（也就是第五次更改值）。
合并复制许可不一样站点自主工作，并在以后将更新合并成一个统一结果。 因为更新是在多个节点上进行，同一数据可能由公布服务器和多个订阅服务器进行了更新。 所以，在合并更新时可能会产生冲突，合并复制提供了多个处理冲突方法。
合并复制是由 SQL Server 快照代理和合并代理实现。 假如公布未经筛选或使用静态筛选器，快照代理将创建单个快照。 假如公布使用参数化筛选器，则快照代理将为每个数据分区创建一个快照。 合并代理将初始快照应用于订阅服务器。 它还将合并自初始快照创建后公布服务器或订阅服务器上所发生增量数据更改，并依据所配置规则检测和处理任何冲突。

复制总结：
1、 初始设置比较复杂，需要进行数次模拟才能最终成功，而且不管哪种复制形式全部是异步复制，中间会有延迟损失；
2、 因为复制等业务会影响I/O性能，比较合理方法是使用SSD硬盘，PCI-E卡最好，同时要避免公布和订阅之间网络延迟，SQL Server默认事务隔离等级要设置成READ_COMMITTED_SNAPSHOT；
3、 公布服务器出现问题瘫痪，需要人工进行调整一段时间；
4、 在公布服务器要注意数据库日志文件容量和增加速度，数据库日志文件超大以后会影响系统正常运行，影响硬盘空间利用；