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

《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://pan.baidu.com/s/1bnzvsuz

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

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

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

操作：

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

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

　　　　注：

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

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