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

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

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

Replication的犄角旮旯（三）--聊聊@bitmap

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

Replication的犄角旮旯（五）--关于复制identity列

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

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

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

Replication的犄角旮旯（九）-- sp_setsubscriptionxactseqno，赋予订阅活力的工具

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

接触Replication只有1年多的时间；曾追随JD首席DBR（DB for Replication）陈璟同鞋学习复制，受益匪浅；

关于SQLServer Replication的文章看过不少，大多以原理介绍、如何搭建复制居多。本文旨在从生产环境出发，挖掘Replication中各种犄角旮旯的功能，使其成为运维环节中便于使用的工具；

如无特殊说明，本系列均是基于transaction replication场景；

变更订阅端表名的应用场景

本文以之前我在SQL PASS活动上分享的“翻滚吧 Replication”为背景，相关PPT及demo如下：

http://yun.baidu.com/share/link?shareid=2808657365&uk=120218674

场景描述：一般通过快照或备份初始化，订阅端表名与发布端一致；而我们要研究的是订阅端表名与发布端不一致时的应用场景（发布端 table、订阅端table_new）

用途：适用于在不影响当前复制链路的情况下，实现对同一订阅存在多个副本，以至于延伸到可以满足数据移动、表结构变更等用途；

案例：对于一个较大的且数据表，如果业务方提出要升级表结构（如int类型改为bigint），如何尽量减少停机操作时间？如果这个表参与复制呢？如果被修改的column是主键呢？

操作：

　　1、按照一般方法创建好一个publication，并添加需要发布的article；

　　2、编辑项目属性，参照下图，编辑“目标对象名称”、“名称已被使用时的操作”及“语句传递”

　　　　注：

　　　　　　a)对于修改表结构（int类型改为bigint类型）的需求，可以先在订阅端创建新结构的新表（如table_new），在通过指定“名称已被使用时的操作”为“现有对象保持不变”，让订阅在应用快照时只写入数据而忽略表结构上不一致；

　　　　　　b)事务复制是通过调用订阅端对应的ins、del、upd存储过程实现复制命令在订阅端的执行，为了不影响原有复制链路，需要自定义新的订阅端存储过程名

　　3、添加订阅并通过快照初始化，即可生成“更名的订阅”；

　　4、参照原订阅端旧表，添加对新表的相关权限、索引等；

　　5、在停机维护窗口，停止发布端的写操作；

　　6、待复制命令完全应用到订阅端后，拆除全部复制关系，交换订阅端table和table_new的表名，参照旧的复制关系重新添加不初始化的订阅，即可实现订阅端表结构的变更；

　　至此，我们实现了大数据表升级表结构的业务需求，较之直接在数据表上进行alter table，时间大大缩短，且尽可能的避免长时间架构锁给业务带来的影响；

　　对于无复制关系的单表而言，同样可以参照此方法创建“更名的订阅”实现表结构的升级，但需要注意的是SQLServer Replication的限制：

　　1、同一个数据库不能既是发布又是订阅（自己复制到自己是不允许的）；

　　2、如果增加一个实例，实现A--B--A的链式复制，

　　　　你会发现，即使复制链路可以搭建成功，但B--A，是不会应用复制命令的（貌似Replication将此类复制认为是形成了复制环，也是不被允许的）

　　针对上述限制，就产生了我提出的另一个概念--复制回路；

　　其实就是欺骗了一下Replication，既然2个实例被认为是复制环，那就再加1个实例：A--B--C--A，这样就实现了复制回路，相当于将A上的table重新复制回A上，并更名为table_new；

　　关于复制回路2实例和3实例的测试，可以看一下我云盘中“复制回路Demo.flv”的演示；

　　http://yun.baidu.com/share/link?shareid=2819400848&uk=120218674