摘要：截至年底，貝殼金服業務已覆蓋全國多個城市及地區，為超過萬用戶提供了金融服務。老機房下線完成則表示數據遷移完成。機房遷移實施過程操作描述配置防火墻，將兩個機房所需端口開通。執行下線命令，一次性下線所有舊機房的。跨機房遷移，網絡延遲不能高于。

作者介紹 ：
李振環，貝殼金服數據基礎架構負責人，目前負責數據平臺和企業級數據倉庫開發。

貝殼金服是專注居住場景的金融科技服務商，起步于2006年成立的鏈家金融事業部，并于 2017年3月正式獨立運營。

貝殼金服聚焦于居住場景，在租賃、買賣、家裝、安居等場景中為用戶提供定制化的居住金融服務。貝殼金服以獨家大數據與場景風控能力見長，致力于解決居住金融需求，以Fintech驅動產業升級，讓每個家庭都能享受高品質的居住生活。

截至2018年底，貝殼金服業務已覆蓋全國90多個城市及地區，為超過130萬用戶提供了金融服務。

貝殼金服數據中臺使用 TiDB 和 TiSpark 平臺，基于 Syncer 將業務數據實時從 MySQL 備庫抽取到 TiDB 中，并通過 TiSpark 對 TiDB 中的數據進行數據分析處理，供上游業務消費，現已服務于 70 多名數據開發人員。現有集群已經使用 100 多個 Syncer 同步上游 MySQL 數據，目前已經達到 4.7TB 熱數據，上百張離線和實時報表。由于機房調整，數據中臺也需要同步遷移到新機房，結合 TiDB 的特性，我們探索了一種在線不停機遷移機房的方式。

TiDB 是一個分布式 NewSQL 數據庫。它支持水平彈性擴展、ACID 事務、MySQL 語法，具有數據強一致的高可用特性，是一個不僅適合 OLTP 場景還適合 OLAP 場景的混合數據庫。而 TiSpark 是為解決較重的 OLAP 需求而推出的產品。它借助 Spark 平臺，同時融合 TiKV 分布式集群的優勢，和 TiDB 一起為用戶一站式解決 HTAP 的業務需求。TiSpark 依賴于 TiKV 集群和 PD 組件，使用同一個數據源，減少對于 ETL 工具的維護，并且可以使用 Spark 進行復雜查詢計算。

由于原有 MySQL 數據庫提供服務非常吃力，使用 100 多個 Syncer 同步上游的 MySQL 數據，而 TiDB 作為一個數據中臺，主要使用 TiSpark 在做查詢。

本次數據遷移主要有兩個關鍵因素：

盡可能減少對業務的影響，業務方希望服務不能中斷超過 1 小時。

由于跨機房網絡帶寬有限，并且與線上業務共用跨機房網絡專線，在遷移過程中需要能控制遷移速度，在白天線上業務繁忙時以較慢的速度遷移，等到晚上業務空閑時加快遷移速度。另外網絡運維同事如果發現流量過載，為了不影響其他業務正常網絡資源使用，可能隨時限制正在遷移的網絡帶寬，切斷遷移網絡連接，因此遷移方案必須要支持“斷點續傳功能”。

本次遷移最初設想了三套方案（如下），最終通過技術考察和驗證，采用了技術上更有優勢的第三套方案。

方案一：只使用 Syncer 在新機房同步 ODS（Operational Data Store 操作性數據存儲）數據，然后從 ODS 數據再次全部計算 DW 和 ADM 層等數據。此方案需要遷移的數據最小，但是只從 ODS 計算出所有的其它數據是不現實的。其中很多拉鏈表（拉鏈表是數據倉庫的數據模型設計中常用的數據模式，該模型記錄歷史，通常記錄一個事務從開始，一直到當前狀態的所有變化的信息）的數據都是基于歷史時間點計算出來的結果，由于 TiDB 目前版本剛剛開始支持部分分區表功能，不能馬上用于生產。并且歷史數據沒有分區備份，歷史的拉鏈數據無法真實還原。另外此方案業務遷移成本也很高，兩邊需要不斷校準數據，查漏補缺，重新計算所有非 ODS 層數據計算量也過大，導致遷移時間和大量人力投入。

方案二：在某個時間點將老機房數據 Dump 出來，全量導入到新機房。之后再開啟 TiDB 集群的 Binlog 增量同步老集群數據，待新集群慢慢追上老集群之后再遷移業務。這個方案中 Dump 數據無法實現單庫 Dump。因為 Dump 出來的 Position 值不一樣，而且有的表沒有主鍵，多次導入會導致數據重復。因此全量 Dump 所有數據是一個很“重”的操作，Dump 后的大文件傳輸也存在無法斷點續傳的問題。具體存在問題如下：

鎖問題：全量備份時，需要對庫進行加鎖操作，如果數據量很大，備份時間較長，可能會影響業務。

備份失敗可能性較高：如果數據量較大，比如對 2T 的數據進行備份，可能會達到 3h 以上的備份時間，如果備份失敗，那么這次備份就相當于不可用。

Binlog 增量同步延遲問題：如果上游 MySQL 壓力較大，或者跨機房的網絡帶寬成為了瓶頸，那么增量同步可能追不上，Binlog 同步無法控制速度，斷點續傳也需要人工參與。

最終數據校驗任務較重：數據遷移完成之后，需要對上下游數據進行校驗，最簡單的方式是業務校驗和對比上下游標的行數。或者使用 pt-toolkit 工具進行數據校驗。

停業務風險：在機房遷移完成后，業務需要停止，等待同步和數據校驗完成才可以啟動。

方案三：采用 TiDB 原生的 Raft 三副本機制自動同步數據。在新機房添加 TiKV 節點，待數據均衡之后再下線老機房 TiKV 節點。老機房 TiKV 下線完成則表示數據遷移完成。此方案操作簡單，業務影響在分鐘級別。網絡層面可以通過 PD 調度參數控制 TiKV 遷移速度，Raft 副本遷移如果網絡中斷會自動重新傳輸。具體優點如下：

遷移數據期間不會影響線上業務，整個遷移過程都是在線提供服務的。

遷移效率非常高。一個機房內部 balance 3T 的數據只需要 10 小時左右，跨機房遷移一般受限于網絡。

容錯性高，沒有很多的人工干預，集群高可用依然保留。

操作描述：

配置防火墻，將兩個機房所需端口開通。

新機房擴容 3+ 個 TiKV，3 個 PD，2+ 個 TiDB。

執行下線 TiKV 命令，一次性下線所有舊機房的 TiKV。

PD Leader 手動切換到新機房，業務遷移到新機房，等待 TiKV balance 完成之后，下線舊機房的 TiKV、PD 和 TiDB。

整個過程人為操作較少，耗時較長的只有 TiKV balance 數據的過程，可以調整調度并發度來加速整個過程。

注意事項：

新機房的 TiKV 節點盡量要多于舊機房，否則在下線過程中，可能由于集群 TiKV 實例數比以前要少，導致 TiKV 壓力較大。

跨機房遷移，網絡延遲不能高于 3ms。

TiKV 下線過程中， Region Leader(s) 會逐漸遷移到新機房，這時業務已經可以并行的遷移，將壓力轉移到新機房去。

Syncer 二次開發：在貝殼金服，有 100 多個 Syncer 實時同步線上數據，由于 TiDB 語法與 MySQL 語法不是 100% 兼容，特別是上游修改 DDL 操作，比如從 INT 改成 VARCHAR，會導致 Syncer 同步失敗。在貝殼金服實戰中，優化了失敗恢復工作，監控程序會監控失敗原因并自動化恢復 Syncer 錯誤。

TiSpark 二次開發：TiSpark 無法實現 TiDB 數據插入和刪除。貝殼金服基于 TiSpark 二次開發封裝了 TiSpark，因此可以實現 TiSpark 直接原生 SparkSQL 執行 Insert 、Create 操作。實現新增 executeTidbSQL 實現 delete、update、drop 操作。增加 TiSpark View 的功能，彌補現階段 TiDB 不支持 View 的問題。

TiSpark 權限控制：TiDB 和 TiSpark 都無法實現基于組和大量用戶的權限控制。貝殼金服基于 Catalyst 自研了一套兼容 TiSpark SQL 和 TiDB SQL 的 SQL 解析引擎，并基于此引擎之上開發權限驗證、權限申請、權限審批、數據發現等功能。

Region 過多：由于 TiDB 目前版本暫不支持 Partition 功能，我們的 job 都是需要支持可以重復跑，因此有一些業務會直接先 drop table 然后再創建 table。默認情況下每次創建 table 都會申請一套 Region，導致現在單臺 TiKV Region 數過載。

DDL 排隊執行：有一次對一個 2 億級別的大表添加索引，希望提高基于時間查詢的效率，結果導致集群業務中所有 drop table 、create table 相關 job 全部卡住。最終了解到 DDL 是串行化操作。Add index 大操作讓其他 DDL 操作 pending，手動 kill add index 操作后集群恢復。目前 TiDB 2.1 版本已經將添加索引操作和其他的 DDL 操作分開，這個問題已經解決。

Syncer 恢復自動化：TiDB 現在對某些 alter column sql（字段從 INT 改為 VARCHAR 的跨類型修改操作）依然不兼容，因此在上游執行不兼容 SQL 之后，Syncer 同步會失敗。修復過程需要使用到 Syncer 同步 position，DB name，table name。獲取這些信息之后可以一個 shell 自動恢復 Syncer 同步，但是上面的三個信息輸出不夠友好，需要人為查看才能獲取到。如果在失敗 Syncer 日志中可以格式化輸出以上三個信息，Syncer 恢復可以更自動化。目前新版本的 Syncer 已經解決這個問題。

Decimal Hash Join 結果不正確：在使用兩個 Decimal 字段做表 join 時，發現使用 limit 可以查詢出來數據，不 limit 返回無結果。查看執行計劃發現 limit 之后改變了執行計劃，將 HashLeftJoin 改為了 IndexJoin。調查之后發現 Decimal 在計算 hash 值時返回結果不正確，導致相同 Decimal 無法 join 上。可以使用 hint 強制使用 IndexJoin 來解決此問題。目前 TiDB 2.0.11 及以上版本已經解決了這個問題。

列式存儲：由于現在 TiDB 是行存，即使是 TiSpark 讀取 TiDB 一個字段也會在底層取出此記錄所有值，導致性能問題。在 OLAP 大寬表場景中使用列式存儲性能會顯著提升。

機房順利遷移完成后，后續計劃升級到 TiDB 3.0，利用 TiDB 3.0 產品路線圖中提供的新功能來優化和提升使用效果：

開啟 Region merge 功能，自動在后臺合并空 Region 從而減少 Region 的數量。

使用 3.0 所提供的視圖 View 和分區 Partition 功能。

嘗試 PingCAP 新一代的列計算/存儲引擎 TiFlash ，提升 OLAP 寬表查詢性能。

此外，在應用 TiDB 支持業務的過程中，貝殼金服的技術團隊也通過自身對數據中臺的業務理解和技術實踐，打磨出了以下配套工具及平臺：

基于 TiDB 的數據發布平臺

基于 TiDB 的元數據管理平臺

支持 TiSpark+TiDB 的權限管理系統

基于 Flink + TiDB 的在線 SQL 流式處理平臺

在上面這些技術成果的基礎上，貝殼金服的技術團隊正在做未來的數據中臺技術棧演進規劃，即基于 TiDB + Azkaban + 自研的數據質量平臺。