有一个法则叫“九法则”,人和高可用性解决方案的终极目标是五九法则,即99.999%,这样每年只有比5分钟多一点的死机时间。目前灾难恢复一词已经不再受人们欢迎。人们更喜欢使用的词是业务连续性business continuity。其思想是希望防止系统变得不可用,如果服务确实失败,使其对环境的影响最小。这篇文章介绍的高可用性解决方案可以帮助在停机事件中维护业务连续性。
故障转移集群
SQL Server集群基于Windows服务集群服务,集群的工作方式是在两个或多个服务器(称为节点)作为一个单独的虚拟服务器为终端用户服务。
如果要开始集群的话,需要两台服务器,还需要一个共享的存储设备。串行联接SCSI,光纤通道和iSCSI是许多集群存储设备的常用接口。如果选择在集群解决方案中使用iSCSI,那么需要确保对于Windows网络适配器相分离的iSCSI联接采用一个专用的网络接口卡。如果使用Windows Server 2008,确保使用一个兼容的存储设备。在这个设备上将至少创建两个卷。一个卷将作见证磁盘,保存集群配置信息。而对于应用程序,将需要一个或多个数据卷。此外,要使集群起作用,需要为它定义一个虚拟服务器。该虚拟服务器在客户端和终端应用程序看来是一个服务器。它有一个唯一名称和IP地址,可以将SQL Server安装在这个虚拟服务器上。
主动/被动集群:在主动/被动集群中,对于单个应用程序,有一个节点被指派为主节点,所有进入该集群虚拟服务器的请求都被导向至主节点。辅助节点时故障转移节点,只有在主节点不可用且其中没有检测信号时,他们被变成主动的。当这种情况发生时,一个辅助节点会开始接收集群的工作,使得应用程序继续运行而几乎没有明显的中段。
主动/主动集群:主动/主动集群是这样一幅场景,其中运行着许多个集群感知的应用程序,而且每个应用程序都有一个不同的节点被配置为该应用程序的主节点。这主要是受数据库和其他应用程序服务的工作方式的限制。例如,如果只关注SQL Server,那么每次只有一个服务器可以写主动事务日志。由于其他节点无法写入同一事物日志,他们还能做什么呢?可以配置另一个虚拟服务器,把一个现有的备用节点配置为该虚拟服务器的主节点,然后在该服务器上安装另一个SQL Server实例。假如,假定您有两个服务器,节点A和节点B,节点A是集群服务器1的主节点,节点B是它的辅助节点。您决定使用这两个服务器创建一个叫做集群服务器2的辅助虚拟服务器。只有在这个时候节点B才是主节点,而节点A是辅助节点。要想使主动/主动集群发挥作用,那么如果两个虚拟服务器都出现故障,备用服务器必须能够处理他们两个加起来的工作量。因此,如果服务器A死机了,服务器B就必须能够响应针对两个虚拟服务器的客户端请求。
日志传送
日志传送时用于维护业务连续性的另一种方法。和故障转移集群不一样,日志传送时基于每台数据库进行管理的。它允许指定一个或多个服务器来存储某数据库的辅助副本。其实现方法是 先常规备份事务日志,然后把这些备份还原到一个辅助服务器上。
准备日志传送:首选确定主服务器和备用服务器之间存在可靠的网络连接。其次,确保数据库使用了完整恢复模式;还需要确保备用服务器上不存在目标数据库。
使用SQL Server Management Studio配置日志传送:右击该数据库,选择任务-传送事务日志命令。在事务日志传送页面上,可以配置备份数据库,指定辅助服务器和监视服务器所需的选项。首先,必须把这个数据库启用为日志传送的主服务器。单击“备份设置”将会出现一个新的窗口,允许指定备份操作的位置和频率。如果有多个辅助服务器,而且希望在其中一个辅助服务器升级为主服务器之后继续使用备用辅助服务器,那么可以考虑把备份文件夹放在所有服务器都可以访问的共享位置上,但要确保当主服务器上发生一般的服务故障时,该位置不会受到影响。一旦配置了备份作业设置,就可以配置一个或多个辅助服务器。可以将辅助服务器配置为热备用服务器,使之处于NO RECOVERY状态,直至出现故障转移,或者也可以把它们配置为数据库的一个只读副本。
要配置一个新的辅助服务器,可以在事务日志传送页面上单击添加按钮。如果用于故障转移,那么辅助服务器的名称应当和主服务器一致,这样可以避免重新配置客户端应用程序。然后还可以配置数据库初次还原的选项。在复制文件选项卡中,可以配置有关文件复制任务的选项。可以创建一个新的作业,把备份操作创建的文件复制到辅助服务器上的目标文件夹中。在还原事务日志选项卡中可以配置还原操作,包括恢复模式,频率和使用备用数据库的任务。还可以配置延迟还原操作以保证备份及复制操作有机会完成,并制定在多长时间内如果没有执行还原就发出警报,还可以为还原任务配置适当的计划。
另外,也可以配置服务器来监视日志传送操作,但并不是必须这么做。该服务器应该是一个不直接参与日志传送过程的SQL Server。要添加监视服务器,可以在事务日志传送页面上选择“使用监视服务器实例”,然后单击设置按钮添加和配置新的服务器。在配置了日志传送监视器之后,也可以使用它来查看该服务器监视的所有日志传送数据库的报表。为此,可以在对象资源管理器中右击服务器名称,选择报表-标准报表-事务日志传送状态命令。
一旦配置了日志传送选项,就可以把它们应用到数据库,如果所有的配置都正确,备份就会立刻开始。
使用Transact-SQL配置日志传送:直接上实例代码
-- Execute the following statements at the Primary to configure Log Shipping
-- for the database [AUGHTEIGHT].[AdventureWorks2008],
-- The script needs to be run at the Primary in the context of the [msdb] database.
--------------------------------------------------------------
Adding the Log Shipping configuration
-- ****** Begin: Script to be run at Primary: [AUGHTEIGHT] ******
DECLARE @LS_BackupJobId AS uniqueidentifier
DECLARE @LS_PrimaryId AS uniqueidentifier
DECLARE @SP_Add_RetCode As int
EXEC @SP_Add_RetCode = master.dbo.sp_add_log_shipping_primary_database
@database = N'AdventureWorks2008'
,@backup_directory = N'\\AughtEight\SQLLogs'
,@backup_share = N'\\AughtEight\SQLLogs'
,@backup_job_name = N'LSBackup_AdventureWorks2008'
,@backup_retention_period = 4320
,@backup_compression = 1
,@monitor_server = N'AUGHTEIGHT\HOTH'
,@monitor_server_security_mode = 1
,@backup_threshold = 60
,@threshold_alert_enabled = 1
,@history_retention_period = 5760
,@backup_job_id = @LS_BackupJobId OUTPUT
,@primary_id = @LS_PrimaryId OUTPUT
,@overwrite = 1
IF (@@ERROR = 0 AND @SP_Add_RetCode = 0)
BEGIN
DECLARE @LS_BackUpScheduleUID As uniqueidentifier
DECLARE @LS_BackUpScheduleID AS int
EXEC msdb.dbo.sp_add_schedule
@schedule_name =N'LSBackupSchedule_AUGHTEIGHT1'
,@enabled = 1
,@freq_type = 4
,@freq_interval = 1
,@freq_subday_type = 4
,@freq_subday_interval = 15
,@freq_recurrence_factor = 0
,@active_start_date = 20081111
,@active_end_date = 99991231
,@active_start_time = 0
,@active_end_time = 235900
,@schedule_uid = @LS_BackUpScheduleUID OUTPUT
,@schedule_id = @LS_BackUpScheduleID OUTPUT
EXEC msdb.dbo.sp_attach_schedule
@job_id = @LS_BackupJobId
,@schedule_id = @LS_BackUpScheduleID
EXEC msdb.dbo.sp_update_job
@job_id = @LS_BackupJobId
,@enabled = 1
END
EXEC master.dbo.sp_add_log_shipping_primary_secondary
@primary_database = N'AdventureWorks2008'
,@secondary_server = N'AUGHTEIGHT\DAGOBAH'
,@secondary_database = N'AdventureWorks2008'
,@overwrite = 1
-- ****** End: Script to be run at Primary: [AUGHTEIGHT] ******
-- Execute the following statements at the Secondary to configure Log Shipping
-- for the database [AUGHTEIGHT\DAGOBAH].[AdventureWorks2008],
-- the script needs to be run at the Secondary in the context of the
-- [msdb] database.
----------------------------------------------------------------------------
-- Adding the Log Shipping configuration
-- ****** Begin: Script to be run at Secondary: [AUGHTEIGHT\DAGOBAH] ******
DECLARE @LS_Secondary__CopyJobId AS uniqueidentifier
DECLARE @LS_Secondary__RestoreJobId AS uniqueidentifier
DECLARE @LS_Secondary__SecondaryId AS uniqueidentifier
DECLARE @LS_Add_RetCode As int
EXEC @LS_Add_RetCode = master.dbo.sp_add_log_shipping_secondary_primary
@primary_server = N'AUGHTEIGHT'
,@primary_database = N'AdventureWorks2008'
,@backup_source_directory = N'\\AughtEight\SQLLogs'
,@backup_destination_directory = N'C:\CopiedLogs'
,@copy_job_name = N'LSCopy_AUGHTEIGHT_AdventureWorks2008'
,@restore_job_name = N'LSRestore_AUGHTEIGHT_AdventureWorks2008'
,@file_retention_period = 4320
,@monitor_server = N'AUGHTEIGHT\HOTH'
,@monitor_server_security_mode = 1
,@overwrite = 1
,@copy_job_id = @LS_Secondary__CopyJobId OUTPUT
,@restore_job_id = @LS_Secondary__RestoreJobId OUTPUT
,@secondary_id = @LS_Secondary__SecondaryId OUTPUT
IF (@@ERROR = 0 AND @LS_Add_RetCode = 0)
BEGIN
DECLARE @LS_SecondaryCopyJobScheduleUID As uniqueidentifier
DECLARE @LS_SecondaryCopyJobScheduleID AS int
EXEC msdb.dbo.sp_add_schedule
@schedule_name =N'DefaultCopyJobSchedule'
,@enabled = 1
,@freq_type = 4
,@freq_interval = 1
,@freq_subday_type = 4
,@freq_subday_interval = 15
,@freq_recurrence_factor = 0
,@active_start_date = 20081111
,@active_end_date = 99991231
,@active_start_time = 0
,@active_end_time = 235900
,@schedule_uid = @LS_SecondaryCopyJobScheduleUID OUTPUT
,@schedule_id = @LS_SecondaryCopyJobScheduleID OUTPUT
EXEC msdb.dbo.sp_attach_schedule
@job_id = @LS_Secondary__CopyJobId
,@schedule_id = @LS_SecondaryCopyJobScheduleID
DECLARE @LS_SecondaryRestoreJobScheduleUID As uniqueidentifier
DECLARE @LS_SecondaryRestoreJobScheduleID AS int
EXEC msdb.dbo.sp_add_schedule
@schedule_name =N'DefaultRestoreJobSchedule'
,@enabled = 1
,@freq_type = 4
,@freq_interval = 1
,@freq_subday_type = 4
,@freq_subday_interval = 15
,@freq_recurrence_factor = 0
,@active_start_date = 20081111
,@active_end_date = 99991231
,@active_start_time = 0
,@active_end_time = 235900
,@schedule_uid = @LS_SecondaryRestoreJobScheduleUID OUTPUT
,@schedule_id = @LS_SecondaryRestoreJobScheduleID OUTPUT
EXEC msdb.dbo.sp_attach_schedule
@job_id = @LS_Secondary__RestoreJobId
,@schedule_id = @LS_SecondaryRestoreJobScheduleID
END
DECLARE @LS_Add_RetCode2 As int
IF (@@ERROR = 0 AND @LS_Add_RetCode = 0)
BEGIN
EXEC @LS_Add_RetCode2 = master.dbo.sp_add_log_shipping_secondary_database
@secondary_database = N'AdventureWorks2008'
,@primary_server = N'AUGHTEIGHT'
,@primary_database = N'AdventureWorks2008'
,@restore_delay = 0
,@restore_mode = 1
,@disconnect_users = 1
,@restore_threshold = 45
,@threshold_alert_enabled = 1
,@history_retention_period = 5760
,@overwrite = 1
END
IF (@@error = 0 AND @LS_Add_RetCode = 0)
BEGIN
EXEC msdb.dbo.sp_update_job
@job_id = @LS_Secondary__CopyJobId
,@enabled = 1
EXEC msdb.dbo.sp_update_job
@job_id = @LS_Secondary__RestoreJobId
,@enabled = 1
END
-- ****** End: Script to be run at Secondary: [AUGHTEIGHT\DAGOBAH] ******
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93.
- 94.
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101.
- 102.
- 103.
- 104.
- 105.
- 106.
- 107.
- 108.
- 109.
- 110.
- 111.
- 112.
- 113.
- 114.
- 115.
- 116.
- 117.
- 118.
- 119.
- 120.
- 121.
- 122.
- 123.
- 124.
- 125.
- 126.
- 127.
- 128.
- 129.
- 130.
- 131.
- 132.
- 133.
- 134.
- 135.
- 136.
- 137.
- 138.
- 139.
- 140.
- 141.
- 142.
- 143.
- 144.
- 145.
- 146.
- 147.
- 148.
- 149.
- 150.
- 151.
- 152.
- 153.
- 154.
- 155.
- 156.
- 157.
- 158.
- 159.
- 160.
- 161.
- 162.
- 163.
- 164.
- 165.
- 166.
- 167.
- 168.
- 169.
- 170.
- 171.
- 172.
- 173.
- 174.
- 175.
- 176.
- 177.
- 178.
- 179.
- 180.
- 181.
- 182.
- 183.
- 184.
- 185.
- 186.
- 187.
- 188.
- 189.
- 190.
- 191.
- 192.
- 193.
- 194.
- 195.
- 196.
- 197.
- 198.
- 199.
- 200.
- 201.
- 202.
- 203.
- 204.
- 205.
- 206.
- 207.
- 208.
- 209.
- 210.
- 211.
- 212.
- 213.
- 214.
- 215.
- 216.
- 217.
- 218.
- 219.
- 220.
- 221.
- 222.
- 223.
- 224.
- 225.
- 226.
- 227.
- 228.
- 229.
- 230.
- 231.
- 232.
- 233.
- 234.
- 235.
- 236.
- 237.
- 238.
- 239.
- 240.
- 241.
- 242.
- 243.
- 244.
- 245.
- 246.
- 247.
- 248.
- 249.
- 250.
- 251.
- 252.
- 253.
- 254.
- 255.
- 256.
- 257.
- 258.
- 259.
- 260.
- 261.
- 262.
- 263.
- 264.
- 265.
- 266.
- 267.
- 268.
- 269.
- 270.
- 271.
- 272.
- 273.
- 274.
- 275.
- 276.
- 277.
- 278.
- 279.
- 280.
- 281.
- 282.
- 283.
- 284.
- 285.
配置故障转移:要配置主服务器和辅助服务器之间的故障转移,可以使用下列步骤:如果备份共享中有任何为复制的备份文件,需要把它们复制到每个辅助服务器上的复制目标;把所有剩下的事务日志按顺序应用到每个辅助数据库上;如有可能,在主数据库上执行活动事务日志的备份,复制该备份,然后将其应用到每个备用数据库中;如果主服务器仍然可以操作,那么故障转移完成时可以将主数据库配置为新的辅助数据库,使用NO RECOVERY选项在主数据库上备份事务日志有助于完成这项工作;把数据库设置为恢复模式,选择一个辅助服务器来主流新的主数据库。
如果有额外的辅助服务器,则可以将新恢复的数据库配置为额外辅助数据库的主数据库,并使原来的主数据库成为一个新的辅助数据库,执行下列步骤来进行角色转换:禁用原主服务器上的备份作业;禁用原辅助服务器上的复制和还原作业;对新的主数据库的备份使用为原主数据库创建的共享;添加原数据库作为一个辅助数据库;在原数据库的辅助数据库选项中,指定该数据库已经初始化,这样就没有必要进行完整还原。
由于日志传送是基于每个数据库配置的,因此可能需要执行一些额外的任务以确保用户能够一致地访问该数据库,即便发生了故障转移。首先,客户端使用的应用程序必须知道这一更改。这可能要求手动配置应用程序使用新的主服务器或将旧的服务器名称重新指派为新服务器的别名。另外,要确保应用程序对数据库的一致访问,将需要确保已经迁移了该数据库所有关联的元数据,包括SQL Server登录名、作业和报警等。由于日志传送有一些限制,创建只读备用服务器很好,但是它对于故障转移来说只是一个一般的解决方案。
数据库镜像
数据库镜像与日志传送非常相似,即事务日志记录是从源数据库发送到目标数据库。不过,和基于文件复制的事务日志不同的是,单独的日志记录是基于事务发送的。尽管数据库镜像也是一个数据库级别的冗余解决方案,但它依赖于服务间不断通信来维护事务完整性。数据库镜像还提供了一个在配置了另外一个见证服务器时自动并且几乎瞬时故障转移的额外好处。数据库镜像的配置是通过在驻留主体数据库的服务器和主流镜像数据库的服务器之间建立合作关系完成的。两者之间的通信通过使用SQL Server端点建立和维护,而不是使用文件系统作为维护两个服务器之间的一致性方法。日志传送和数据库镜像的另外一个主要区别是,数据库镜像限制每个数据库智能有一个主题服务器和一个镜像服务器。
数据库镜像配置中的3个服务器角色如下:主体服务器、镜像服务器、见证服务器(可选)。在使用数据库镜像时,客户端请求无法直接访问镜像数据库,因为它一直处于恢复事务日志记录的状态下。但是,可以通过创建镜像数据库的数据库快照配置间接访问。还要注意,数据库镜像不能与启用了FILESTREAM存储的数据库一起使用。
客户端重定向:数据库镜像的优势之一是如果主体数据库出现故障,客户端可以被自动重定向到镜像服务器。然而,自动重定向不是基于服务器的功能。通过添加Failover Partner属性,可以将客户端的联接字符串配置为与镜像的数据库一起工作,如果联接Server属性标识的服务器失败,那么它会尝试连接由Failover Partner属性标识的数据库,反之亦然,如果联接故障转移伙伴不可用,就会尝试连接原服务器
Server=AughtEight;Failover Partner=Dagobah;Database=AdventureWorks2008
数据库镜像模式:数据库可以被配置为使用高性能模式、不支持自动故障转移的高安全性模式以及支持故障转移的高安全性模式。高性能模式使用异步处理,当主体服务器把事务日志记录发送到镜像服务器之后,会立刻向客户端应用程序发送一个事务成功的确认,但是不会等待镜像服务器确认接收日志记录。在高性能模式下,不存在自动故障转移也不需要见证服务器,因为主题服务器出现故障时仍然会要求强制执行镜像服务器上的数据库服务。一旦原来的主主体服务器恢复服务,它会配置自身为镜像服务器,但是镜像会话仍然会处于SUSPENDED状态,除非管理员明确要求恢复。不支持自动故障转移的高安全性模式中,在镜像服务器确认收到了相应的事务日志记录之前,主体服务器不会给客户端发送事务成功的确认消息。该模式中没有自动故障转移,也没有见证服务器,主体数据库出现故障后要求手动强制见证服务器上的服务器提升其主体。在镜像服务器出现故障的情况下,客户端仍然可以使用主体服务器,但是镜像会话会处于断开连接的状态。支持自动故障转移的高安全性模式中,见证服务器用于提供自动故障转移。见证服务器不直接参与镜像过程,而是作为两个服务器之间的监督员,只要三个参与此模式的服务器中有两个能够保证连接性,那么数据库就会对客户端请求可用。当两个服务器就镜像会话的状态取得一致时,这就被叫做仲裁,如果镜像或主体服务器丢失了仲裁,镜像配置也会相应的改变。
使用SQL Server Management Studio配置数据库镜像:打开数据库属性-镜像页面,或者从任务-镜像菜单打开这个页面,单击配置安全性按钮启动向导,要求为主体、镜像和见证服务器端点提供联接选项。单击下一步进入下一页面,向导会询问是否要配置一个见证服务器;向导的下一页面要求标识在这个向导里要配置的服务器,您需要检查所有参与的服务器,包括见证服务器(如果使用了的话)。进入下一页面,配置主体服务器的选项;接下来需要为镜像服务器配置同样的信息,注意,挡在每个服务器上创建端点时,必须有在端点上创建和配置安全性的适当权限;如果配置了见证服务器,下一页面要求为见证服务器提供服务器名称和端点配置,其中需要注意一点,即如果同一物理服务器上有多个角色,那么端口号必须butong.youyu数据库镜像起作用的条件中并不要求所有的及其都采用相同的配置,甚至不要求他们是同一个域中的成员,所以向导允许为每个服务器指定账户信息。输入这些信息后,就可以通过向导的摘要页面查看配置。如果对设置感到满意,可以单击完成按钮来创建端点,如有必要,应用合适的权限。在完成向导后,SQL Server会提示立刻开始镜像还是延迟镜像。如果确定配置是正确的,并且镜像服务器和主体服务器时一致的,那么就可以单击按钮开始镜像。
使用T-SQL配置镜像数据库:为了进行数据库镜像,执行下列命令创建一个不使用加密的端点
-- Create DB Mirroring Endpoint
USE Master;
GO
CREATE ENDPOINT MirroringEndPoint
STATE = STARTED
AS TCP ( LISTENER_PORT = 5022 )
FOR DATABASE_MIRRORING (ROLE=PARTNER)
GO
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
在主体服务器和镜像服务器上执行此语句会创建可用于镜像的同样的端点。如果只是测试镜像,并且没有使用一个单独的物理服务器,那么只要这些端点使用不同的端口号,就可以安装另一个实例来镜像数据库。在使用一个见证服务器时,在见证实例上执行下列命令来创建合适的端点:
-- Create Witness Endpoint
USE Master;
GO
CREATE ENDPOINT WitnessEndPoint
STATE = STARTED
AS TCP ( LISTENER_PORT = 5024 )
FOR DATABASE_MIRRORING (ROLE=WITNESS)
GO
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
创建数据库镜像的额外选项允许指定身份验证和加密选项,要创建一个使用Windows身份验证和AES加密的新端点,可以使用下列代码
-- Create Witness Endpoint with encryption
USE Master;
GO
CREATE ENDPOINT WitnessEndPoint
STATE = STARTED
AS TCP ( LISTENER_PORT = 5024 )
FOR DATABASE_MIRRORING (AUTHENTICATION = WINDOWS NEGOTIATE,
ENCRYPTION = REQUIRED ALGORITHM AES, ROLE = WITNESS);
GO
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
在创建了端点后,下一步就是建立镜像。只需要把每个服务器上的数据库指向目标伙伴即可。这将通过使用一个ALTER DATABASE语句来完成:
-- Begin by configuring the Mirror database
USE Master;
GO
ALTER DATABASE AdventureWorksLT2008
SET PARTNER = 'TCP://AUGHTEIGHT:5022';
-- Execute this statement on the principal server
-- to specify the endpoint for the mirror
USE Master;
GO
ALTER DATABASE AdventureWorksLT2008
SET PARTNER = 'TCP://AUGHTEIGHT:5023';
-- Execute this statement on the principal server
-- to specify the endpoint for the witness
USE Master;
GO
ALTER DATABASE AdventureWorksLT2008
SET WITNESS = 'TCP://AUGHTEIGHT:5024';
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
当主体和镜像服务器都被配置为互相认识时,镜像进程就会开始,默认情况下数据库镜像被配置为使用同步模式,但是可以在镜像开始之后通过在主体服务器上执行下列语句更改这一模式
-- Turn of Synchronous mode
USE Master;
GO
ALTER DATABASE AdventureWorksLT2008
SET PARTNER SAFETY OFF;
- 1.
- 2.
- 3.
- 4.
- 5.
监视数据库镜像:从数据库的任务菜单中选择启动数据库镜像监视器命令,打开一个新窗口。默认情况下,您将会进入从中启动工具的数据库的状态页面;不过,也可以通过单击导航树中的数据库镜像监视器链接额外注册的镜像集。在注册页面上,单击利娜姐按钮联接主体或镜像服务器,使用合适的身份验证和联接选项。然后将会看到该实例上被镜像的数据库的列表,选择合适的数据库进行注册,然后单击确定按钮;如果需要在主体和镜像服务器之间使用不同的身份验证平局,可以选中“当单击确定后,显示管理服务器连接对话框”复选框来指定每个服务器链接的选项。单击警告选项卡可以查看或配置当前基于镜像条件生成警报的设置
管理数据库镜像:暂停镜像会话,如果数据库相应中的延迟比较严重,原因可能是由必须维持主体和镜服务器之间不断通信的额外工作造成的,这时候可能需要考虑暂停那些通信。使用SSMS,浏览数据库属性的镜像页面,单击暂停按钮即可。或者使用TSQL的SET PARTNER SUSPEND执行ALTER DATABASE语句
-- Suspend a mirror
USE Master;
ALTER DATABASE AdventureWorksLT2008 SET PARTNER SUSPEND;
GO
- 1.
- 2.
- 3.
- 4.
恢复镜像会话,可在SSMS中单击恢复按钮,或者使用SET PARTNER RESUME选项执行ALTER DATABASE语句来恢复
-- Resume a Mirror
USE Master;
ALTER DATABASE AdventureWorksLT2008 SET PARTNER RESUME;
GO
- 1.
- 2.
- 3.
- 4.
手动故障转移:不管镜像的操作如何,都可以随时通过SQL Server Management Studio或TSQL手动启动故障转移。在启动故障转移是,任何连接到原主体服务器的客户端都会被立刻断开,而镜像服务器会变成在线。如果原来的主体服务器仍在线,那么它就会变成镜像服务器,并一直处于NO RECOVERY状态,直到再次执行故障转移。要想通过SQL Server Management Studio启动故障转移,在主体数据库的镜像属性页面上单击故障转移按钮即可,SQL 会处理剩下的工作。如果需要将之前的主体数据库还原至主体状态,则必须连接到新的主体数据库,然后单击数据库属性上的故障转移按钮。由于数据库镜像进复制特定数据库的内容,因此在故障转移之前或刚刚发生故障转移时,特定的服务器范围的资源必须在服务器上可用,因此,在使用数据库镜像时,最好创建一个Integration Services包,它将定期复制额外的对象。要使用TSQL手动故障转移,必须连接到主体服务器,然后执行下列代码
-- Manual Failover
USE Master;
ALTER DATABASE AdventureWorksLT2008 SET PARTNER FAILOVER;
GO
- 1.
- 2.
- 3.
- 4.
强制镜像服务器上的服务:当处于高性能或不支持自动故障转移的高安全性模式下,一旦主体服务器发生故障,镜像服务器不是自动可用的,要强制镜像服务器提升自己并响应客户端请求,可以在镜像服务器上发出下列命令:
-- Manual Failover
USE Master;
ALTER DATABASE AdventureWorksLT2008 SET PARTNER FAILOVER;
GO
- 1.
- 2.
- 3.
- 4.
取消数据库镜像:一旦不再需要某个数据库镜像的话,就可以中段镜像。中断镜像允许两个参与的服务器维护该数据库的一份副本。主体服务器会保持在线,而镜像服务器将处于恢复模式。中段镜像不会删除、移除或更改端点,这一点非常好,因为他们仍然可以被使用数据库镜像的其他数据库使用。。通过SSMS中断镜像可以单击主体数据库的镜像属性页面上的取消镜像按钮,如果使用TSQL的话,可以使用ALTER DATABASE语句中的SET PARTNER OFF选项:
-- Remove mirror
USE Master;
ALTER DATABASE AdventureWorksLT2008 SET PARTNER OFF;
- 1.
- 2.
- 3.
原文链接:http://www.cnblogs.com/xupengnannan20070617/archive/2012/09/03/2667865.html
【编辑推荐】