事务复制中的snapshot

4: 重新创建发布、订阅。问题解决。

Snapshot agent读取article的信息,将article的内容和脚本放置到snapshot文件夹中; 接下来distribution agent会读取这些快照文件,传输到订阅,完成初始化操作。期间distribution agent需要处理很多事情,例如判断快照是否可用,需要应用那些快照文件,传输过程中发生中断怎么办 等等。这些都需要distribution agent来协调。读完本文之后您会对这些处理方式有所了解,也会帮助您更好地判断当前事务复制的状态以及进行错误排查。

 

现在基本知识介绍完毕,下面开始进入正题

The concurrent snapshot for publication 'RPL_PUB_Tecdb' is not available because it has not been fully generated or the Log Reader Agent is not running to activate it. If generation of the concurrent snapshot was interrupted, the Snapshot Agent for the .....

  1. 当创建发布和订阅后,distribution 数据库中MSsubscriptions表的status列为1(Subscribed),

  2. 如果此时运行distribution agent,会抛出21075, 21076或21088错误"The initial snapshot for %%  is not yet available".  

  3. 当快照生成后,snapshot agent会去更新MSsubscriptions中的status列的状态。当status列的值为2(Actived)时,表示快照已经完成,这样distribution agent就可以正常运行了。不过根据不同的设置,snapshot agent会将status列更新为不同的值:
  4. 如果sync_method是concurrent(sql server 2005以及以后版本的默认模式),status的值会变更为3; 如果此时运行distribution agent,会出现下面的21388的错误The concurrent snapshot for publication 'PublicationName' is not available because it has not been fully generated or the Log Reader Agent is not running to activate it. If generation of the concurrent snapshot was interrupted, the Snapshot Agent for the publication. 我们必须运行一下log reader agent,运行后, status就被更新为2(active)了. 这样distribution agent就可以正常运行了。

  5. 如果sync_method是native,那么status的值会被直接更新为2,

       

    如何应用快照文件

 

@get_count tinyint = 0,  -- 0 = no count, 1 = cmd and tran (legacy), 2 = cmd only 

 

@compatibility_level int = 7000000, 

3: 从MSarticles、MSsubscriptions 中删除对应的数据

@last_xact_seqno varbinary(16), 

其实这里面只需要查看distribution..MSpublisher_databases、distribution..MSarticles 、distribution..MSsubscriptions

@agent_id表示distribution agent id,每个订阅都会有一个单独的distribution agent来处理数据。 带入@agent_id后,就可以找到订阅对应的publication 和所有的article。

SELECT  *

FROM    msdb..MSdistpublishers;

 

SELECT  *

FROM    distribution..MSpublisher_databases;

 

SELECT  *

FROM    distribution..MSpublications;

 

SELECT  *

FROM    distribution..MSarticles;

 

SELECT  *

FROM    distribution..MSsubscriptions;

如何判断快照是否可用

 

Snapshot会在快照文件夹或alt_snapshot_folder生成快照文件,那么distribution
agent是如何找到这些文件并应用的呢?


Snapshot
agent会将一些信息写入到distribution 数据库中的MSrepl_transactions和MSrepl_commands表中,下面是snapshot产生后两张表的查询截图 

![](https://images0.cnblogs.com/blog/14074/201308/08080323-03bcbff513f149da8350e143f356c395.jpg) 

那么这些内容代表什么意义呢?我们可以通过sp_browsereplcmds来查看
, 

use distribution 

go 

exec sp_browsereplcmds
'0x0000001E0000008F001E','0x0000001E0000008F001E'
.


![](https://images0.cnblogs.com/blog/14074/201308/08080324-b45decc4866c40b0b27791ee9d2c5f1c.jpg) 

表中的内容包含了snapshot文件的名称和路径,
distribution agent就会据这些信息将snapshot应用到订阅数据库中。


   

   

**如何判断是否需要应用快照**


当一个订阅数据库完成初始化之后,如何避免distribuiton
agent下次运行时重复应用快照呢? 系统表中并没有单独的字段来标记订阅数据库是否已经完成了快照。
实际上,这些判断逻辑是包含在sp_MSget_repl_commands里的: 

当第一次初始化时,订阅数据库的LSN(MSreplication_subscriptions表的 transaction_timestamp)小于快照文件对应的LSN,这样,所有大于订阅LSN(也包含了快照)的数据都会被同步到订阅。


   

接下来就有个问题了,假设发布添加了一个新的订阅数据库,新的订阅数据库需要distribution
agent来帮助其完成初始化快照的步骤。于是生成了一个新的快照,这些快照的xact_seqn肯定是大于已存在的订阅的xact_seqno的。
但对于已经存在的订阅数据库,是不需要应用这些快照的.那么distribution
agent是如何处理这种情况的呢? 

实际上sp_MSget_repl_commands除了会比较xact_seqno,还存在额外的判断:订阅对应的每个已发布项目在
MSsubscriptions
表中都会有一行记录。MSsubscriptions 表的subscription_seqno
列表示快照事务序列号;publisher_seqno 
列表示该订阅在发布服务器上的事务序列号。如果@last_xact_seqno的值小于这两个值中的任意一个,就表示订阅需要应用快照,否则表示快照已经应用过了,只需要应用后续更新即可。


当第一次快照生成后,这两个列的值就不会再放生变化了(除非订阅被标记为需要重新初始化),但是订阅数据库的MSreplication_subscriptions表的 transaction_timestamp是不断增加的,所以即使生成新的快照,已存在的订阅也不会受到影响。


   

**在应用快照过程中意外中断怎么办?**


假设一共有8个snapshot文件,distribution agent已经应用了3个文件,在应用第四个文件的时候OS重启了。
那重启后该如何继续呢? 是否需要全部重新开始呢? 答案是否定的。
在应用snapshot文件的过程中,distribution agent会向subscription数据库里的MSsnapshotdeliveryprogress系统表写入数据,每当一个文件成功应用到订阅,就会写入一条数据。如果意外重启,distribution agent会根据这张表来判断哪些文件已经被应用过。当所有的snapshot文件都传递到订阅后,distribution会清除表里的内容。  当下面是MSsnapshotdeliveryprogress的查询截图。 

![](https://images0.cnblogs.com/blog/14074/201308/08080325-d2b518e70d3a4ac981d27f5053bfb16c.jpg) 

参考资料:

   

2: 查看关于发布订阅的一些信息

exec sp_MSget_repl_commands 46,0x0010630F000002A900EA00000000,0,10000000

DELETE  FROM distribution..MSarticles

WHERE   publisher_db = '<NameOfDatabase>';

 

 

DELETE  FROM distribution..MSsubscriptions

WHERE   publisher_db = '<NameOfDatabase>';

   

 

   

这个可能是因为以前配置过这个数据库的发布订阅,但是由于某些原因,没有清理干净。我参考网上http://stackoverflow.com/questions/1018339/the-concurrent-snapshot-for-publication-xx-is-not-available-because-it-has-not的解决方案 ,连续测试了几个发布订阅,都能完美解决这个问题,特此记录一下,方面以后遇到该问题能顺速解决。

图片 1

大致逻辑是:Reader读取分发数据库中LSN大于@last_xact_seqno的数据。 Writer将读取到的数据写入订阅,并更新订阅的LSN.( MSreplication_subscriptions表的 transaction_timestamp列)。然后Reader会继续用新的LSN来读取后续的数据,再传递给Writer,如此往复。在sp_MSget_repl_commands 的处理过程中, Msrepl_Commands表(通过type列进行区分)的数据大致分为两种: 1快照产生的数据,2 正常更新产生的数据

 

reader是通过sp_MSget_repl_commands来读取distribution数据库中(读取Msrepl_transactions表和Msrepl_Commands表)的数据

本文由金沙官网线上发布于数据库,转载请注明出处:事务复制中的snapshot

您可能还会对下面的文章感兴趣: