设为首页 收藏本站
查看: 449|回复: 0

[经验分享] SQL SERVER 2005数据库镜像

[复制链接]

尚未签到

发表于 2016-11-2 01:47:22 | 显示全部楼层 |阅读模式
内容列表  

  

  

概述 1  

数据库镜像介绍.. 1  

数据库镜像动态.. 5  

数据库镜像可用性场景.. 15  

实现数据库镜像.. 32  

数据库镜像和高可用性技术.. 36  

结论 39  

  

  



  

概述  

数据库镜像是SQL SERVER2005用于提高数据库可用性的新技术。数据库镜像将事务日志记录直接从一台服务器传输到另一台服务器,并且能够在出现故障时快速转移到备用服务器。可以编写客户端程序自动重定向连接信息,这样一旦出现故障转移就可以自动连接到备用服务器和数据库。   

自动进行故障转移并且使数据损失最小化通常包括昂贵的硬件和复杂的软件。但是,数据库镜像可以在不丢失已提交数据的前提下进行快速故障转移,无须专门的硬件,并且易于配置和管理。  

数据库镜像介绍  

在数据库镜像中,一台SQLServer2005实例连续不断的将数据库事务日志发送到另一台备用SQL Server实例的数据库副本中。发送方的数据库和服务器担当角色,而接收方的数据库和服务器担当镜像角色。主服务器和镜像服务器必须是独立的SQLServer2005实例。  

在所有SQLServer数据库中,在对真正的数据页面进行修改之前,数据改变首先都记录在事务日志中。事务日志记录先被放置在内存中的数据库日志缓冲区中,然后尽快地输出到磁盘(或者被硬化)。在数据库镜像中,当主服务器将主数据库的日志缓冲区写入磁盘时,也同时将这些日志记录块发送到镜像实例。   

当镜像服务器接收到日志记录块后,首先将日志记录放入镜像数据库的日志缓冲区,然后尽快地将它们硬化到磁盘。稍后镜像服务器会重新执行那些日志记录。由于镜像数据库重新应用了主数据库的事务日志记录,因此复制了发生在主数据库上的数据改变。   

主服务器和镜像服务器将对方视为数据库镜像会话中伙伴。数据库镜像会话包含了镜像伙伴服务器之间的关系。一台给定的伙伴服务器可以同时承担某个数据库的主角色和另一个数据库的镜像角色。   

除了两台伙伴服务器(主服务器和镜像服务器),一个数据库会话中可能还包含第三台可选服务器,叫做见证服务器。见证服务器的角色就是启动自动故障转移。当数据库镜像用于高可用性时,如果主服务器突然失败了,如果镜像服务器通过见证服务器确认了主服务器的失败,那么它就自动承担主服务器角色,并且在几秒钟之内就可以向用户提供数据库服务。  

数据库镜像中需要注意的一些重要事项:  

· 主数据库必须为FULL还原模型。由于bulk-logged操作而导致的日志记录无法发送到镜像数据库。  

· 初始化镜像数据库必须首先使用NORECOVERY还原主数据库,然后再按顺序还原著数据库事务日志备份。
· 镜像数据库和主数据库名称必须一致。
· 由于镜像数据库处于recovering状态,因此不能直接访问。通过在镜像数据库上创建数据库快照可以间接读取某一个时刻点的镜像数据库。(参阅该白皮书后面“数据库镜像和数据库快照”部分)   

注意: 要想获取更多与数据库镜像术语有关的信息,请参阅SQLServer2005 Books Online中关于“Overview of Database Mirroring”。
操作模式  

数据库镜像会话有三种可能的操作模式。根据事务安全性的设置以及镜像会话中是否需要见证服务器来决定精确的操作模式。   

1.数据库镜像操作模式  

操作模式  

事务安全性  

传输机制  

需要Quorum

见证服务器  

故障转移类型  

高可用  

FULL
同步  

Y
Y
自动或者手动  

高保护  

FULL
同步  

Y
N
只能手动  

高性能  

OFF
异步  

N
N/A
只能forced
  

如果safety设置为FULL,那么通过同步方式传输数据,并且需要一台镜像服务器才能提供数据库服务。quorum投票表决要求至少两台服务器的参与才能够决定两个伙伴服务器各自承担什么角色,主角色还是镜像角色。   

为了更深入研究这三种操作模式,首先来更进一步研究一下事务安全性和quorum的角色。  

事务安全性
If 事务安全性(或者'safety')设置为FULL,那么主服务器和镜像服务器工作在同步传输模式下。当主服务器硬化其主数据库日志记录到磁盘时,也同时将日志发送到镜像服务器。然后主服务器等待镜像服务器的回答。镜像服务器将那些相同的日志记录硬化到镜像日志所在磁盘后,对主服务器进行答复。当safety设置为OFF时,主服务器不会等待来自服务器的确认,因此主数据库和镜像数据库可能不是完全同步的(也就是,镜像可能滞后于主数据库)。  

同步传输方式保证镜像数据库事务日志中所有事务与主数据库事务日志中的事务同步,因此可视为事务是安全传输的。要将safety设置为FULL,使用   

ALTER DATABASE [<dbname>] SET SAFETY FULL;
safety设置为OFF,主服务器和镜像服务器之间的通信是异步的。主服务器不会等待镜像服务器已将事务记录硬化的确认信息。镜像服务器通过尽快记录事务日志的来试图保持与主服务器同步,但是如果主服务器突然失败同时强制镜像服务器提供服务,那么某些事务还是有可能丢失(参阅SQLServer Books中的'Forced Service')。  

Quorum和见证服务器  

safety设置为FULL,数据库镜像需要quorum才能提供数据库服务。quorum是在同步数据库镜像会话中要求的所有连接起来的服务器之间的最小关系。由于一个quorum至少需要两台服务器,因此当safetyFULL时,主服务器必须和其他某至少一台服务器组成quorum才能够提供数据库服务。  

见证服务器帮助主服务器或者镜像服务器组成quorum。如果存在见证服务器,那么主数据库或者镜像数据库失败时,其余两台服务器还可以组成quorum。如果主服务器无法看到镜像服务器,那么它可以和见证服务器组成quorum,并保持提供数据库服务。类似地,如果镜像服务器和见证服务器看不到主服务器,那么这两台服务器可以组成quorum,镜像服务器担当新主服务器的角色。   

见证服务器失败不被视为数据库镜像绘画中的单点失败。因为如果见证服务器失败了,那么主服务器和镜像服务器还可以组成quorum(更多信息请参阅SQLServer Books Online中的“Quorum in Database Mirroring Sessions”主题)。  

高可用操作模式  

高可用操作模式支持最大程度的数据库可用性,如果主数据库失败将自动转移到经销数据库。它要求将safety设置为FULL并且定义一台见证服务器作为数据库镜像会话中的一员。   

高可用操作模式最适合于那些服务器之间具有高速且可靠的通信线路,同时要求在单一数据库上实现自动故障转移的场景。当safetyFULL时,主服务器必须短暂等待来自镜像服务器的回答,主服务器性能也因此受到镜像服务器能力的影响。由于单数据库失败将导致自动故障转移,因此如果有多数据库应用程序,那么就应该考虑其他操作模式(参阅该白皮书中实现数据库镜像部分介绍的“多数据库问题”)  

高可用模式中数据库镜像是自监视的。如果主数据库突然不可用,或者主服务器停机,那么见证服务器和镜像服务器将组成quorum,然后镜像的SQLServer将进行自动故障转移。此时,竞相服务器实例将其角色转换为新主服务器并恢复数据库。由于镜像数据库已经重新执行了主数据库的事务日志并且其事务日志也与主数据库同步,因此镜像服务器可以快速提供数据库服务。  

此外,SQLServer2005可以在数据库恢复前就向用户提供数据库服务。SQLServer数据库恢复包括三个阶段:分析阶段、redo阶段、以及最后的undo阶段。在SQLServer2005中,只要redo阶段完成,新恢复的数据库就可以让用户访问。因此如果数据库镜像故障转移发生,新恢复的主数据库只要完成了redo阶段就可以向用户提供服务了。因为镜像数据库自始至终都在重新执行事务日志记录,因此所有镜像服务器只须完成redo过程就可以了,通常几秒钟就可以完成。   

高保护操作模式  

高保护操作模式中事务安全性设置为FULL,但是镜像会话中没有见证服务器。主服务器必须组成quorum,可是没有见证服务器,因此只能和镜像服务器配合在一起。这种模式下由于没有见证服务器来担当平局决胜的角色,因此只能手动完成故障转移。行自动故障转移是不可能的,因为如果主服务器失败,镜像服务器没有见证服务器来组成quorum  

safety设置为FULL,如果主服务器突然间失去了和镜像服务器的quorum,那么镜像服务器必须使其数据库停止服务。不推荐使用高保护模式的数据库镜像配置,除非在高可用模式下必须临时移除见证服务器时,可以使用该模式作为一种临时过渡。  

高性能操作模式  

在高性能操作模式下,事务安全性设置为OFF,以异步方式传输日志记录。主服务器无须等待镜像服务器所有日志记录已被硬化的确认信息。镜像服务器尽自己最大可能保持与主服务器数据的一致,但不能保证在任何时刻来自主数据库的所有最新事务日志记录都能够被硬化到镜像数据库的事务日志中。   

在高性能模式下,见证服务器不承担任何角色,也不需要quorum。因此高性能模式无法启用自动和手动的故障转移。唯一允许的故障转移方式就是forced service ,它同样也是一种手工操作:  

ALTER DATABASE <dbname> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
forced service故障转移导致立刻恢复镜像数据库。如果某些主数据库的事务日志记录还没有被镜像服务器接收,那么恢复镜像数据库将导致潜在的数据丢失。高性能模式特别适合于远距离的数据传输(换句话说,用于远程站点的灾难恢复),或者对那些活动频繁且可以容忍某种程度数据丢失的数据库进行镜像。   

数据库快照和数据库镜像  

由于镜像数据库处于recovering状态,因此不可访问也不可读。在SQLServer2005企业版和开发人员版中可以创建数据库快照来读取某个时点的镜像数据库。数据库快照提供了一个只读的数据库视图,开放数据给用户访问。这些数据与创建快照时刻的数据库数据相一致。   

对数据库快照的访问如同访问一个其他的数据库。查询数据库快照时,从数据库快照文件中读出那些自快照创建后被修改的数据,从原始数据库中读出未修改的数据。最终效果就是读取了在创建快照时刻数据库当时的数据。(更多信息请参阅SQLServer Books Online"Using Database Snapshots with Database Mirroring"主题。)  

由于数据库快照确实增加了镜像服务器的负担,因此需要当心它们对数据库镜像性能可能造成的影响。由于只能镜像到一个数据库,因此如果需要将数据扩充到多个只读的报表服务器上,那么事务复制是更好的选择。(更新信息请阅读后面实现数据库镜像部分的“数据库镜像和复制”)  

客户端重定向  

SQLServer2005中,如果使用ADO.NET或者SQL Native Client连接配置了镜像的数据库,那么应用程序就可以利用驱动程序的能力在发生数据库镜像故障转移时自动重定向数据库连接。必须在连接字符串中指定原始主服务器和数据库名称,以及可选的故障转移伙伴服务器名称。   

连接字符串的写法有许多种,以下只给出一个例子,指定server A作为主服务器,server B作为镜像服务器,AdventureWorks作为数据库名称:  

"Data Source=A;Failover Partner=B;Initial Catalog=AdventureWorks;Integrated Security=True;"
如果连接到原始主服务器失败,那么就使用连接字符串中的failover partner作为备用服务器名称。如果连接到原始主服务器成功,那么就不使用连接字符串中的failover partner名称,但是会从主服务器上查询其故障转移伙伴的名称并将结果存放在客户端缓存中。  

假设客户端成功连接到主服务器,然后一个数据库镜像故障转移发生(自动地、手动的、forced)。当下一次应用程序尝试使用连接时,ADO.NET或者SQL Native Client驱动程序将会检测到与旧主服务器的连接已经失败,然后自动重新连接由failover partner名称指定的新主服务器。如果连接成功并且新的镜像服务器存在,那么驱动程序从新主服务器处获取新的故障转移伙伴名称并将其存放在客户端缓存中。如果无法连接到备用服务器,那么驱动程序将交替尝试与每个服务器的连接直道连接超时。  

使用内置在ADO.NETSQL Native Client驱动程序中的数据库镜像支持的最大优点就是无须重新编写应用程序,或者在应用程序中编写特殊代码来处理数据库镜像的故障转移。   

如果不使用ADO.NET或者SQL Native Client自动进行重定向,那么也可以使用其他技术使应用程序进行故障转移。例如,如果客户端连接到一台虚拟服务器,可以使用Network Load Balancing手动重定向一台服务器到另一台服务器的连接。还可以编程实现自己的重定向代码和连接重试逻辑。  

但是,所有这些用于协调客户端重定向和数据库镜像的技术都有一些重要限制。数据库镜像只能工作在数据库级别,而不是服务器级别。如果应用程序查询一台服务器上的多个数据库,或者使用完全限定对象名称进行跨数据库查询,那么就需要多加小心了。如果多个数据库位于一台服务器并且都配置了和备用服务器的镜像,就有可能出现其中一个数据库故障转移到备用服务器而其他数据库依然在原始服务器的情况。如果是那样的话,可能就要求每个数据库查询都使用一个单独的连接,这样将无法进行跨数据库查询,因为在镜像服务器上只有一个数据库是主数据库,其余都是镜像数据库。  

数据库镜像与SQL SERVER 2005版本  

下表显示各种版本的SQL SERVER2005支持的数据库镜像功能
2数据库镜像SQL SERVER 2005版本  

[table][tr][td=1,1,126]数据库
镜像功能  

[/td][td=1,1,102]企业版  

[/td][td=1,1,101]开发人员版  

[/td][td=1,1,98]标准版  

[/td][td=1,1,104]工作组版  

[/td][td=1,1,78]SQL
Express
[/td][/tr][tr][td=1,1,126]镜像伙伴  

[/td][td=1,1,102]√
[/td][td=1,1,101]√
[/td][td=1,1,98]√
[/td][td=1,1,104]  

[/td][td=1,1,78]  

[/td][/tr][tr][td=1,1,126]见证服务器  

[/td][td=1,1,102]√
[/td][td=1,1,101]√
[/td][td=1,1,98]√
[/td][td=1,1,104]√
[/td][td=1,1,78]√
[/td][/tr][tr][td=1,1,126]Safety = FULL
[/td][td]padding-right: 5.4pt; border-top: #d4d0c8; padding-left: 5.4pt; padding-bottom: 0cm; border-left: #d4d0c8; width: 76.15pt; padding-top: 0cm; background-c

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-294274-1-1.html 上篇帖子: [转载]大豆男生的文章:SQL Server 2000/2005 分页SQL — 单条SQL语句 下篇帖子: SQL SERVER T-SQL 游标的初步研究
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表