SQLserver⾼可⽤⽅案
SQL server⾼可⽤⽅案
⼀、⾼可⽤的类型
●Always On ⾼可⽤性解决⽅案，需要sql server 版本在2012以上
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台(数据库主服务器、监听服务器、从服务器)相同硬件配
置和操作系统版本与补丁、相同数据库版本和补丁的服务器
三、各种实现⽅式的对⽐
四、以上各种类型的实现⽅式及优缺点
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 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）针对⼀组离散的⽤户数据库（称为“可⽤性数据库”，
它们共同实现故障转移）⽀持故障转移环境。⼀个可⽤性组⽀持⼀组主数据库以及多组对应的辅
助数据库。
每组可⽤性数据库都由⼀个“可⽤性副本”承载。有以下两种类型的可⽤性副本：
（1）⼀个“主副本”
sqlserver2012数据库还原主副本⽤于承载主数据库。主副本使⼀组主数据库可⽤于客户端的读写连接。
（2）多个“辅助副本”
辅助副本承载⼀组辅助数据库并作为可⽤性组的潜在故障转移⽬标。主副本将每个主数据库的事
务⽇志记录发送到每个辅助数据库。每个辅助副本缓存事务⽇志记录（“硬化”⽇志），然后将它
们应⽤到相应的辅助数据库。
可以配置⼀个或多个辅助副本以⽀持对辅助数据库进⾏只读访问，并且可以将任何辅助副本配置
为允许对辅助数据库进⾏备份。
可⽤性组的优势
可⽤性组具有以下优势：
（1）与FCI 相⽐，可⽤性组不依赖于共享存储。
（2）辅助副本数量最多可达到8个（SQL Server 2012 限制为4个）。
（3）辅助副本可以直接提供只读访问。
（4）“数据同步”延迟时间已经极⼤地缩短，甚⾄可以“同步提交”。⽽且可⽤性组的辅助副本在还
原事务⽇志时不需要断开客户端的已有连接(需要确定⽬前使⽤的JDBC驱动是否⽀持SQL SERVER 2014以上的版本)。（5）提供VNN 和虚拟IP 地址，供客户端透明访问。
可⽤性组的不⾜
可⽤性组具有以下不⾜：
（1）在部署可⽤性组的过程中，集中了⽇志传送、数据库镜像和FCI 的⼤部分功能与属性，增加了部署的复杂程度。
（2）Always On 可⽤性组与数据库镜像都不⽀持跨数据库事务和分布式事务。这是因为⽆法保证事务的原⼦性和完整性，可能出现逻辑上的不⼀致。
4.2.1.4 Always On 故障转移集实例
Windows Server 故障转移集（Windows Server Failover Cluster，简称WSFC）由⼀组物理服务器（节点）构成，这些服务器包含类似的硬件配置以及相同的软件配置
WSFC 服务可以监视由其托管的⾓⾊（Windows Server 2012 以前称为“服务和应⽤程序”）的运⾏状况，并根据预设的条件进⾏故障转移处理。
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 相应服务。