《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 实现方式 https:/ 为主数据库创建一个事务日志备份计划2. 为辅助数据库创建一个文件复制计划3. 为辅助数据库创建一个事务日志还原计划4.1.2 优劣势优点：可以广泛地部署。通过在多个辅助服务器上配置多个辅助数据库，可以建立多个“冷备用”数据库。辅助数据库可以提供只读访问，作为报表等应用程序的数据源，从而将报表查询等只读访问的负载分摊到一个或多个辅助服务器。局限：主数据库和辅助数据库分别属于不同的实例，辅助数据库只是被动地进行事务日志恢复，不主动识别主
7、数据库的状态，因此日志传送技术不支持自动的故障转移。主数据库与辅助数据库之间的异步数据更新被拆分成3个独立的步骤来实现，因此会有较大的延时。相关注意事项：数据库备份进程和事务日志备份进程不能并发运行截断事务日志将断开日志链，从而导致日志传送无法正常工作4.2 Always On 方式4.2.1 应用方式对于通过第三方共享磁盘解决方案 (SAN) 进行的数据保护，建议你使用 Always On 故障转移群集实例。即实例级可用性对于通过SQL Server进行的数据保护，建议您使用Always On 可用性组。即数据库级可用性在主数据库和备用副本之间传送数据。有同步提交和异步提交两种模式4.2.1
8、.1 同步提交方式同步提交时，需要经过一系列的过程。（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 可用性组，-数据库级可用性 https:/ 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）在部署可用性组的过程中，集中了日志传送、数据库镜像和 FCI 的大部分功能与属性，增加了部署的复杂程度。 （2）Always On 可用性组与数据库镜像都不支持跨数据库事务和分布式事务。这是因为无法保证事务的原子性和完整性，可能出现逻辑上的不一致。 4.2.1.4 Always On 故障转移群集实例 https:/
