SQL server高可用方案 —、高可用的类型
•AlwaysOn高可用牲解决方案，需要sqlserver版本在2012以上
SQL Server Always On即“全面的髙可用性和灾难恢复解决方案”。客户iiil使用Always On技术,可以提髙应用 用11的部署和管
理方面的工作。
SQL Server Always On在以下2个级别提旅了可用性。
*数据库级可用性 是一种“热备份”技术。在同步提交模式下，主副本的数掘被同步更新到其他籀助副本，主制本与箱助副本之IP 到主副本发生故障时，辅助剧本可以立即威为新的主副本。
\"实傍圾可用性 Always On故障转務雅集实M （ Failover Cluster Instance,简称FCI）可以在多个16个节直之同实现故障转移（Faile 点，标准版
只支持2f节自。
当主节点发生故常附，舖助节点提开为主节点并获取共享存嵋中的Uffi,然后才在这个新的主节点服务器中启3）
FCI是一种“冷爸卅”技术。籀助节自并不从主节自同步数据，唯一的一卅数据被保存在共享存储（稲集其享砒舌
•日志传送
日志传送依賴于传鋭的Windows文件复科技术与SQL Server代理。
主数据库所做岀的任何数据变化那会被生成事务日志，这些事务日志将定期备份。然后笛份文件ffiSM数据库所b 最后事务日志备悅在稱助数松库中aiitift,从面实现在两个数据库之间异步更新数据。
当主数掘库发生故障时，可以使舖助数掘库变成朋机状态。可以把每一彳、帝助数据库都当作“冷爸用”数松库
-可修编-
•其它稱助技术
刘数据库进行备份，当出现故障时，手动将数据还原到JR务器，使得数据库重新联机，这也可以算作实现高可用 fi «
（ Replication ）并不算是一个高可用性解决方案,只是它的功能可以实现高可用性。复制通过“发布JT阅” ♦ 发布数掘，使这些服务器间实现可ffltto
SQL server fi 制
定义及应用：数据库间口制和分发数据和数据库对象，然后在数松库间进行同; 可以通il局
域网和广域网、按号连接、无线连接和Internet将数据分配到不同 sql server ft制什成三类：
事务夏對通常用于需耍髙吞吐量的服务器到服务器方案（色括：提髙可伸编性 成多个站点的数据、集威异类数据以及减轻批处理的负荷）。
合并复*1主要是为可能存在数掘冲突的務別应用程序或分步成服务器应用程序 務朋用户交换数据、P0S （消贾者第售直）应用程序以及集成来自多个站点的 快照复匍用于为事务ft H
ID合并R制提険材始数掘集；在适合数据完全削新时
二、髙可用的服务器配置:
如杲只是需要复制方或，则搭建两台相同硕件配置和探作系统版本与补T、相 可 如杲Always On高可用方茨，即岀现故障后系貌自3）进行切换到备用服务 务器、U听服务器、从BR务譽）相同領件配置和H作系貌版本与补丁、相同5U
三、各种实现方式的对比
下表擀SQL Server常用的高可用It解决方案进行妹合对比。 Always On 对比咦目 实図圾 -可修编-
Always On 敬册库级 M本数量 副本的可用性 (只读诉冋) 对外统一IP ittt 自动故障转務 故常转務单元 无 不适用 最乡8f 可以 是 可以 实例 是 可以 —组数据库 01、以上各种类型的实现方式及优缺点
4.1日志传送
4.1.1 实现方衣 https://technet.microsoft./zh-/library/ms1900(v=sql.110).aspx 1. 为主数据库创建一f事务日志备卅计划 2. 为箱助数折库创建一个文件filhttU 3. 为稱助数据库创建一个事务日志il原计划 4.1.2优劣势
可以广泛地部署。通过在名个埔助服务器上配置数松库，可以建立多个“冷备用”数据库。
-可修编-
藉助数掘库可以提0!只读前问，作为报表等应用程序的数SS,从而将报表査询等只读1S冋的负我分拯到一个或 局限：
主数据库fii库分别协干不同的实用，库只是祓动地进行事务日志恢更，不主朋识别主数松库的： 自动的故障转移。
主数据库与ffiMUffi库之间的异步数据更新被拆分咸3个奴立的步骤来实现，因此会有较大的延时。
相关注»9»：
数掘库备份进程和事务日志gfftffl程不能并发运行 裁断事务日志将Bi开日志fi, U而导致日志传送无常工作
4.2 Always On 方衣
4.2.1应用方式
对于通过第三方共享磁盘解决方案(SAN)进行的数据保护，建议你使用Always On JU< H fHI集实例。即奚 对于a il SQL Server fl fi的数据保护,建垃您使用Always On njffltti。即数据库级可用性 在主数掘库皿备用副本之间传送数据。有同步提交和异步提交两种模式
4.2.1.1同步提交方衣
同步提交附，需耍经过一系列的过程。
(1) 主数据库在将事务日志写人文件的同时就传送给帝助数据库。然后主数据库等库的回应。
(2) IHUIUK库收到了来自主数据库的事务，耳入本地事务日志文件(固化)，然后发送确从信息给主数据库。 (3) 主数据库收到辅助数Jg库发来的确认信息，结東等侍状态，址续运行。
(4) 主数据库在遇到检查点时才将缓存中的“册页”回写到St摒文件;藉助数据库根松收到的事务在本地进行重
同步提交模式可以保证附刻拥有着一模一样的M本,因此具有様高的安全性。但是辅腐服务器接收事务日志、写
•可修编・
这一系列11程也会带来一定程度的延世，八而影响到主数掘库的性能。
由于同步提交对11能影唱较大,因此SQL Server仅允许单向的同步提交(从_个主BI本单向同步到多个辅助副本 而且,SQL
Server严格了同步提交的副本数量，Always On可用性组的—个主樹本最多可以同时向2个辅助 使用异步提交模式。
4.2.1.2异步提交模氏
异步提交附，主敎据库将事务发送f&ISffl数掘库后，无需等待而11接地续运行。
异步提交模式消除了主数据库的等持状态，因此这种提交模式对性能几乎没有影响。但是舖助数需库可能遇到更; 络故障导致未接受主数据库的事务，或写入本地事务日志日志文件时酒到錯俣)，而此时主数据库如果发生故障1 SQL Server 2014最多允许Always
On可用性组拥有8个箱助副本，其中同步提交的副本数量不能超过2个。
4.2.1.3 Always On可用性组，—数据库级可用牲
https://docs.microsoft./zh-/sql/database-eMine/availability-0roups/windows/availability-niodes-always-on-availability-Qro
Always On可用性组是SQL Server 2012中引入的企业级髙可用性皿灾难恢口解决方案，可使一个或名f用户 Always On可用性组要求SQL Server实例驻留在Windows Server故障转務诽集(WSFC)节点上。
“可用(Availability Group,简称AG)打对一组离散的用户数摒库(称为“可用性钦据库\"，
•£ 111 tt同实现故障转務)支持故常转粽坏境。一个可用性组支持一组主数据库以及马组对应的捕
助数据库。
每组可用性数掘库都由一个“可用11副本”承我。有以下两种类里的可用性副本：
(D-f \"主剧本”
-可修编-
主副本用主数据库。主副本使一组主数掘库可用于客户端的读耳连接。
(2) 多个“箱助副本”
|«Ma本承裁一组稱助数姐库并作为可用性组的潜在故障转粽目标。主副本将每彳、主数据库的事 务日志记录发送到每个辅助数据
库。每个辅助樹本缓存事务日志记录(“哽化”日志)，然后将 它们应用到相应的稱助数松库。
可以配置一个或多个轴助剧本以支持对辅助数掘库逍行只读前问，并且可以将任何箱助副本配置 为允贰对库进行备份。
可用性组的优势
可用性组具有以下优势：
(1) 与PCI相比，可用性组不依顿于共享存6L
(2 )辅助BI本数量最多可达到8个(SQL Server 2012为4个)。
(3) 藉助副本可以宜接提供只读«r«io
(4) “数松同步”延迟时间已经机大地细短，甚至可以“同步提交”。而且可用性组的帝助副本 在迹原事务日志时不需要斷开客户
端的已有连接(需更禽定目雷使用的J DBC驱动是否支持SQL SERVER2014以上的版本)。
(5) 提供VNN fOgffl IP地址，快客户端透明前肌
可用性组的不足
可用11组具有以下不足：
(1 )在部署可用性组的ii程中,集中了日志传送、数粥库镜像和FCI的大部分功能弓属性，增 ®TS署的复杂程度。
(2 ) Always On可用性组与数据库镜像都不支持胯数据库事务皿分布貳事务。逹是因为无法保址 事务的原子性和完整性，可能岀现逻
轲上的不一致。
-可修编-
4.2.1.4 Always On故障转移群集实例
https://docs.microsoft./zh-/sql/sql-server/failover-clusters/windows/windows-server-failover-clusterinQ -wsfc-with-sql-server
Windows Server 故障转移滞集(Windows Server Failover Cluster,简称 WSFC )由一组物理服务器
(节点)构成，这些服务器包含类111的硕件配置以及相同的軟件配置
WSFC服务可以监視由其托管的角色(Windows Server 2012以前称为“JK务和应用程序”)的运 行状况，并根掘预设的条件进行故
障转務处理。
SQL Server安装在Always On故障转朽群集实用(Failover Cluster Instance,简称FCI)的每个节点 ±o IS是，在启动过程中，SQL Server服务不会自动启动，而是交由WSFC托管。 Always On FCI 简介
对于钦据库fll日志存储，FCI必须在FCI的所有节点之间使用共享存储。共享存储的形武可以为 WSFC SI集施盘、SAN上的砒盘或
SMB上的文件共享。这样一来，当发生故障转粽时，FCI中 的所有节点稲会具有相同的实例数摒視图。
FCI使用一个虛Hl网络gf$ (Virtual Network Name,简fii VNN) IP地址，应用程序和客户
端可使用同一VNN (或虚抵IP地址)连接到FCI。当发生故障转務时，VNN会在新的活朋节自 启动后注册到该节点。此U程对干连接到SQL Server的客户端或应用程序是透明的，可以最大陨 度地编犯岀现故障时应用程序或客户端的停机时间。
FCI作为WSFC的一f “角色”，在一f资源组中运行。曲集中一次只有一f节点(活动节虫) 拥有该资瀰组。此节点拥有有资潔包
括：虚松网络名称、虚加IP地址、共享存B. SQLServer数 据库引擎服务、SQL Server代理JR务、SSAS (如果已安装)、一个文件共享资澹(如果安装了 FILESTREAM 功能。
当活动节点岀现故常(哽件故障、It作系貌散辑、应用程序或服务故障)或ilfiitiUffJft级时， 将按照以下U序进行故障转務过程。
(1) 将缓冲区的所有“册页”耳人虧盘。
-可修编-
(2) 停止FCI活动节点上的所有SQL Server相应服务。
(3) 资滌组的所有权转够到FCI的另一个节点，使其成为新的活朋节点。
(4) 新的活动节虑启动SQL Server相应服务。
(5) 客户端应用程序的连接请求将自动定向到VNN的新的活动节点。 Always On FCI 的优势
FCI具有以下优势:
（1） 自动故障转務FCI通过冗余在实侧级提供保护。
（2） 客户端透明连接
应用程序连接到VNN（或虚si IP地址），而无SBlifi当前活动节点。当发生故障转粽时，VNN会 会自3）切换到新的活动节点。在故障转務iif?中，无需重新配置应用程序fl!客户端。
Always On FCI 的不足
FCI具有以下不足：
（1） 单一il障点
FCI必须在所有的节自之间使用共享存JS.fi意味着共享存储有可能咸为单个故障虫。因此FCI依 额于共享存储拥有的硕件解决方案来
确保数松保护，但这种解决方案伎往需要较髙的成本。
（2） 资滌利用率
-可修编-
任何时候FCI只有1个节点（活动节点）运行SQL Server服务，其他节点则处于“冷备用\"状 态，资淵利用率较不髙。
4・3复制应用 https://docs・microsoft・/zh-/sql/relational-databases/replication/types-of -replication
4.3.1快服复胃
特定时列的状态分发数据，而不监视数松是否更新。发生同步时，将生成完整的快照并将其发送 到订阅服务器。
当符合以下一彳、或乡个条件时，使用快照复制本身是最合适的：
•很少更auffio
•在一段时间允许具有相对发布服务器已u时的钦折副本。 •复嗣少量数AL ・在短期出现大量更改。
在数掘更改量很大，但很少发生更改时，快照度制是最合适的。例如，咖漿某细售组纵维护一彳、 产品价怡列表冃这些IHSS年要在固定附间进行一两次完全更新，那么建放在数松更改后R制完 整tflilffi快照。对于给定的某些类里的数据，更破繁的快照可能也比较适合。例如，如杲一天中 在发布服务器上更新相对小的表，但可以接受一定的滞后时间，刚可以在夜间以快朋形式传递更 改。
发布股务器上快照an(ft连续开第低于事务
R制的开孙，因为不量更改。但是，如果要 更制的数据集非常大，那么若要生成利应用
快照，将需耍使用大量资滌。评估是否使用快照更尅 时，需要考虑整个数据集的大小以及数据的更改顾率。
与备份的区别
先来看快照•快廉，其本质类似于数据库的照片，也就是在某个特定时同点（创建快照的时同贞）给数 据库拍个照故在那儿•但是fit
pa片是一个新的数摒库,可以应用SQL语旬.
快照数据库里的数掘是不变的卫建快照后，系筑会对原数据库的所有数松页做个标识，如果数据页 在创建快照后祓修改，会巫制一个数据页出来，没有修改的数据页则不会有快照（原数松库和快照数 据库共用该数掘页）.
从这样来看，快照存在的时间n长，对系竦的压力会蕾大（要錐护的变化数据页丈多）.一般来 说,快照用在数掘库的镜像机上，因为
-可修编-
镜像机上的数据库永远是Restoring状态,可以在某个特定的时 间点生成一个快照卫样就可以在镜像机上提供一个可历问的数据库,用来为数据仓库提供数据瀏 比较合适.
再来看备份•备份，其本质是一个副本•相当于在某f时间点把数16库里的所有对象容那COPY —乩 放到一个特定的文件里（备愉文件，一般是-bak）.
这个文件不是一个数据库，不能II接应用SQL,必须先通过连原的方武II原到一个数松库（可以是HI 原数掘库名称一致，也可以是一个新的数据库）,之后才能is冋里面的数松.
因为备怡的给果是文件泌个文件可11« COP Y走,或者写人屜带（故到扳行里）,U而实现离线容女.
4.3.2事物复制
事务应制通常从发布数据库对象皿数据的快照开始。创建了初始快照后，接着在发布服务器上所 做的数据更改皿架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。数据更改将按照 其在发布服务器上发生的U序和事务边界应用于订阅服务器，因此，在发布部可以保址事务的一 致性。
事务Q制通常用于服务器到服务器从境中，在以下各种悄猊下适合采用事务应制:
•希里发生增量更改时将其传播到i]•阅服务器。
•从发布服务器上发生更改，至更改到达订阅服务器， 应用程序需嬰逆两者之河的滞后
时间较现。
・应用程序需要ifi问中间数掘状态。«»,如果某一行 更改了五次，事务允许应用程序响
应每次更改 （用如，激发紋发器），而不只是响应该行最终的数 据更改。 •发布服务器有大量的插入、更新和剧除活动。
•发布服务器或i]■阅服务器不是SQL Server数据库（例 如，Oracle ）。
默从情况下，事务发布的订阅服务器应视为只读，因力更改不会传播阿发布服务器。但是，事务 复制81实提0! 了允许在订阅服务器
-可修编-
ifflff更新的选顶。
耍求：
数折库的恢交方式不能是简单模式，并且不能啟Bi数松库日志，数据库表必须稲胃有王廻索引
4.3.3合并复制
合并复制通常用于服务器到客户端的坏境中。合并直制适用于卞列各种
• ^tiT阅服务器可能会在不同时间更新同一数掘，并將其更改传播到发布服务器皿其他iJ
阅服务器。
・iJ阅服务器需要接收数据，IR机更改数据，并在以后与发布服务器和其他订阅服务器同步 更改。
・ 每fiJ阅服务器稲需要不同的数16分区。
・ 可能会发生冲突，并且在冲突发生时，您需要具有检測利解决冲突的能力。
・ 应用程序需要最终的数据更改结果，而不是诉问中间数折状态。例如，如果在iJ阅服务器 与发布服务器进行同步之前，订阅服
务器上的行更改了五a, MKR在发布服务器上仅更 改一次来反映最终数松更改（也就是第五次更改的值）。
合并夏制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。由于更新是在 乡个节点上进行的，同一数据可能由发布服务器和名fiJ阅服务器iilfiT更新。K1此，在 合并更新时可能会产生冲突，合并夏制提供了乡种处理冲突的方法。
合并更制是由SQL Server快照代理和合并代理实现的。如果发布未经筛选或使用静态晞选 器，快照代理将创建单个快照。如杲发布使用参数化筛选器，刚快照代理将为每个数据分 区创建一彳、快照。合并代理将初始快照应用于iJ阅服务器。它il将合并自初始快照御建后 发布服务器或订阅服务器上所发生的增量数松更改，并根摒所配置的規则检測和解决任何 冲突。
-可修编-
复制总结：
1、 初始设置比较更杂，需要afi^a模ai才能最终成功，并且无论呱种复制形式稲是异步更 制,中同会有延迟的损失；
2、 由f &II等业务会影响l/Oft能，比较合理的方式是使用SSD «盘，PCI-E卡最佳，同时耍 遐免发布与订阅之间的网络延迟，
SQL Server iA事务隔离级别要设置成 READ_MITTED_SNAPSHOT；
3、 发布服务器出现问趙抵換，需要人IiSfi调整一段时间;
4、 在发布服务器要注意数据库的日志文件的容量和增长速度，数据库日志文件超大之后会影
响系貌的正常Efi,影卵盘空间的利用；
•可修编・
