SQL Server 2005数据库镜像(1)
来源：互联网 发布：java后端技术入门 编辑：程序博客网 时间：2024/04/20 05:10
内容列表 概述 数据库镜像是SQL Server 2005用于提高数据库可用性的新技术。数据库镜像将事务日志记录直接从一台服务器传输到另一台服务器，并且能够在出现故障时快速转移到备用服务器。可以编写客户端程序自动重定向连接信息，这样一旦出现故障转移就可以自动连接到备用服务器和数据库。 自动进行故障转移并且使数据损失最小化通常包括昂贵的硬件和复杂的软件。但是，数据库镜像可以在不丢失已提交数据的前提下进行快速故障转移，无须专门的硬件，并且易于配置和管理。 数据库镜像介绍 在数据库镜像中，一台SQL Server 2005实例连续不断的将数据库事务日志发送到另一台备用SQL Server实例的数据库副本中。发送方的数据库和服务器担当主角色，而接收方的数据库和服务器担当镜像角色。主服务器和镜像服务器必须是独立的SQL Server 2005实例。 在所有SQL Server数据库中，在对真正的数据页面进行修改之前，数据改变首先都记录在事务日志中。事务日志记录先被放置在内存中的数据库日志缓冲区中，然后尽快地输出到磁盘（或者被硬化）。在数据库镜像中，当主服务器将主数据库的日志缓冲区写入磁盘时，也同时将这些日志记录块发送到镜像实例。 当镜像服务器接收到日志记录块后，首先将日志记录放入镜像数据库的日志缓冲区，然后尽快地将它们硬化到磁盘。稍后镜像服务器会重新执行那些日志记录。由于镜像数据库重新应用了主数据库的事务日志记录，因此复制了发生在主数据库上的数据改变。 主服务器和镜像服务器将对方视为数据库镜像会话中的伙伴。数据库镜像会话包含了镜像伙伴服务器之间的关系。一台给定的伙伴服务器可以同时承担某个数据库的主角色和另一个数据库的镜像角色。 除了两台伙伴服务器（主服务器和镜像服务器），一个数据库会话中可能还包含第三台可选服务器，叫做见证服务器。见证服务器的角色就是启动自动故障转移。当数据库镜像用于高可用性时，如果主服务器突然失败了，如果镜像服务器通过见证服务器确认了主服务器的失败，那么它就自动承担主服务器角色，并且在几秒钟之内就可以向用户提供数据库服务。 数据库镜像中需要注意的一些重要事项： ◆主数据库必须为FULL还原模型。由于bulk-logged操作而导致的日志记录无法发送到镜像数据库。 注意： 要想获取更多与数据库镜像术语有关的信息，请参阅SQL Server 2005 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 [ 当safety设置为OFF，主服务器和镜像服务器之间的通信是异步的。主服务器不会等待镜像服务器已将事务记录硬化的确认信息。镜像服务器通过尽快记录事务日志的来试图保持与主服务器同步，但是如果主服务器突然失败同时强制镜像服务器提供服务，那么某些事务还是有可能丢失（参阅SQL Server Books中的'Forced Service'）。 Quorum和见证服务器 当safety设置为FULL，数据库镜像需要quorum才能提供数据库服务。quorum是在同步数据库镜像会话中要求的所有连接起来的服务器之间的最小关系。由于一个quorum至少需要两台服务器，因此当safety为FULL时，主服务器必须和其他某至少一台服务器组成quorum才能够提供数据库服务。 见证服务器帮助主服务器或者镜像服务器组成quorum。如果存在见证服务器，那么主数据库或者镜像数据库失败时，其余两台服务器还可以组成quorum。如果主服务器无法看到镜像服务器，那么它可以和见证服务器组成quorum，并保持提供数据库服务。类似地，如果镜像服务器和见证服务器看不到主服务器，那么这两台服务器可以组成quorum，镜像服务器担当新主服务器的角色。 见证服务器失败不被视为数据库镜像绘画中的单点失败。因为如果见证服务器失败了，那么主服务器和镜像服务器还可以组成quorum（更多信息请参阅SQL Server Books Online中的“Quorum in Database Mirroring Sessions”主题）。 高可用操作模式 高可用操作模式支持最大程度的数据库可用性，如果主数据库失败将自动转移到经销数据库。它要求将safety设置为FULL并且定义一台见证服务器作为数据库镜像会话中的一员。 高可用操作模式最适合于那些服务器之间具有高速且可靠的通信线路，同时要求在单一数据库上实现自动故障转移的场景。当safety为FULL时，主服务器必须短暂等待来自镜像服务器的回答，主服务器性能也因此受到镜像服务器能力的影响。由于单数据库失败将导致自动故障转移，因此如果有多数据库应用程序，那么就应该考虑其他操作模式（参阅该白皮书中实现数据库镜像部分介绍的“多数据库问题”） 高可用模式中数据库镜像是自监视的。如果主数据库突然不可用，或者主服务器停机，那么见证服务器和镜像服务器将组成quorum，然后镜像的SQL Server将进行自动故障转移。此时，竞相服务器实例将其角色转换为新主服务器并恢复数据库。由于镜像数据库已经重新执行了主数据库的事务日志并且其事务日志也与主数据库同步，因此镜像服务器可以快速提供数据库服务。 此外，SQL Server 2005可以在数据库恢复前就向用户提供数据库服务。SQL Server数据库恢复包括三个阶段：分析阶段、redo阶段、以及最后的undo阶段。在SQL Server 2005中，只要redo阶段完成，新恢复的数据库就可以让用户访问。因此如果数据库镜像故障转移发生，新恢复的主数据库只要完成了redo阶段就可以向用户提供服务了。因为镜像数据库自始至终都在重新执行事务日志记录，因此所有镜像服务器只须完成redo过程就可以了，通常几秒钟就可以完成。 高保护操作模式 高保护操作模式中事务安全性设置为FULL，但是镜像会话中没有见证服务器。主服务器必须组成quorum，可是没有见证服务器，因此只能和镜像服务器配合在一起。这种模式下由于没有见证服务器来担当平局决胜的角色，因此只能手动完成故障转移。行自动故障转移是不可能的，因为如果主服务器失败，镜像服务器没有见证服务器来组成quorum。 safety设置为FULL，如果主服务器突然间失去了和镜像服务器的quorum，那么镜像服务器必须使其数据库停止服务。不推荐使用高保护模式的数据库镜像配置，除非在高可用模式下必须临时移除见证服务器时，可以使用该模式作为一种临时过渡。 高性能操作模式 在高性能操作模式下，事务安全性设置为OFF，以异步方式传输日志记录。主服务器无须等待镜像服务器所有日志记录已被硬化的确认信息。镜像服务器尽自己最大可能保持与主服务器数据的一致，但不能保证在任何时刻来自主数据库的所有最新事务日志记录都能够被硬化到镜像数据库的事务日志中。 在高性能模式下，见证服务器不承担任何角色，也不需要quorum。因此高性能模式无法启用自动和手动的故障转移。唯一允许的故障转移方式就是forced service ，它同样也是一种手工操作： ALTER DATABASE forced service故障转移导致立刻恢复镜像数据库。如果某些主数据库的事务日志记录还没有被镜像服务器接收，那么恢复镜像数据库将导致潜在的数据丢失。高性能模式特别适合于远距离的数据传输（换句话说，用于远程站点的灾难恢复），或者对那些活动频繁且可以容忍某种程度数据丢失的数据库进行镜像。 数据库快照和数据库镜像 由于镜像数据库处于recovering状态，因此不可访问也不可读。在SQL Server 2005企业版和开发人员版中可以创建数据库快照来读取某个时点的镜像数据库。数据库快照提供了一个只读的数据库视图，开放数据给用户访问。这些数据与创建快照时刻的数据库数据相一致。 对数据库快照的访问如同访问一个其他的数据库。查询数据库快照时，从数据库快照文件中读出那些自快照创建后被修改的数据，从原始数据库中读出未修改的数据。最终效果就是读取了在创建快照时刻数据库当时的数据。（更多信息请参阅SQL Server Books Online中"Using Database Snapshots with Database Mirroring"主题。） 由于数据库快照确实增加了镜像服务器的负担，因此需要当心它们对数据库镜像性能可能造成的影响。由于只能镜像到一个数据库，因此如果需要将数据扩充到多个只读的报表服务器上，那么事务复制是更好的选择。（更新信息请阅读后面实现数据库镜像部分的“数据库镜像和复制”） 客户端重定向 在SQL Server 2005中，如果使用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.NET和SQL Native Client驱动程序中的数据库镜像支持的最大优点就是无须重新编写应用程序，或者在应用程序中编写特殊代码来处理数据库镜像的故障转移。 如果不使用ADO.NET或者SQL Native Client自动进行重定向，那么也可以使用其他技术使应用程序进行故障转移。例如，如果客户端连接到一台虚拟服务器，可以使用Network Load Balancing手动重定向一台服务器到另一台服务器的连接。还可以编程实现自己的重定向代码和连接重试逻辑。 但是，所有这些用于协调客户端重定向和数据库镜像的技术都有一些重要限制。数据库镜像只能工作在数据库级别，而不是服务器级别。如果应用程序查询一台服务器上的多个数据库，或者使用完全限定对象名称进行跨数据库查询，那么就需要多加小心了。如果多个数据库位于一台服务器并且都配置了和备用服务器的镜像，就有可能出现其中一个数据库故障转移到备用服务器而其他数据库依然在原始服务器的情况。如果是那样的话，可能就要求每个数据库查询都使用一个单独的连接，这样将无法进行跨数据库查询，因为在镜像服务器上只有一个数据库是主数据库，其余都是镜像数据库。<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 728x15, 创建于 08-4-23MSDN */google_ad_slot = "3624277373";google_ad_width = 728;google_ad_height = 15;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>
数据库镜像介绍
数据库镜像动态
数据库镜像可用性场景
实现数据库镜像
数据库镜像和高可用性技术
结论
概述
◆初始化镜像数据库必须首先使用NORECOVERY还原主数据库，然后再按顺序还原著数据库事务日志备份。
◆镜像数据库和主数据库名称必须一致。
◆由于镜像数据库处于recovering状态，因此不能直接访问。通过在镜像数据库上创建数据库快照可以间接读取某一个时刻点的镜像数据库。（参阅该白皮书后面“数据库镜像和数据库快照”部分）
