TDSQL資料同步和備份

TDSQL另外一個輔助特性：資料同步和備份。

# TDSQL資料同步元件


**資料同步的重點分為三個場景：**

**第一個場景是一個資料彙總。**比如，多個資料庫例項的資料同步到一個資料庫例項，如保險行業使用者多喜歡將全國多個區域資料庫例項的資料同步到全國總庫進行統計分析。

**第二個就是跨城的容災。**跨城容災，一般一個城市的分散式資料庫的資料需要同步到另外一個城市異構的分散式資料庫中做災備。有的時候我們要做異構資料庫的跨城容災，比如說主城是一個十六節點的資料庫，它非常龐大。但是備城，可能我們基於成本考慮，選用的裝置數量、機房都要差一些。

比如災備例項只有兩個物理分片。一個是兩分片資料庫例項，而另外一個時十六分片的資料庫例項。從十六分片同步到；兩分片，這是一個異構的資料庫的同步，這時候我們就需要利用資料同步這個元件。

**第三個是遷移。**異構資料庫的遷移，將資料從TDSQL同步到MySQL、Oracle、PostgreSQL等資料庫。當然，從TDSQL到TDSQL是一種同步方式，更有一種是TDSQL到其他異構資料庫。舉個例子，張家港農商行，它的核心繫統需要從傳統的國外商用資料庫替換為TDSQL，可能還是需要做一定的風險的防範。

最終我們給了一套用Oracle作為TDSQL災備示例的方案，通過資料同步元件，將TDSQL的資料準實時同步到Oracle。假如在極端情況下需要將業務切到Oracle，我們也是有這個能力的。

當然資料遷移也體現了TDSQL開放的思想，既然允許使用者將資料遷移到TDSQL，如果有一天使用者可能覺得TDSQL不是很好，覺得有更好的產品可以替代它，TDSQL支援使用者把資料遷走。

# TDSQL資料備份


**TDSQL支援線上的實時熱備，同時這個備份是基於備機上做的備份，備份支援映象和binlog的備份。映象又支援物理映象和邏輯映象（也叫物理備份和邏輯備份）。**

物理備份的好處是速度快，直接操縱物理檔案，缺點是隻能備份整個資料庫例項，無法選擇指定庫表。邏輯備份的好處是通過SQL的方式備份，它可以選擇單個庫表備份，但是如果對整個例項備份效率不及物理備份。比如說有1T的資料，只有100兆是我的關鍵的資料，如果為了節省儲存空間就沒有必要用物理備份，就用邏輯備份，只備份我們關心的庫表。

有了物理備份和邏輯備份之後，基於資料的映象，再結合binlog輕鬆實現資料的定點恢復。對於binlog的備份TDSQL的Agent模組完成準實時的非同步備份。比如說我們每天的0點備份映象，同時各個時間段的binlog準實時備份。當需要恢復到一個早上6點的資料，利用0點的資料映象再結合0點到6點的binlog，即可完成6點的資料恢復。

**備份是在備機上做不會影響主機。整個備份過程也是有監控有告警，實現整個備份過程的追蹤。**

因為架構這一塊內容確實是比較多，本次也作為所有TDSQL系列分享的一個前瞻，後面更多的系列分享會根據這門課的部分章節詳細展開。這次分享主要是想幫助大家瞭解TDSQL的整體架構和模組劃分，以及它的關鍵特性是如何設計，是基於什麼樣的考慮。聽完本次分享再聽後面的專題，會更容易去理解。

# Q&A

Q：TDSQL 1.0版本沒有SQL引擎模組吧？ 

A：最早在2002年的時候我們使用單機版MySQL作為資料存取服務，而後衍生出了TDSQL，這種計算儲存相分離的架構，進而引入SQL引擎。

Q：請問儲存節點的MySQL是使用官方原生的麼 ？ 

A：TDSQL在原生MySQL基礎上做了大量調優，如執行緒池、強同步的優化，以及安全限制，分散式事務XA優化等等。

Q：銀行核心要做到分庫分表，開發的聚合查詢如何實現？

A：SQL引擎遮蔽了分表的細節，讓業務在邏輯上看到的和單節點模式一下一樣，仍然是一張獨立的庫表。此外，SQL引擎會自動做資料聚合，業務開發不需要關心。

Q：a+3，如果掉失了，B和C節點都沒有同步過來，怎麼辦？A機器已經已經無法恢復。

A：a+3如果沒有被B,C確認，即不滿足被多數派確認，是不會應答給業務成功的，最終會以超時的錯誤返回給業務。如果A機器無法恢復，這時新加入節點會通過物理拷貝方式最快速度“克隆”出一個備節點繼續代替A節點提供服務。

Q：Shard版本的可以通過pt工具，或者gh-ost加欄位不？會有什麼限制不？

A：TDSQL管理臺提供online ddl的功能，會自動對多分片做原子性變更，不需要業務再用第三方工具；分散式TDSQL在做DDL的時候不允許調整shardkey欄位，比如原來以id作為shardkey，現在要調整成name作為shardkey，這樣是不允許的。

Q：TDSQL Shard演算法有幾種？建表語句必須需要修改語法嗎？

A：TDSQL shard演算法對業務遮蔽，即基於MySQL分割槽表做的hash拆分（該演算法不允許使用者修改），這麼做也是為了對業務遮蔽TDSQL分表細節。這裡並不是限制使用者只能做基於hash的分割槽，使用者可以在TDSQL-shard的基礎上做二級分割槽（比如：按照日期、時間）。建表以及使用方面的語法，後面有一門關於分散式開發的課程，敬請期待。

Q：誰來解決zk的可靠性？

A：一方面，zk自身做了高可用跨機房部署，同時奇數個zk部署當發生故障時只要剩餘存活zk數量大於叢集zk的一半，zk就可以繼續提供服務；另外一方面，就算zk節點全部當機，各個模組自身對zk也不是強依賴的，即zk在不工作的情況下，資料庫例項的正常讀寫請求不會受到任何影響，只是不能處理切換、擴容等排程相關的觸發式操作。

Q：老師剛才講兩種模式，如果是用Shard模式，應用層對Sql語法有要求？是我聽錯了嗎？ 

A：相容MySQL 99%的SQL語法，shard模式與noshard模式最主要的區別是shardkey的引入。引入shardkey之後，為了發揮出shard模式下的效能優勢，建議所有sql都帶shardkey訪問，同時在shard模式下，一些資料庫的高階特性如：儲存過程、觸發器、檢視等特性會受到一定的使用限制。更詳細的內容後面會有專門的分散式開發的課程會專門介紹。

Q：分支到總行資料同步彙總，Oralce 同步到TDSQL是雙向都支援麼？

A：支援雙向同步。這裡的支援是有條件的，從TDSQL到Oracle是可以做到準實時同步，但是從Oracle到TDSQL目前還無法做到準實時同步，後續會支援。

Q：分散式表和非分散式表如何做join？

A：分散式TDSQL下存在兩種表分別是大表和小表，大表就是shard表（分散式表），小表又叫廣播表，會冗餘到所有資料節點上。分散式表和非分散式表做join時，由於分散式表所在的物理節點上存在非分散式表的一份冗餘，因而可以在單個資料節點上完成join。

Q：是否支援自建私有云？如果公有云，成本會不會上升？

A：支援私有云的，TDSQL大部分的銀行客戶都是採用私有云部署模式，並和外網隔離。公有云的成本相比私有云明顯是前者更低，像私有云需要自建機房，搭建光纖裝置，但是好處是獨佔物理硬體資源。公有云的話都是和公有云上的其他使用者公用一套IDC、網路環境。

Q：是否支援K8S部署？

A：TDSQL自帶了一鍵部署解決方案，不依賴K8S。

Q：分局分表支援大表關聯查詢嗎？

A：支援的