实验一：SQL server 2005高可用性之----日志传送

如转载，请注明出处：http://blog.csdn.net/robinson_0612/archive/2009/10/31/4751070.aspx

 

 

      SQL server 2005高可用性之日志传送是在SQL server 2000 日志传送基础之上的延续，两者其本质上并没有太大的差异。日志传送能够同步位于不同服务器或同一服务器不同实例之间的数据库，通过将主服务器上备份出来的一系列日志自动传送到辅助服务器上并进行恢复。当主服务器宕机的时候，日志传送功能并不能实现从主服务器到辅助服务器的自动故障转移功能，需要手动将辅助服务器切换到联机状态，使得辅助服务器上数据库来提供服务，从而实现数据库的高可用性。

     一、实验目的：配置SQL server 2005日志传送、监控日志传送状态及故障转移。

     二、日志传送使用的场景

        1. 可用于支持Reporting server，通过指定standby模式来实现相应的查询功能，并保持与主体数据库同步。

        2. 可用于初始化镜像数据库，使得镜像中主体数据库与镜像中的镜像数据库在时间上，时点延迟上更接近，加快镜像会话的实现。

        3. 实现数据库的版本更新或迁移到新平台，有利于最小化应用程序的宕机时间。

        4. 实现多个将多个主数据库的数据备份到一个辅助数据库，节省资源和开支。

 

     三、实现日志传送的组成部分

        1. Primary server(Primary database):  主服务器中用于实现日志传送的主体数据库

        2. Secondary server(Secondary database):   辅助服务器中恢复日志文件的数据库，可以为多个主服务器提供日志备份。

        3. Monitor Server: 可选的监视服务器，用于记录日志传送过程中出现的异常情况，失败时给出警告，存储在msdb数据库中。

 

     四、实现日志传送所需的环境

        1. 至少两台SQL server 2005服务器，或同一服务器的两个实例。

        2. SQL server 2005的版本要求为Standard, Workgroup, Enterprise, or Developer Edition之一。

        3. 主体服务器的主体数据库使用完全恢复模式(FULL)或大容量日志恢复模式(Bulk-Logged)。

        4. 主体服务器中SQL server Agent服务启动帐户拥有对存放备份日志文件目录读写的权限，辅助服务器中SQL server Agent启动帐户一是要有对主服务器上存放备份日志文件目录读的权限，用于从主服务器复制日志文件，二是要拥有辅助服务器上存放用于恢复日志文件目录读写的权限。用于将复制过来的日志文件写入恢复日志文件目录。不建议将备份出来的日志文件存放到主服务器，可以考虑放到文件服务器上，减少主服务器的I/O。

        5. 若主服务器备份出的日志文件要存放到其他服务器或文件服务器，请使用Windows域用户帐户启动主服务器的SQL server Agent服务。

        6. 启动主体服务器和辅助服务器的SQL server Agent服务，若有监视服务器，也应当启动监视服务器的SQL server Agent服务。

 

     五、实现日志传送所需要用到的几个作业

       1.  备份作业(backup job): 运行在主服务器上，为每个实现日志传送数据库创建一个备份作业，备份主体数据库日志，删除旧的日志文件或历史记录信息，并将其记录到主服务器和监视服务器上。

       2.  复制作业(copy job):  运行在辅助服务器上，将备份文件从主服务器复制到辅助服务器，并记录信息到辅助服务器和监视服务器上。

       3.  还原作业(restore job):  运行在辅助服务器上，为每个日志传送配置创建一个还原作业，恢复从主体数据库传送过来的日志，删除旧的日志文件或历史记录信息，并将其记录到辅助服务器和监视服务器上。 

       4.  警报作业(alter job): 运行于监视服务器上，警报作业由使用监视器服务器实例的所有日志传送配置中的主数据库和辅助数据库所共享。

 

     六、本次实验的环境

       1. windows xp pro (英文版) + sp2

       2. SQL server 2005 Developer + sp3

       3. 同一主机的三个实例： ROBINSON ， ROBINSON/MIRROR，ROBINSON/WITNESS

       4. 用于日志传送的数据库为Ecustom_qah

       5. 因在同一服务器上实现日志传送，本实验没有增加SQL server Agent 服务帐户，用的是Local system帐户启动SQL server Agent 服务。

 

    七、具体实验步骤如下

       1. 设定共享目录，在主服务器上设定Backuplog并共享，使主服务器上的SQL server Agent 服务帐户拥有读写的权限，使辅助服务器上的SQL server Agent 服务帐户拥有读的权限。Backuplog用于存放主服务器备份出来的日志文件。

       2. 辅助服务器上设定Resotrelog，使辅助服务器上的SQL server Agent 服务帐户拥有读写的权限。Resotrelog用于存放从主服务器复制过来的日志文件，用于恢复。

       3. 在辅助服务器上设定一个初始化数据库的文件夹Databckup并共享，使辅助服务器上的SQL server Agent 服务帐户拥有读写的权限。Databckup用于存放Ecustom_qah的mdf文件和ldf文件。

       4. 测试以上的设置可以正常使用，因本实验在同一台服务器上执行，故仅仅是在D：盘下设定了Backuplog、Resotrelog、Databackup并设定相应权限。

       5. 启动相关服务。在SQL Server Configuration Manager中查看各个实例的MSSQLSERVE 和SQL server Agent是否启动，如下图：

                

 

        6. 查看用于日志传送的主数据是否处于FULL或Bulk-Logged恢复模式，如不是，请修改其为FULL或Bulk-Logged恢复模式。

            也可以使用如下语句来修改恢复模式： Alter database Ecustom_qah  set recovery FULL。

        7. 启动SSMS并连接到主服务器，展开databases文件夹，右单击Ecustom_qah，选择Properties,选择Transaction Log Shipping，选择Enable This As A Primary Database In A Log Shipping Configuration后单击Backup Settings设置。

        8. 输入备份文件夹网络路径，当备份文件夹位于主服务器上时，输入主服务器上的文件夹。

        9. 设定超6分钟后删除日志文件，并设定3分钟没有备份则提示报警。

 

 

          

 

        10.单击Schedule，设定日志的备份频率，为每2分钟备份一次日志文件。

        11. 单击 Add 按钮添加Secondary server.

        12. 单击connect，连接Secondary server，输入帐户和密码，选择secondary database为Ecustom_qah，在Initialize Secondary Database中，因我们没有对初始数据库进行备份，故在此处选择generate a full backup，并设定其Restore options，设定数据文件和日志文件的位置在辅助服务器上的所在的文件夹 。

        13. 如果在设定日志传送之前已经备份了数据库或已对辅助数据库初始化可以选择restore an existing backup或the secondary database is initialized.

 

         

 

      14. 在copy files选项卡设定复制文件的目的文件夹，设定删除已复制的文件的时间间隔为6分钟，复制频率为每2分钟复制一次日志文件。       

         

 

        15. 在Restore Transaction Log选项卡中设定No recovery模式，并设定延迟为1分钟，恢复每2分钟发生一次，超过4分钟日志没有恢复则报警。

           

 

 

        16. 设定完Restore Transaction Log后，回到log shipping 主界面，勾选use a monitor server instance，选择settings选择ROBINSON/WITNESS并设定15分钟后删除历史记录。

            

        17. 按以上设定完毕后，点击ok，系统开始按所设定配置日志传送，如果有错误发生，系统会给出警告，按警告提示更正相关错误。

        18. 如设定无误后，连接到MIRROR实例和WITNESS实例，则在各个实例之间的jobs会出现相关作业，在MIRROR实例中出现数据库Ecustom_qah(Restoring)如下图所示：

 

         

       

 

        19. 打开设定的文件夹检查主服务器的备份情况和辅助服务器上复制过来的日志文件。

        

         

        至此SQL server 2005日志传送配置完毕。

     八、监控日志的传送

       1. 通过存储过程查看日志传送的情况

             如在主服务器上执行：sp_help_log_shipping_primary_database 'Ecustom_qah'

                在辅助服务器上执行：sp_help_log_shipping_secondary_database 'Ecustom_qah'

             也可以在监视服务器上执行脚本来跟踪日志的传送情况，如下图：

         

 

        2. 通过摘要中报表模块下的事物日志传送状态来动态查看和跟踪事务日志的情况。

            因本机所使用SQL server 2005的版本为Developer + sp3 ，所以无报表模块功能，什么原因待考证。笔者曾在SQL server标准版(中文)中看到有报表且有事物日志传送状态功能但安装了sp3中文补丁后则不再有此功能。如有知其原因者可以给我留言。

        3. 通过警报作业将故障通知道相关人员。

            在监视服务器上我们可以看到有两个警报作业，即Alters下，我们可以看到Log shipping Primary Server Alert和Log shipping Secondary Server Alert。.默认的情况，如果监视到错误，并不会做任何通知，我们可以通过新建操作员(Operators)来接受相关报警信息。同样，我们也可以在主服务器和辅助服务器上设定操作员来接受相关报警信息，可以通过消息，邮件等形式，前提是需要配置数据库邮件或启动操作系统中的Messenger信使服务等，如本试验中设定的启动了Messenge服务后，则得到如下图的提示：

      

        4. 对于常见的SQL server故障，我们可以通过查看操作系统的事件查看器或SQL server日志来发现问题。

     九、事务日志模式

           在设置辅助数据库时，对于恢复事务日志Restore Transaction Log选项卡，我们设定了为No recovery mode，还有一个可供选择的则为Standby mode。在事物日志的传送过程中，恢复事务日志Restore Transaction Log与我们普通的恢复不同，一般情况下的恢复是回滚所有未提交的事务，前滚所有已提交但未写入磁盘的事务。事务日志中，如果一个事务回滚，所有改变的数据将会被丢失，因为在这个时候，你并不知道下一事物究竟是回滚还是提交。故在事务日志传送中提供了No recovery mode和Standby mode，两者的介绍如下：

        1. 无恢复模式(No recovery mode):既不前滚也不回滚未提交的事务，数据不可读。

        2. 备用模式(Standby mode):在恢复日志期间回滚所有未提交的事务，并且将所有未提交的事务保存为一个单独的Transaction Undo File(TUF)文件，恢复过程通过该文件来维护事务的完整性，当恢复下一个事物的时候则恢复所有已提交的事务。Standby mode中的复选框勾选则当日志恢复的时候，断开所有用户的连接，如果有一个用户没有断开，则还原无法进行。

 

 

     十、演示Standby mode查看日志传送及故障转移

        1. 将No recovery mode切换到Standby mode 。此操作在主服务器上打开Ecustom_qah 的 properties，选择Transaction Log shipping，点击辅助数据库后的… 号打开Restore Transaction Log，直接点击Standby mode即可，可以勾选当日志恢复的时候断开所有用户的连接。如果设定的复制和恢复间隔时间很短，则当主服务器上所有在Restoring模式下的备份出来的日志文件在辅助服务器上恢复完毕后，会自动在复制到的目录中产生一个tuf文件。且辅助服务中Ecustom_qah 数据库由restoring显示为standby/read-only模式。如果设定的复制和恢复间隔时间很长，可以手动执行辅助服务其中的copy 作业和restore作业，将主服务器上所有未复制的日志文件复制到设定的恢复目录(restorelog)中，然后恢复到辅助服务器中。同样也可以将Standby mode切换回No recovery mode。图略。

        2. 可以通过在原始数据库中创建新的表或表中插入记录在到辅助数据库中检查该变化是否亦同步，前提是使用Standby mode，此演示省略。

        3. 故障转移

• 在主服务器Ecustom_qah数据库中，删除complex表中字段code_ts中以04开头的记录,delete from complex where code_ts like '04%'。
• 停止主服务器的MSSQLSERVER服务，然后删除主服务器中的Ecustom_qah数据库的mdf文件来模拟主服务器故障。
• 重新启动主服务器的MSSQLSERVER服务服务，在主服务器master中执行备份尾部日志。

             backup log Ecustom_qah to disk ='D:/Restorelog/last.bak' with no_truncate

• 将主、辅助、监视服务器上日志传送的几个作业禁用(Disable) 。
• 在辅助服务器上执行copy作业和resotre作业将未复制过来的日志复制到恢复目录并全部恢复完毕。
• 将尾部日志恢复到辅助服务器辅助数据库中并使辅助数据库Ecustom处理联机状态。在辅助服务器master数据库中执行如下脚本:

              restore log Ecustom_qah from disk = 'D:/Restorelog/last.bak' with norecovery;
              go
              restore database Ecustom_qah with recovery;
              go

•  改变应用程序的连接字符串，使应用程序连接到辅助服务器的辅助数据库，此时辅助服务器的辅助数据库已变成为主服务器主数据库。
•  当原始主服务器修复后，再重新配置日志传送即可。