?
?
《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
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
