Replication的犄角旮旯(八)-- 订阅与发布异构的问题

原文:Replication的犄角旮旯(八)-- 订阅与发布异构的问题

 

 

《Replication的犄角旮旯》系列导读

Replication的犄角旮旯(一)--变更订阅端表名的应用场景

Replication的犄角旮旯(二)--寻找订阅端丢失的记录

Replication的犄角旮旯(三)--聊聊@bitmap

Replication的犄角旮旯(四)--关于事务复制的监控

Replication的犄角旮旯(五)--关于复制identity列

Replication的犄角旮旯(六)-- 一个DDL引发的血案(上)(如何近似估算DDL操作进度)

Replication的犄角旮旯(七)-- 一个DDL引发的血案(下)(聊聊logreader的延迟)

Replication的犄角旮旯(八)-- 订阅与发布异构的问题

Replication的犄角旮旯(九)-- sp_setsubscriptionxactseqno,赋予订阅活力的工具

---------------------------------------华丽丽的分割线--------------------------------------------

 

订阅与发布异构的情况并不常见,我们曾经的案例是对发布表扩充列长度时,避免长时间锁表而采用异构的方式,详见之前的博客

Replication的犄角旮旯(一)--变更订阅端表名的应用场景

对于异构产生的问题,还要感谢微软工程师浩然兄的提醒。

 

前言:

订阅与发布异构(我定义的名字):实际指发布端和订阅端存在列长度上的不一致情况,如发布端某列为int类型,由于业务增长,需要扩容到bigint;

尽管replication支持DDL的传递,但直接在发布表上alter table,执行时间受表大小和更新频率影响较大,长时间的锁表必然是业务所不能容忍的;因此,想到个折中的办法——复制回路。

也就是通过一个闭环,本地发布的表创建一个到本地的异构订阅,在同步完数据后,通过交换表名的方式,实现数据表的alter变更操作,可以最大化的缩短锁表时间;

但这其中却碰到个问题,也就是本文要描述的中心内容;

 

闲话少叙,亮真家伙!

 

现象:创建异构表后,通过快照初始化时,发现订阅端记录全部乱掉;

1 CREATE TABLE test_a.dbo.tmp_byxl_01 (id INT NOT NULL PRIMARY KEY IDENTITY NOT FOR REPLICATION,flag TINYINT)
2 CREATE TABLE test_b.dbo.tmp_byxl_01_new (id BIGINT NOT NULL PRIMARY KEY IDENTITY NOT FOR REPLICATION ,flag TINYINT)
3
4 INSERT INTO test_a.dbo.tmp_byxl_01 VALUES(1),(2)
5
6 SELECT * FROM test_a.dbo.tmp_byxl_01
7 SELECT * FROM test_b.dbo.tmp_byxl_01

View Code

使用上面的脚本创建测试表和测试数据,采用默认方式创建事务复制(注意,由于发布和订阅端异构,在选择artile属性时,需选择“保持现有对象不变”)

1 INSERT INTO test_a.dbo.tmp_byxl_01 VALUES(3),(4)
2
3 SELECT * FROM test_a.dbo.tmp_byxl_01
4 SELECT * FROM test_b.dbo.tmp_byxl_01

View Code

查看发布和订阅的数据

发现通过快照初始化的数据(1,2)在订阅端只变成了一行,且ID和flag的值都不正确;而快照初始化后写入的数据时正确的;

 

反复测试后,均出现了类似的情况;

经浩然兄指点,怀疑是在创建快照的时候,由于是二进制形式,int和bigint存储的长度有差异(int为4字节,bigint为8字节),在订阅端解析时,由于异构的存在,对二进制解析截断存在偏差,因此导致应用快照后出现数据异常;

而新增的数据,由于replication默认采用订阅端call proc的方式,只是数据的传递,因此不存在类似的问题;

 

再纠结了一个多月后,这个问题终于有了进展;

既然问题出在快照创建的阶段,因此考虑尝试使用其他模式的快照

sp_addpublication中有个参数@sync_method

由于我们是事务复制,因此改成concurrent_c

对图形界面来说,需要修改发布属性中的快照格式,改成字符型;

 

重新以字符型格式创建快照,可以看到订阅端数据正常了;

 

问题分析:由于暂时没有十六进制分析工具,没有进一步分析本机格式和字符格式下创建的快照有什么样的差异,但初步怀疑,字符型为了兼容非sqlserver环境的发布或订阅,可能以列分隔符的方式取代了本机格式中的二进制形式,这样在订阅端应用快照时,即可忽略订阅端的结构,只应用数据;

 

时间: 2015-02-12

Replication的犄角旮旯(八)-- 订阅与发布异构的问题的相关文章

Replication的犄角旮旯(一)--变更订阅端表名的应用场景

原文:Replication的犄角旮旯(一)--变更订阅端表名的应用场景     <Replication的犄角旮旯>系列导读 Replication的犄角旮旯(一)--变更订阅端表名的应用场景 Replication的犄角旮旯(二)--寻找订阅端丢失的记录 Replication的犄角旮旯(三)--聊聊@bitmap Replication的犄角旮旯(四)--关于事务复制的监控 Replication的犄角旮旯(五)--关于复制identity列 Replication的犄角旮旯(六)--

Replication的犄角旮旯(九)-- sp_setsubscriptionxactseqno,赋予订阅活力的工具

原文:Replication的犄角旮旯(九)-- sp_setsubscriptionxactseqno,赋予订阅活力的工具 <Replication的犄角旮旯>系列导读 Replication的犄角旮旯(一)--变更订阅端表名的应用场景 Replication的犄角旮旯(二)--寻找订阅端丢失的记录 Replication的犄角旮旯(三)--聊聊@bitmap Replication的犄角旮旯(四)--关于事务复制的监控 Replication的犄角旮旯(五)--关于复制identity列

Replication的犄角旮旯(四)--关于事务复制的监控

原文:Replication的犄角旮旯(四)--关于事务复制的监控     <Replication的犄角旮旯>系列导读 Replication的犄角旮旯(一)--变更订阅端表名的应用场景 Replication的犄角旮旯(二)--寻找订阅端丢失的记录 Replication的犄角旮旯(三)--聊聊@bitmap Replication的犄角旮旯(四)--关于事务复制的监控 Replication的犄角旮旯(五)--关于复制identity列 Replication的犄角旮旯(六)-- 一个D

Replication的犄角旮旯(五)--关于复制identity列

原文:Replication的犄角旮旯(五)--关于复制identity列     <Replication的犄角旮旯>系列导读 Replication的犄角旮旯(一)--变更订阅端表名的应用场景 Replication的犄角旮旯(二)--寻找订阅端丢失的记录 Replication的犄角旮旯(三)--聊聊@bitmap Replication的犄角旮旯(四)--关于事务复制的监控 Replication的犄角旮旯(五)--关于复制identity列 Replication的犄角旮旯(六)--

SQL SERVER2000中订阅与发布的具体操作收藏

SQL SERVER2000中订阅与发布的具体操作 同步过程 一.准备工作,如果完成则可跳过. 1.内网DB服务器作为发布服务器,外网DB服务器作为订阅服务器.发布服务器和订阅服务器上分别创建Windows用户jl,密码jl,隶属于administrators,注意要保持一致.2.发布服务器上创建一个共享目录,作为发布快照文件的存放目录.例如:在D盘根目录下建文件夹名为SqlCopy,设置用户jl,权限为完全控制.3.确定发布服务器和订阅服务器的数据库autoweb保持一致.4.在发布服务器和订

linux下使用hiredis异步API实现sub/pub消息订阅和发布的功能

本文转载自链接: http://blog.csdn.net/chenzba/article/details/51224715  最近使用redis的c接口--hiredis,使客户端与redis服务器通信,实现消息订阅和发布(PUB/SUB)的功能,我把遇到的一些问题和解决方法列出来供大家学习.        废话不多说,先贴代码. redis_publisher.h /*************************************************************

八百客发布秋季版直击Salesforce 上演亦敌亦友间的博弈

在这个"客户才是上帝"的时代,谁能赢得消费者的信赖和忠诚,谁就能占领整个市场,成为王者.CRM作为一种集结了先进营销管理理念和前沿科学技术的客户关系管理软件,能帮助企业完善销售流程,提升客户忠诚度,因而受到了越来越多企业的推崇. 近年来,随着企业信息化进程的加速,CRM市场逐渐升温,IT行业巨头纷纷进入该领域,推动了整个行业的发展.在云计算所引发的第三次信息技术革命浪潮向世界蔓延的推动下,中国云计算产业也已达到与其它国家齐头并进的水平,不断上演着国际大佬与本土企业激烈角逐的"

分享一个分布式消息总线,基于.NET Socket Tcp的发布-订阅框架,附代码下载

一.分布式消息总线      在很多MIS项目之中都有这样的需求,需要一个及时.高效的的通知机制,即比如当使用者A完成了任务X,就需要立即告知使用者B任务X已经完成,在通常的情况下,开发人中都是在使用者B所使用的程序之中写数据库轮循代码,这样就会产品一个很严重的两个问题,第一个问题是延迟,轮循机制要定时执行,必须会引起延迟,第二个问题是数据库压力过大,当进行高频度的轮循会生产大量的数据库查询,并且如果有大量的使用者进行轮循,那数据库的压力就更大了.      那么在这个时间,就需要一套能支持发布

Jquery 自定义事件实现发布/订阅的简单实例_jquery

Jquery 自定义事件实现发布/订阅的简单实例 //用户点击logoff按钮时,广播一个自定义事件,给任何需要保存状态的感兴趣的观察者,然后导航到logoff页面 $('#logoff').click(function(){ $.event.trigger("logoff");//广播一个事件 window.location = "logoff.php";//导航到新页面 }); 以上这篇Jquery 自定义事件实现发布/订阅的简单实例就是小编分享给大家的全部内容