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

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

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

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

 

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

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

http://pan.baidu.com/share/link?shareid=294359247&uk=120218674

 

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

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

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

 

操作:

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

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

    注:

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  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://pan.baidu.com/share/link?shareid=294359247&uk=120218674

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

上一篇:System.Threading.Timer使用心得


下一篇:CString和string的互相转换