SQLserver高可用方案文档格式.docx
《SQLserver高可用方案文档格式.docx》由会员分享，可在线阅读，更多相关《SQLserver高可用方案文档格式.docx（18页珍藏版）》请在冰豆网上搜索。
*实例级可用性
AlwaysOn故障转移群集实例（FailoverClusterInstance，简称FCI）可以在多个16个节点之间实现故障转移（Failover）。
企业版最多支持16个节点，标准版只支持2个节点。
当主节点发生故障时，辅助节点提升为主节点并获取共享存储中的数据，然后才在这个新的主节点服务器中启动SQLServer服务。
FCI是一种“冷备份”技术。
辅助节点并不从主节点同步数据，唯一的一份数据被保存在共享存储（群集共享磁盘）中。
●日志传送
日志传送依赖于传统的Windows文件复制技术与SQLServer代理。
主数据库所做出的任何数据变化都会被生成事务日志，这些事务日志将定期备份。
然后备份文件被辅助数据库所属的实例复制到它的本地文件夹，
最后事务日志备份在辅助数据库中进行恢复，从面实现在两个数据库之间异步更新数据。
当主数据库发生故障时，可以使辅助数据库变成联机状态。
可以把每一个辅助数据库都当作“冷备用”数据库
●其它辅助技术
对数据库进行备份，当出现故障时，手动将数据还原到服务器，使得数据库重新联机，这也可以算作实现高可用性的一种技术手段。
复制（Replication）并不算是一个高可用性解决方案，只是它的功能可以实现高可用性。
复制通过“发布-订阅”模式，由主服务器向辅助服务器发布数据，使这些服务器间实现可用性。
SQLserver复制
定义及应用：
数据库间复制和分发数据和数据库对象，然后在数据库间进行同步操作以维持一致性。
使用复制，可以通过局域网和广域网、拨号连接、无线连接和Internet将数据分配到不同位置以及分配给远程或移动用户
sqlserver复制分成三类：
事务复制通常用于需要高吞吐量的服务器到服务器方案（包括：
提高可伸缩性和可用性、数据仓库和报告、集成多个站点的数据、集成异类数据以及减轻批处理的负荷）。
合并复制主要是为可能存在数据冲突的移动应用程序或分步式服务器应用程序设计的。
常见应用场景包括：
与移动用户交换数据、POS（消费者销售点）应用程序以及集成来自多个站点的数据。
快照复制用于为事务复制和合并复制提供初始数据集；
在适合数据完全刷新时也可以使用快照复制。
二、高可用的服务器配置：
如果只是需要复制方式，则搭建两台相同硬件配置和操作系统版本与补丁、相同数据库版本和补丁的服务器即可
如果需要AlwaysOn高可用方式，即出现故障后系统自动进行切换到备用服务器上，则需要3台（数据库主服务器、监听服务器、从服务器）相同硬件配置和操作系统版本与补丁、相同数据库版本和补丁的服务器
三、各种实现方式的对比
下表将SQLServer常用的高可用性解决方案进行综合对比。
对比项目
AlwaysOn
日志传送
实例级
数据库级
副本数量
无
最多8个
无限制
副本的可用性
不适用
可以
“备用模式”时可以访问
（只读访问）
对外统一IP地址
是
各自独立的IP地址
自动故障转移
不可以
故障转移单元
实例
一组数据库
四、以上各种类型的实现方式及优缺点
4.1日志传送
4.1.1实现方式https:
//technet.microsoft./zh-/library/ms190640（v=sql.110）.aspx
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
异步提交模式
异步提交时，主数据库将事务发送给辅助数据库后，无需等待而直接继续运行。
异步提交模式消除了主数据库的等待状态，因此这种提交模式对性能几乎没有影响。
但是辅助数据库可能遇到更新数据失败的情况（例如，因网络故障导致未接受主数据库的事务，或写入本地事务日志日志文件时遇到错误），而此时主数据库如果发生故障则可能造成数据丢失。
SQLServer20
升级会员 