SQLserver高可用方案

《SQLserver高可用方案》由会员分享，可在线阅读，更多相关《SQLserver高可用方案（14页珍藏版）》请在装配图网上搜索。

1、SQL server高可用方案一、高可用的类型Always On 高可用性解决方案，需要sql server 版本在2012以上SQL Server Always On 即“全面的高可用性和灾难恢复解决方案”。客户通过使用 Always On 技术，可以提高应用程序可用性，并且通过简化高可用性的部署和管理方面的工作。SQL Server Always On 在以下2个级别提供了可用性。*数据库级可用性是一种“热备份”技术。在同步提交模式下，主副本的数据被同步更新到其他辅助副本，主副本与辅助副本之间可以保持实时同步。当系统监测到主副本发生故障时，辅助副本可以立即成为新的主副本。*实例级可用性Al

2、ways On 故障转移群集实例（Failover Cluster Instance，简称 FCI）可以在多个16个节点之间实现故障转移（Failover）。企业版最多支持16个节点，标准版只支持2个节点。当主节点发生故障时，辅助节点提升为主节点并获取共享存储中的数据，然后才在这个新的主节点服务器中启动 SQL Server 服务。FCI 是一种“冷备份”技术。辅助节点并不从主节点同步数据，唯一的一份数据被保存在共享存储（群集共享磁盘）中。 日志传送日志传送依赖于传统的 Windows 文件复制技术与 SQL Server 代理。主数据库所做出的任何数据变化都会被生成事务日志，这些事务日志将定

3、期备份。然后备份文件被辅助数据库所属的实例复制到它的本地文件夹，最后事务日志备份在辅助数据库中进行恢复，从面实现在两个数据库之间异步更新数据。当主数据库发生故障时，可以使辅助数据库变成联机状态。可以把每一个辅助数据库都当作“冷备用”数据库 其它辅助技术对数据库进行备份，当出现故障时，手动将数据还原到服务器，使得数据库重新联机，这也可以算作实现高可用性的一种技术手段。复制（Replication）并不算是一个高可用性解决方案，只是它的功能可以实现高可用性。复制通过“发布-订阅”模式，由主服务器向辅助服务器发布数据，使这些服务器间实现可用性。SQL server复制定义及应用：数据库间复制和分发数

4、据和数据库对象，然后在数据库间进行同步操作以维持一致性。 使用复制，可以通过局域网和广域网、拨号连接、无线连接和 Internet 将数据分配到不同位置以及分配给远程或移动用户sql server复制分成三类：事务复制通常用于需要高吞吐量的服务器到服务器方案（包括：提高可伸缩性和可用性、数据仓库和报告、集成多个站点的数据、集成异类数据以及减轻批处理的负荷）。 合并复制主要是为可能存在数据冲突的移动应用程序或分步式服务器应用程序设计的。 常见应用场景包括：与移动用户交换数据、POS（消费者销售点）应用程序以及集成来自多个站点的数据。 快照复制用于为事务复制和合并复制提供初始数据集；在适合数据完全

5、刷新时也可以使用快照复制。二、高可用的服务器配置： 如果只是需要复制方式，则搭建两台相同硬件配置和操作系统版本与补丁、相同数据库版本和补丁的服务器即可如果需要Always On 高可用方式，即出现故障后系统自动进行切换到备用服务器上，则需要3台(数据库主服务器、监听服务器、从服务器)相同硬件配置和操作系统版本与补丁、相同数据库版本和补丁的服务器三、各种实现方式的对比下表将 SQL Server 常用的高可用性解决方案进行综合对比。对比项目Always OnAlways On日志传送实例级数据库级副本数量无最多8个无限制副本的可用性不适用可以“备用模式”时可以访问（只读访问）对外统一IP地址是是

6、各自独立的IP地址自动故障转移可以可以不可以故障转移单元实例一组数据库不适用四、以上各种类型的实现方式及优缺点4.1 日志传送4.1.1 实现方式 1. 为主数据库创建一个事务日志备份计划2. 为辅助数据库创建一个文件复制计划3. 为辅助数据库创建一个事务日志还原计划4.1.2 优劣势优点：可以广泛地部署。通过在多个辅助服务器上配置多个辅助数据库，可以建立多个“冷备用”数据库。辅助数据库可以提供只读访问，作为报表等应用程序的数据源，从而将报表查询等只读访问的负载分摊到一个或多个辅助服务器。局限：主数据库和辅助数据库分别属于不同的实例，辅助数据库只是被动地进行事务日志恢复，不主动识别主数据库的状

7、态，因此日志传送技术不支持自动的故障转移。主数据库与辅助数据库之间的异步数据更新被拆分成3个独立的步骤来实现，因此会有较大的延时。相关注意事项：数据库备份进程和事务日志备份进程不能并发运行截断事务日志将断开日志链，从而导致日志传送无法正常工作4.2 Always On 方式4.2.1 应用方式对于通过第三方共享磁盘解决方案 (SAN) 进行的数据保护，建议你使用 Always On 故障转移群集实例。即实例级可用性对于通过SQL Server进行的数据保护，建议您使用Always On 可用性组。即数据库级可用性在主数据库和备用副本之间传送数据。有同步提交和异步提交两种模式4.2.1.1 同步

8、提交方式同步提交时，需要经过一系列的过程。（1）主数据库在将事务日志写入文件的同时就传送给辅助数据库。然后主数据库等待辅助数据库的回应。（2）辅助数据库收到了来自主数据库的事务，写入本地事务日志文件（固化），然后发送确认信息给主数据库。（3）主数据库收到辅助数据库发来的确认信息，结束等待状态，继续运行。（4）主数据库在遇到检查点时才将缓存中的“脏页”回写到数据文件；辅助数据库根据收到的事务在本地进行重做（Re-do）。同步提交模式可以保证时刻拥有着一模一样的副本，因此具有极高的安全性。但是辅助服务器接收事务日志、写入事务日志文件和发送确认信息这一系列过程也会带来一定程度的延迟，从而影响到主数据

9、库的性能。由于同步提交对性能影响较大，因此 SQL Server 仅允许单向的同步提交（从一个主副本单向同步到多个辅助副本）。而且，SQL Server 严格限制了同步提交的副本数量，Always On 可用性组的一个主副本最多可以同时向 2 个辅助副本实现同步提交，其他副本则使用异步提交模式。4.2.1.2 异步提交模式异步提交时，主数据库将事务发送给辅助数据库后，无需等待而直接继续运行。异步提交模式消除了主数据库的等待状态，因此这种提交模式对性能几乎没有影响。但是辅助数据库可能遇到更新数据失败的情况（例如，因网络故障导致未接受主数据库的事务，或写入本地事务日志日志文件时遇到错误），而此时主

10、数据库如果发生故障则可能造成数据丢失。SQL Server 2014 最多允许 Always On 可用性组拥有 8 个辅助副本，其中同步提交的副本数量不能超过2个。4.2.1.3 Always On 可用性组，-数据库级可用性 Always On 可用性组是SQL Server 2012中引入的企业级高可用性和灾难恢复解决方案，可使一个或多个用户数据库的可用性达到最高。Always On 可用性组要求SQL Server实例驻留在 Windows Server 故障转移群集 (WSFC) 节点上。“可用性组”（Availability Group，简称 AG）针对一组离散的用户数据库（称为“

11、可用性数据库”，它们共同实现故障转移）支持故障转移环境。一个可用性组支持一组主数据库以及多组对应的辅助数据库。 每组可用性数据库都由一个“可用性副本”承载。有以下两种类型的可用性副本： （1）一个“主副本” 主副本用于承载主数据库。主副本使一组主数据库可用于客户端的读写连接。 （2）多个“辅助副本” 辅助副本承载一组辅助数据库并作为可用性组的潜在故障转移目标。主副本将每个主数据库的事务日志记录发送到每个辅助数据库。每个辅助副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。 可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据

12、库进行备份。 可用性组的优势 可用性组具有以下优势： （1）与 FCI 相比，可用性组不依赖于共享存储。 （2）辅助副本数量最多可达到8个（SQL Server 2012 限制为4个）。 （3）辅助副本可以直接提供只读访问。 （4）“数据同步”延迟时间已经极大地缩短，甚至可以“同步提交”。而且可用性组的辅助副本在还原事务日志时不需要断开客户端的已有连接(需要确定目前使用的JDBC驱动是否支持SQL SERVER 2014以上的版本)。 （5）提供 VNN 和虚拟 IP 地址，供客户端透明访问。 可用性组的不足可用性组具有以下不足：（1）在部署可用性组的过程中，集中了日志传送、数据库镜像和 FC

13、I 的大部分功能与属性，增加了部署的复杂程度。 （2）Always On 可用性组与数据库镜像都不支持跨数据库事务和分布式事务。这是因为无法保证事务的原子性和完整性，可能出现逻辑上的不一致。 4.2.1.4 Always On 故障转移群集实例 Windows Server 故障转移群集（Windows Server Failover Cluster，简称 WSFC）由一组物理服务器（节点）构成，这些服务器包含类似的硬件配置以及相同的软件配置 WSFC 服务可以监视由其托管的角色（Windows Server 2012 以前称为“服务和应用程序”）的运行状况，并根据预设的条件进行故障转移处理。

14、 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） 和虚

15、拟 IP 地址，应用程序和客户端可使用同一 VNN（或虚拟 IP 地址）连接到 FCI。当发生故障转移时，VNN 会在新的活动节点启动后注册到该节点。此过程对于连接到 SQL Server 的客户端或应用程序是透明的，可以最大限度地缩短出现故障时应用程序或客户端的停机时间。 FCI 作为 WSFC 的一个“角色”，在一个资源组中运行。群集中一次只有一个节点（活动节点）拥有该资源组。此节点拥有有资源包括：虚拟网络名称、虚拟 IP 地址、共享存储、SQL Server 数据库引擎服务、SQL Server 代理服务、SSAS（如果已安装）、一个文件共享资源（如果安装了 FILESTREAM 功能。

16、 当活动节点出现故障（硬件故障、操作系统故障、应用程序或服务故障）或进行计划的升级时，将按照以下顺序进行故障转移过程。 （1）将缓冲区的所有“脏页”写入磁盘。 （2）停止 FCI 活动节点上的所有 SQL Server 相应服务。 （3）资源组的所有权转移到 FCI 的另一个节点，使其成为新的活动节点。 （4）新的活动节点启动 SQL Server 相应服务。 （5）客户端应用程序的连接请求将自动定向到 VNN 的新的活动节点。 Always On FCI 的优势 FCI 具有以下优势： （1）自动故障转移 FCI 通过冗余在实例级提供保护。 （2）客户端透明连接 应用程序连接到 VNN（或虚

17、拟 IP 地址），而无需知道当前活动节点。当发生故障转移时，VNN 会会自动切换到新的活动节点。在故障转移过程中，无需重新配置应用程序和客户端。 Always On FCI 的不足 FCI 具有以下不足： （1）单一故障点 FCI 必须在所有的节点之间使用共享存储，这意味着共享存储有可能成为单个故障点。因此 FCI 依赖于共享存储拥有的硬件解决方案来确保数据保护，但这种解决方案往往需要较高的成本。 （2）资源利用率 任何时候 FCI 只有1个节点（活动节点）运行 SQL Server 服务，其他节点则处于“冷备用”状态，资源利用率较不高。 4.3复制应用 4.3.1快照复制特定时刻的状态分发数

18、据，而不监视数据是否更新。发生同步时，将生成完整的快照并将其发送到订阅服务器。当符合以下一个或多个条件时，使用快照复制本身是最合适的： 很少更改数据。 在一段时间内允许具有相对发布服务器已过时的数据副本。 复制少量数据。 在短期内出现大量更改。在数据更改量很大，但很少发生更改时，快照复制是最合适的。 例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。 对于给定的某些类型的数据，更频繁的快照可能也比较适合。 例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。发布服务器

19、上快照复制的连续开销低于事务复制的开销，因为不用跟踪增量更改。 但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。 评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。与备份的区别先来看快照.快照,其本质类似于数据库的照片,也就是在某个特定时间点(创建快照的时间点)给数据库拍个照放在那儿.但是这个照片是一个新的数据库,可以应用SQL语句.快照数据库里的数据是不变的.创建快照后,系统会对原数据库的所有数据页做个标识,如果数据页在创建快照后被修改,会复制一个数据页出来,没有修改的数据页则不会有快照(原数据库和快照数据库共用该数据页).从这样来看,快照存在的

20、时间越长,对系统的压力会越大(要维护的变化数据页太多).一般来说,快照用在数据库的镜像机上,因为镜像机上的数据库永远是Restoring状态,可以在某个特定的时间点生成一个快照,这样就可以在镜像机上提供一个可访问的数据库,用来为数据仓库提供数据源比较合适.再来看备份.备份,其本质是一个副本.相当于在某个时间点把数据库里的所有对象内容都COPY一份,放到一个特定的文件里(备份文件,一般是.bak).这个文件不是一个数据库,不能直接应用SQL,必须先通过还原的方式还原到一个数据库(可以是和原数据库名称一致,也可以是一个新的数据库),之后才能访问里面的数据.因为备份的结果是文件,这个文件可以被COP

21、Y走,或者写入磁带(放到银行里),从而实现离线容灾.4.3.2事物复制事务复制通常从发布数据库对象和数据的快照开始。 创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。 数据更改将按照其在发布服务器上发生的顺序和事务边界应用于订阅服务器，因此，在发布内部可以保证事务的一致性。事务复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务复制： 希望发生增量更改时将其传播到订阅服务器。 从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。 应用程序需要访问中间数据状态。 例如，如果某一行更改了五次，事务

22、复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。 发布服务器有大量的插入、更新和删除活动。 发布服务器或订阅服务器不是SQL Server 数据库（例如，Oracle）。默认情况下，事务发布的订阅服务器应视为只读，因为更改不会传播回发布服务器。 但是，事务复制确实提供了允许在订阅服务器上进行更新的选项。要求： 数据库的恢复方式不能是简单模式，并且不能截断数据库日志，数据库表必须都得有主键索引4.3.3 合并复制合并复制通常用于服务器到客户端的环境中。合并复制适用于下列各种情况： 多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅

23、服务器。 订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。 每个订阅服务器都需要不同的数据分区。 可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。 应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。因此，在合并更新时可能会产生冲突，合并复制提

24、供了多种处理冲突的方法。合并复制是由SQL Server快照代理和合并代理实现的。如果发布未经筛选或使用静态筛选器，快照代理将创建单个快照。如果发布使用参数化筛选器，则快照代理将为每个数据分区创建一个快照。合并代理将初始快照应用于订阅服务器。它还将合并自初始快照创建后发布服务器或订阅服务器上所发生的增量数据更改，并根据所配置的规则检测和解决任何冲突。复制总结：1、 初始设置比较复杂，需要进行多次模拟才能最终成功，并且无论哪种复制形式都是异步复制，中间会有延迟的损失；2、 由于复制等业务会影响I/O性能，比较合理的方式是使用SSD硬盘，PCI-E卡最佳，同时要避免发布与订阅之间的网络延迟，SQL Server默认事务隔离级别要设置成READ_COMMITTED_SNAPSHOT；3、 发布服务器出现问题瘫痪，需要人工进行调整一段时间；4、 在发布服务器要注意数据库的日志文件的容量和增长速度，数据库日志文件超大之后会影响系统的正常运行，影响硬盘空间的利用；