SQLserver高可用方案设计

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

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 实现方式https://technet.microsoft./zh-/library/ms190640(v=sql.110).aspx

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 仅允许单向的同步提交(从一个主副本单向同步到多个辅助副本)。

相关文档
最新文档