《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存儲過程實現復制命令在訂閱端的執行，為了不影響原有復制鏈路，需要自定義新的訂閱端存儲過程名