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

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_017 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_014 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环境的发布或订阅，可能以列分隔符的方式取代了本机格式中的二进制形式，这样在订阅端应用快照时，即可忽略订阅端的结构，只应用数据；

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