SQLserver高可用方案.docx
《SQLserver高可用方案.docx》由会员分享，可在线阅读，更多相关《SQLserver高可用方案.docx（16页珍藏版）》请在冰豆网上搜索。
SQLserver高可用方案
SQL-server高可用方案
D
实例级
数据库级
副本数量
无
最多8个
无限制
副本的可用性
不适用
可以
“备用模式”时可以访问
（只读访问）
对外统一IP地址
是
是
各自独立的IP地址
自动故障转移
可以
可以
不可以
故障转移单元
实例
一组数据库
不适用
四、以上各种类型的实现方式及优缺点
4.1日志传送
4.1.1实现方式
1.为主数据库创建一个事务日志备份计划
2.为辅助数据库创建一个文件复制计划
3.为辅助数据库创建一个事务日志还原计划
4.1.2优劣势
优点：
可以广泛地部署。
通过在多个辅助服务器上配置多个辅助数据库，可以建立多个“冷备用”数据库。
辅助数据库可以提供只读访问，作为报表等应用程序的数据源，从而将报表查询等只读访问的负载分摊到一个或多个辅助服务器。
局限：
主数据库和辅助数据库分别属于不同的实例，辅助数据库只是被动地进行事务日志恢复，不主动识别主数据库的状态，因此日志传送技术不支持自动的故障转移。
主数据库与辅助数据库之间的异步数据更新被拆分成3个独立的步骤来实现，因此会有较大的延时。
相关注意事项：
数据库备份进程和事务日志备份进程不能并发运行
截断事务日志将断开日志链，从而导致日志传送无法正常工作
4.2AlwaysOn方式
4.2.1应用方式
对于通过第三方共享磁盘解决方案（SAN）进行的数据保护，建议你使用AlwaysOn故障转移群集实例。
即实例级可用性
对于通过 SQLServer进行的数据保护，建议您使用 AlwaysOn可用性组。
即数据库级可用性
在主数据库和备用副本之间传送数据。
有同步提交和异步提交两种模式
4.2.1.1同步提交方式
同步提交时，需要经过一系列的过程。
（1）主数据库在将事务日志写入文件的同时就传送给辅助数据库。
然后主数据库等待辅助数据库的回应。
（2）辅助数据库收到了来自主数据库的事务，写入本地事务日志文件（固化），然后发送确认信息给主数据库。
（3）主数据库收到辅助数据库发来的确认信息，结束等待状态，继续运行。
（4）主数据库在遇到检查点时才将缓存中的“脏页”回写到数据文件；辅助数据库根据收到的事务在本地进行重做（Re-do）。
同步提交模式可以保证时刻拥有着一模一样的副本，因此具有极高的安全性。
但是辅助服务器接收事务日志、写入事务日志文件和发送确认信息这一系列过程也会带来一定程度的延迟，从而影响到主数据库的性能。
由于同步提交对性能影响较大，因此SQLServer仅允许单向的同步提交（从一个主副本单向同步到多个辅助副本）。
而且，SQLServer严格限制了同步提交的副本数量，AlwaysOn可用性组的一个主副本最多可以同时向2个辅助副本实现同步提交，其他副本则使用异步提交模式。
4.2.1.2 异步提交模式
异步提交时，主数据库将事务发送给辅助数据库后，无需等待而直接继续运行。
异步提交模式消除了主数据库的等待状态，因此这种提交模式对性能几乎没有影响。
但是辅助数据库可能遇到更新数据失败的情况（例如，因网络故障导致未接受主数据库的事务，或写入本地事务日志日志文件时遇到错误），而此时主数据库如果发生故障则可能造成数据丢失。
SQLServer2014最多允许AlwaysOn可用性组拥有8个辅助副本，其中同步提交的副本数量不能超过2个。
4.2.1.3AlwaysOn可用性组，--数据库级可用性
AlwaysOn可用性组 是 SQLServer2012 中引入的企业级高可用性和灾难恢复解决方案，可使一个或多个用户数据库的可用性达到最高。
AlwaysOn可用性组 要求 SQLServer 实例驻留在WindowsServer故障转移群集（WSFC）节点上。
“可用性组”（AvailabilityGroup，简称AG）针对一组离散的用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。
一个可用性组支持一组主数据库以及多组对应的辅助数据库。
每组可用性数据库都由一个“可用性副本”承载。
有以下两种类型的可用性副本：
（1）一个“主副本”
主副本用于承载主数据库。
主副本使一组主数据库可用于客户端的读写连接。
（2）多个“辅助副本”
辅助副本承载一组辅助数据库并作为可用性组的潜在故障转移目标。
主副本将每个主数据库的事务日志记录发送到每个辅助数据库。
每个辅助副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。
可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。
可用性组的优势
可用性组具有以下优势：
（1）与FCI相比，可用性组不依赖于共享存储。
（2）辅助副本数量最多可达到8个（SQLServer2012限制为4个）。
（3）辅助副本可以直接提供只读访问。
（4）“数据同步”延迟时间已经极大地缩短，甚至可以“同步提交”。
而且可用性组的辅助副本在还原事务日志时不需要断开客户端的已有连接（需要确定目前使用的JDBC驱动是否支持SQLSERVER2014以上的版本）。
（5）提供VNN和虚拟IP地址，供客户端透明访问。
可用性组的不足
可用性组具有以下不足：
（1）在部署可用性组的过程中，集中了日志传送、数据库镜像和FCI的大部分功能与属性，增加了部署的复杂程度。
（2）AlwaysOn可用性组与数据库镜像都不支持跨数据库事务和分布式事务。
这是因为无法保证事务的原子性和完整性，可能出现逻辑上的不一致。
4.2.1.4AlwaysOn故障转移群集实例
WindowsServer故障转移群集（WindowsServerFailoverCluster，简称WSFC）由一组物理服务器（节点）构成，这些服务器包含类似的硬件配置以及相同的软件配置
WSFC服务可以监视由其托管的角色（WindowsServer2012以前称为“服务和应用程序”）的运行状况，并根据预设的条件进行故障转移处理。
SQLServer安装在AlwaysOn故障转移群集实例（FailoverClusterInstance，简称FCI）的每个节点上。
但是，在启动过程中，SQLServer服务不会自动启动，而是交由WSFC托管。
AlwaysOnFCI简介
对于数据库和日志存储，FCI必须在FCI的所有节点之间使用共享存储。
共享存储的形式可以为WSFC群集磁盘、SAN上的磁盘或SMB上的文件共享。
这样一来，当发生故障转移时，FCI中的所有节点都会具有相同的实例数据视图。
FCI使用一个虚拟网络名称（VirtualNetworkName，简称VNN）和虚拟IP地址，应用程序和客户端可使用同一VNN（或虚拟IP地址）连接到FCI。
当发生故障转移时，VNN会在新的活动节点启动后注册到该节点。
此过程对于连接到SQLServer的客户端或应用程序是透明的，可以最大限度地缩短出现故障时应用程序或客户端的停机时间。
FCI作为WSFC的一个“角色”，在一个资源组中运行。
群集中一次只有一个节点（活动节点）拥有该资源组。
此节点拥有有资源包括：
虚拟网络名称、虚拟IP地址、共享存储、SQLServer数据库引擎服务、SQLServer代理服务、SSAS（如果已安装）、一个文件共享资源（如果安装了FILESTREAM功能。
当活动节点出现故障（硬件故障、操作系统故障、应用程序或服务故障）或进行计划的升级时，将按照以下顺序进行故障转移过程。
（1）将缓冲区的所有“脏页”写入磁盘。
（2）停止FCI活动节点上的所有SQLServer相应服务。
（3）资源组的所有权转移到FCI的另一个节点，使其成为新的活动节点。
（4）新的活动节点启动SQLServer相应服务。
（5）客户端应用程序的连接请求将自动定向到VNN的新的活动节点。
AlwaysOnFCI的优势
FCI具有以下优势：
（1）自动故障转移FCI通过冗余在实例级提供保护。
（2）客户端透明连接
应用程序连接到VNN（或虚拟IP地址），而无需知道当前活动节点。
当发生故障转移时，VNN会会自动切换到新的活动节点。
在故障转移过程中，无需重新配置应用程序和客户端。
AlwaysOnFCI的不足
FCI具有以下不足：
（1）单一故障点
FCI必须在所有的节点之间使用共享存储，这意味着共享存储有可能成为单个故障点。
因此FCI依赖于共享存储拥有的硬件解决方案来确保数据保护，但这种解决方案往往需要较高的成本。
（2）资源利用率
任何时候FCI只有1个节点（活动节点）运行SQLServer服务，其他节点则处于“冷备用”状态，资源利用率较不高。
4.3复制应用
4.3.1快照复制
特定时刻的状态分发数据，而不监视数据是否更新。
发生同步时，将生成完整的快照并将其发送到订阅服务器。
当符合以下一个或多个条件时，使用快照复制本身是最合适的：
∙很少更改数据。
∙在一段时间内允许具有相对发布服务器已过时的数据副本。
∙复制少量数据。
∙在短期内出现大量更改。
在数据更改量很大，但很少发生更改时，快照复制是最合适的。
例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。
对于给定的某些类型的数据，更频繁的快照可能也比较适合。
例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。
发布服务器上快照复制的连续开销低于事务复制的开销，因为不用跟踪增量更改。
但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。
评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。
与备份的区别
先来看快照.
快照,其本质类似于数据库的照片,也就是在某个特定时间点（创建快照的时间点）给数据库拍个照放在那儿.但是这个照片是一个新的数据库,可以应用SQL语句.
快照数据库里的数据是不变的.创建快照后,系统会对原数据库的所有数据页做个标识,如果数据页在创建快照后被修改,会复制一个数据页出来,没有修改的数据页则不会有快照（原数据库和快照数据库共用该数据页）.
从这样来看,快照存在的时间越长,对系统的压力会越大（要维护的变化数据页太多）.
一般来说,快照用在数据库的镜像机上,因为镜像机上的数据库永远是Restoring状态,可以在某个特定的时间点生成一个快照,这样就可以在镜像机上提供一个可访问的数据库,用来为数据仓库提供数据源比较合适.
再来看备份.
备份,其本质是一个副本.相当于在某个时间点把数据库里的所有对象内容都COPY一份,放到一个特定的文件里（备份文件,一般是.bak）.
这个文件不是一个数据库,不能直接应用SQL,必须先通过还原的方式还原到一个数据库（可以是和原数据库名称一致,也可以是一个新的数据库）,之后才能访问里面的数据.
因为备份的结果是文件,这个文件可以被COPY走,或者写入磁带（放到银行里）,从而实现离线容灾.
4.3.2事物复制
事务复制通常从发布数据库对象和数据的快照开始。
创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。
数据更改将按照其在发布服务器上发生的顺序和事务边界应用于订阅服务器，因此，在发布内部可以保证事务的一致性。
事务复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务复制：
∙希望发生增量更改时将其传播到订阅服务器。
∙从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。
∙应用程序需要访问中间数据状态。
例如，如果某一行更改了五次，事务复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。
∙发布服务器有大量的插入、更新和删除活动。
∙发布服务器或订阅服务器不是SQLServer数据库（例如，Oracle）。
默认情况下，事务发布的订阅服务器应视为只读，因为更改不会传播回发布服务器。
但是，事务复制确实提供了允许在订阅服务器上进行更新的选项。
要求：
数据库的恢复方式不能是简单模式，并且不能截断数据库日志，数据库表必须都得有主键索引
4.3.3合并复制
合并复制通常用于服务器到客户端的环境中。
合并复制适用于下列各种情况：
∙多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
∙订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
∙每个订阅服务器都需要不同的数据分区。
∙可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
∙应用程序需要最终的数据更改结果，而不是访问中间数据状态。
例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。
合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。
由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。
因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法。
合并复制是由 SQLServer 快照代理和合并代理实现的。
如果发布未经筛选或使用静态筛选器，快照代理将创建单个快照。
如果发布使用参数化筛选器，则快照代理将为每个数据分区创建一个快照。
合并代理将初始快照应用于订阅服务器。
它还将合并自初始快照创建后发布服务器或订阅服务器上所发生的增量数据更改，并根据所配置的规则检测和解决任何冲突。
复制总结：
1、初始设置比较复杂，需要进行多次模拟才能最终成功，并且无论哪种复制形式都是异步复制，中间会有延迟的损失；
2、由于复制等业务会影响I/O性能，比较合理的方式是使用SSD硬盘，PCI-E卡最佳，同时要避免发布与订阅之间的网络延迟，SQLServer默认事务隔离级别要设置成READ_COMMITTED_SNAPSHOT；
3、发布服务器出现问题瘫痪，需要人工进行调整一段时间；
4、在发布服务器要注意数据库的日志文件的容量和增长速度，数据库日志文件超大之后会影响系统的正常运行，影响硬盘空间的利用；
升级会员 