摘要：臨近年中，銀行重要系統(tǒng)的建設進入投產(chǎn)沖刺階段，本次上線又有多個系統(tǒng)對接，為了優(yōu)化集群資源分配，引發(fā)了這次分享的主題線上系統(tǒng)的縮容的遷移，本文主要針對本次的縮容遷移過程進行梳理總結。

作者：Dan
本文轉載自公眾號「白噪聲OG」。

經(jīng)歷了上禮拜漫長的上線周期，終于有時間總結一下期間發(fā)生的故事。TiDB 是一款非常優(yōu)秀的國產(chǎn)分布式 NewSQL 數(shù)據(jù)庫，因其支持水平擴展性、強一致性、高可用性，從 18 年 3 月起已在國內銀行的賬務、支付類核心系統(tǒng)得到應用。

臨近年中，銀行重要系統(tǒng)的建設進入投產(chǎn)沖刺階段，本次上線又有多個系統(tǒng)對接 TiDB，為了優(yōu)化集群資源分配，引發(fā)了這次分享的主題——線上系統(tǒng) TiKV 的縮容、region 的遷移，本文主要針對本次 TiKV 的縮容、遷移過程進行梳理總結。

TiDB 數(shù)據(jù)庫的擴容已在官方文檔進行了詳細的說明（https://pingcap.com/docs-cn/op-guide/horizontal-scale/）并被各路大咖廣泛提及，但縮容遷移并在銀行交易系統(tǒng)上的實踐卻少有分享，這也是本文的目的之一。

進入主題，先交代下環(huán)境，服務器集群采用 NVMe+SSD 的存儲方案構建了 16 個 TiKV 實例，作為重要的核心支付類系統(tǒng)，兩地三中心五副本不可少，每個 TiKV 上 8K+ 個 region。整個遷移過程歷時 5 個小時，過程中沒有停止系統(tǒng)對外服務，很是順滑平穩(wěn)。

接下來還是看一下遷移的過程：

（一） TiKV 采用 Raft 一致性算法保證副本強一致性，遷移過程本質上是擴容的逆過程，確定下線的 TiKV 打上 label 后，將 region 搬移到最終保留下來的 TiKV 上。

（二） 接下來聚焦 region 1 的 Raft Group，對其副本進行搬移，實際上所有 region 的數(shù)據(jù)是一樣的，只是在保留的 TiKV 內進行 region 數(shù)據(jù)的復制，新產(chǎn)生的副本由于數(shù)據(jù)不完整，作為 Raft Group 中的 learner。

（三） Learner 創(chuàng)建后，PD 會在這樣的一個 Raft Group（5 個全副本 region + 2 個 learner）中發(fā)起選舉：

選舉會增加 label 限制，確保 leader 最終在保留的 TiKV 中產(chǎn)生；

由于 learner 沒有投票權，選舉實際還是個 5 副本選主，多數(shù)派 (N+1)/2 仍為 3。

（四） 這樣新的 leader 選出來了，當兩個新副本數(shù)據(jù)追平后，將刪除下線 TiKV 中的 region。

（五） 這樣一個新的 5 副本 Raft Group 我們就獲得了。

這里再說幾點：

1. 磁盤 IO 對遷移的效率影響還是很大的，測試環(huán)境使用普通的 SAS 盤，在更高并發(fā)的條件下，耗時長了很多。

2.（二）、（三）、（四）的過程并非原子化操作，當然 learner 的數(shù)據(jù)本身也不具備一致性，但對 raft 的改造最終要保證一致性，與 PingCAP 的開發(fā)同學確認后，這些會在之后加入。

3. 我認為最有意思，也最有意義的一點，learner 的引入是本次遷移過程中非常巧妙的設計，解決了數(shù)據(jù)不一致副本在選舉過程中的尷尬地位，而 learner 也是 Multi-Raft 協(xié)議中的重要角色，HTAP 引擎 TiFlash&TiSpark 也以此引入列存副本，非常期待?TiDB 3.0。

PS：本次上線的重頭戲 Cloud TiDB 在平穩(wěn)運行后，希望有機會進行總結分享。TiDB 自上線后實現(xiàn)了多次重要變更操作，均未暫停系統(tǒng)對外服務，從一只開發(fā)狗的角度看 TiDB 在金融級 NewSQL 數(shù)據(jù)庫的方向上的確投入了很多。

最后，感謝 PingCAP Gin 同學和研發(fā)大神們的支持，感謝運維爸爸們直到凌晨 4 點的奮斗。