事务复制和镜像共存性的测试

事务复制的发布库同时也是镜像的主库，测试的目的是当镜像发生故障转移时，事务复制关系是否能同时自动转移。

环境：JOEPC\SQLJOEC,DB_TEST1,DB_TEST2_VM三台机都是Win2008_R2_SP1+SQLServer2008_R2_SP1.

        JOEPC,DB_TEST1都是物理机，DB_TEST2_VM是建立在DB_TEST1上的虚拟机。

关系说明：JOEPC\SQLJOEC是镜像关系的主体，是事务复制关系的发布者，

              DB_TEST1是镜像关系的见证者，是事务复制的分发者和订阅者，

              DB_TEST2_VM是镜像关系的镜像端。

1. 首先在JOEPC\SQLJOE上创建测试库和表。

USE TEST

GO

CREATE TABLE dbo.tb_Test

(

 ID INT NOT NULL,

 VAL NVARCHAR(20)

 )

GO

ALTER TABLE [dbo].[tb_Test] ADD CONSTRAINT PK_tbTest_ID PRIMARY KEY  CLUSTERED

(

	[ID] ASC

)

GO

INSERT INTO dbo.tb_Test

        ( ID, VAL )

VALUES  (1,N'A'),(2,N'B'),(3,N'C'),(4,N'D')

       ,(5,N'E'),(6,N'F'),(7,N'G'),(8,N'H');

GO

 

2. 参考工作组模式下SQL Server 2008 R2 事务复制建立JOEPC\SQLJOE与DB_TEST1事务复制关系。

3. 参考工作组模式下SQL Server 2008 R2 数据库镜像建立JOEPC\SQLJOE为主体，DB_TEST2_VM为镜像，DB_TEST1为见证的镜像关系。

    在这里我遇到一个问题见证机总是连接不上，最后放弃用代码来实现，用镜像配置向导重新配置，成功。

4. 在分发服务器DB_TEST1上把镜像服务器DB_TEST2_VM加入到发布者。

    这一步的目的：1.将镜像添加为发布者。2. 镜像成为发布者后与镜像主体使用同一个快照文件夹，同一个发布服务器。

   

5. 在分发服务器上执行以下代码。profile_id代表不同的配置文件，下面列出几个对应关系。

--查看代理配置文件

-- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.

exec sp_help_agent_profile

--因为测试做的是事务复制,所以需要修改配置文件只包括Snapshot Agent,Log Reader Agent.

exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner',

 @parameter_value = N'DB_TEST2_VM';

exec sp_add_agent_parameter @profile_id = 2, @parameter_name = N'-PublisherFailoverPartner',

@parameter_value = N'DB_TEST2_VM';

 

6.基本配置完成。测试验证一下，把JOEPC\SQLJOE的SQLSERVER服务停掉，看一下镜像和复制关系能否转移。

   6.1 镜像关系成功转移过来了。

        

  6.2 事务复制关系开始时遇到一个错误：“进程无法在“DB_TEST2_VM”上执行“sp_replcmds”。 (源: MSSQL_REPL，错误号: MSSQL_REPL20011)”。

       这个错误是个权限问题，执行sp_replcmds需要sysAdmin权限，于是把TEST库的所有者改成SA。在DB_TEST2_VM上执行：

USE TEST

GO

EXEC sp_changedbowner 'SA','dbowner'

GO

      

     OK,事务复制也正常了。不过还是插入两条数据看一下，能否同步到DB_TEST1下的订阅库TEST_Subscriber。

INSERT INTO dbo.tb_Test(ID,VAL) VALUES(9,N'I'),(10,N'J')

     在DB_TEST1的订阅库TEST_Subscriber查询，发现数据没有同步过来。在日志读取代理的作业历史中找到“复制的事务正等待下一次日志备份或等待镜像伙伴更新”。

     在MSDN上找到：

        

   这个测试中镜像用的正是“具有自动故障转移的高安全性模式”，并且“步骤6”中把JOEPC\SQLJOE的SQLSERVER停掉了。

   所以只有当JOEPC\SQLJOE的SQLSERVER联机，重新构成镜像关系后，所做的修改才会从分发库传播到订阅库。

    于是启动JOEPC\SQLJOE的SQLSERVER，果不其然，数据同步过去了。

 

总结：

      1. 镜像主体库，可以同时做事务复制的发布库，并且能实现故障自动转移。

      2. 我想要给一个7*24的关键库，用事务复制做读写分离，并且用“具有自动故障转移的高安全性模式”做热备。测试的结果有些鸡肋。

         当镜像关系中，有一个伙伴离线，故障自动转移后所做数据修改不会传播到订阅端。那么读写分离的只读库的数据也严重滞后，而不可用。

     --Add@20150113

     3. 启用TF1448:事务复制和镜像共用时，改变LogReader的读取限，当镜像故障时仍然可以从Principle读取日志。

 

-------------------------------------

作者：Joe.TJ