同城雙中心自适應同步方案 —— DR Auto-Sync 詳解

作者：Gin​

一、使用者手冊

​​同城兩中心自适應同步模式部署 | PingCAP Docs​​

二、原生 Raft 的限制

1. Raft

Raft 是一種分布式共識算法，在 TiDB 叢集的多種元件中，PD 和 TiKV 都通過 Raft 實作了資料的容災。Raft 的災難恢複能力通過如下機制實作：

• Raft 成員的本質是日志複制和狀态機。Raft 成員之間通過複制日志來實作資料同步；Raft 成員在不同條件下切換自己的成員狀态，其目标是選出 leader 以提供對外服務。
• Raft 是一個表決系統，它遵循多數派協定，在一個 Raft Group 中，某成員獲得大多數投票，它的成員狀态就會轉變為 leader。也就是說，當一個 Raft Group 還保有大多數節點（majority）時，它就能夠選出 leader 以提供對外服務。

1. 副本數目的選擇

Raft 算法本身并沒有限制一個 Raft 組的成員（即副本）的數目，這個成員數可以為任意正整數，當成員數為 n 的時候，一個 Raft 組的可靠性如下：

• 若 n 為奇數，該 Raft 組可以容忍 (n-1)/2 個成員同時發生故障
• 若 n 為偶數，該 Raft 組可以容忍 n/2 -1 個成員同時發生故障

在一般情況下，通常将 Raft 組的成員數設定為奇數，其原因如下：

• 避免造成存儲空間的浪費：三成員可以容忍 1 成員故障，增加 1 個成員變為 4 成員後，也隻能容忍 1 成員故障，容災能力維持不變。
• 當成員數為偶數時，如果發生了一個網絡隔離，剛好将隔離開的兩側的成員數劃分為兩個 n/2 成員的話，由于兩側都得不到大多數成員，是以都無法選出領袖提供服務，這個網絡隔離将直接導緻整體的服務不可用。
• 當成員數為奇數時，如果發生了一個網絡隔離，網絡隔離的兩側中總有一側能分到大多數的成員，可以選出領袖繼續提供服務。

1. 原生 Raft 的限制

遵循 Raft 可靠性的特點，放到現實場景中：

• 想克服任意 1 台伺服器的故障，應至少提供 3 台伺服器。
• 想克服任意 1 個機櫃的故障，應至少提供 3 個機櫃。
• 想克服任意 1 個資料中心（機房）的故障，應至少提供 3 個資料中心。
• 想應對任意 1 個城市的災難場景，應至少規劃 3 個城市用于部署。

可見，原生的 Raft 協定對于偶數可用區（AZ，Available Zone）的支援并不友好，3 可用區或許是最适合部署 Raft 的高可用及容災方案。而在現實情況中，大多數部署環境很少具備同城 3 可用區的條件。比如數字化程度非常高的銀行業，基于傳統單機系統點對點複制的特性，絕大多數銀行都隻建設了同城 2 可用區，兩地 3 可用區的基礎設施。

在同城雙可用區部署原生的 Raft，主、備可用區按 2:1 的比例來配置設定 3 個成員，由于網絡延遲的差異，災備可用區會存在異步複制的成員。當主可用區由于故障無法恢複時，災備可用區僅剩的 1 個成員是無法保障 CAP 中的一緻性的。

我們對 Raft 做了一些功能上的擴充，基于這個擴充它可以在一定程度上克服主可用區故障後使用災備可用區難以恢複一緻性資料的難題。

三、DR Auto-Sync 方案

DR（Disaster Recovery），代指同城容災資料中心，該方案用于應對上文所描述的 TiDB 同城雙中心部署，或同城雙中心+1個投票中心部署的需求。

DR Auto-Sync 是一種跨同城（網絡延遲<1.5ms）兩中心部署的單一叢集方案，即兩種資料中心隻部署一個 TiDB 叢集，兩中心間的資料同步通過叢集自身内部（Raft 協定）完成。兩中心可同時對外進行讀寫服務，任意中心發生故障不影響資料一緻性。

為了解決 Raft 天生對于雙中心支援的不友好，我們對 TiKV 中的 Raft 以及 PD 的排程能力都做出了大幅加強。

圖 1

如圖所示，為了獲得網絡發生隔離後的自動恢複能力，本方案采用奇數副本進行部署，這裡以 3 副本進行舉例，TiKV 和 PD 的 3 個副本都按照主備機房 2:1 的比例進行資源配置設定，而 TiDB 可以在兩中心部署任意多個來獲得兩中心雙活的能力。

從圖中可以看到，本方案與原生 Raft 方案不同的是，TiKV 上增加了 Primary/DR 的位置屬性，用來讓 PD 感覺到各個 TiKV 所在的機房資訊。同時對 TiKV 中的 Raft 做出了加強，使其根據 PD 下發的同步狀态要求，自動的在同步複制和異步複制之間轉換。

使用之前，請確定已對做了妥善的 TiKV Label 規劃。關于 Label 的設計，請參考以下的文章：

​​TiDB 叢集的可用性詳解及 TiKV Label 規劃 - 技術文章 / 原了解讀 - AskTUG​​

1. 同步狀态

我們定義了三種狀态來控制和标示叢集的同步狀态，該狀态限制了 TiKV 的複制方式：

• sync：同步複制，此時 DR 與 Primary 至少有一個節點與 Primary 同步，Raft 保證每條 log 按 label 同步複制到 DR
• async：異步複制，此時不保證 DR 與 Primary 完全同步，Raft 使用經典的 majority 方式複制 log
• sync-recover：恢複同步，此時不保證 DR 與 Primary 完全同步，Raft 逐漸切換成 label 複制，切換成功後彙報給 PD

1. 狀态轉換

簡單來講，叢集的複制模式可以自動在三種狀态之間自适應的切換：

• 當叢集一切正常時，會進入同步複制模式來最大化的保障災備機房的資料完整性
• 當機房間網絡斷連或災備機房發生整體故障時，在經過一段提前設定好的保護視窗之後，叢集會進入異步複制狀态，來保障業務的可用性
• 當網絡重連或災備機房整體恢複之後，災備機房的 TiKV 會重新加入到叢集，逐漸同步資料并最終轉為同步複制模式
• 當主機房整體故障且無法恢複時，使用災備機房的副本來恢複一緻性的資料。

狀态轉換的細節過程如下：

初始化

叢集在第一次啟動時是 sync 狀态，PD 會下發資訊給 TiKV，所有 TiKV 會嚴格按照 sync 模式的要求進行工作。

同步切異步

1. PD 通過定時檢查 TiKV 的心跳資訊來判斷 TiKV 是否當機 / 斷連
2. 如果當機數超過 Primary/DR 各自副本的數量，意味着無法完成同步複制了，需要切換狀态
3. PD 将 async 狀态下發到所有 TiKV
4. TiKV 的複制方式由雙中心同步方式轉為原生的 Raft 大多數落實方式。

異步切同步

1. PD 通過定時檢查 TiKV 的心跳資訊來判斷 TiKV 是否恢複連接配接
2. 如果當機數小于 Primary/DR 各自副本的數量，意味着可以切回同步了
3. PD 将 sync-recover 狀态下發給所有 TiKV
4. TiKV 的所有 region 逐漸切換成雙機房同步複制模式，切換成功後狀态通過心跳同步資訊給 PD
5. PD 記錄 TiKV 上 region 的狀态并統計恢複進度
6. A) 所有 Regoin 都恢複後，PD 将狀态切換為 sync，将 sync 狀态下發給所有 TiKV

B) 如果在過程中又發生當機，執行同步切異步流程

PD 在整個過程中扮演了極為重要的角色，在雙中心同步複制方案中幾乎所有的配置都在 PD 中完成，包括 Label 設定，Primary/DR 角色配置，阻塞視窗 wait-store-timeout 的配置等。為了有效的在分布式系統中表示目前的同步狀态，PD 在向 TiKV 下發狀态的同時會繞過原生的 Raft 通過一個新的接口将目前的複制模式同步的寫入所有的 PD 磁盤中，這是為了當 PD leader 出現當機時，使用者可以準确的擷取目前的複制模式。

3. RPO & RTO

RPO=0

排除同步轉異步，降級以提供服務之後繼而發生主機房整體故障的情況。

RTO 在不同的場景下的計算方法：

• 兩機房網絡斷開時長小于 wait-store-timeout 所設定的時間時，RTO 為網絡斷開時間和 30s（基于預設的 Raft 心跳設定）中更大的那個。
• 兩機房網絡斷開或災備機房整體當機時，RTO 為阻塞視窗 wait-store-timeout 所設定的時間。
• 主機房整體當機時，RTO 為報警響應時間 + 重建 PD 操作時間（熟練 DBA 分鐘級） + 恢複 TiKV 單副本時間（熟練 DBA 分鐘級）+ 叢集驗證時間（用于驗證資料庫可用，應用連接配接順暢），恢複後的單副本叢集可以直接提供服務，後續的擴容以及擴副本操作可以線上執行。

4. 産品限制（5.2.x）

1. 同城災備中心故障觸發 TiDB 進入保護視窗 （預設配置 60s），保護視窗内會禁止使用者請求。保護視窗結束之後由雙中心由同步複制轉為異步複制，主中心抛棄災備中心獨立運轉。
2. 主中心進入異步複制狀态後叢集總計算能力下降，叢集存儲容量不變，容災能力由可容忍一副本故障變為不能容忍副本故障。
3. 主中心進入異步複制狀态之後，叢集不會主動補全副本到 3 副本狀态，如果使用者需要補全到三副本叢集，需要解除 DR Auto-sync 的相關配置，這樣做的代價是當災備中心恢複連接配接後，需要重新配置為 DR Auto-sync 排程政策。
4. 在主中心故障的場景中，需要通過狀态标記檔案确認災備中心的副本處于同步複制狀态還是異步複制狀态。隻有同步複制狀态下的災備副本才能恢複一緻性的資料。

5. 該方案無法應對接連發生的災難場景，如：

   雙中心之間網絡斷開時間超過保護視窗（預設配置 60s），即主中心副本進入異步複制狀态，繼而發生了主中心故障引起主中心資料副本丢失或損壞。在這種場景下，無法依賴災備中心的副本進行資料恢複。

6. 當主中心故障後，使用災備中心的少數副本重建叢集，此時的叢集并不是 DR Auto-Sync 架構，而是一個 n 副本的應急叢集（副本數 n 取決于起初配置設定給災備中心的副本數）。待恢複服務後，需要補充伺服器資源，以線上擴容的方式恢複到初始的副本數量。該操作不可逆，即使主中心後續被修複，也隻能以空白伺服器的角色加入叢集，通過線上重平衡等操作最終恢複到原本的 DR Auto-Sync 架構

5. 産品演進計劃

DR Auto-Sync 正處在高速疊代的周期中，後續版本将會有一系列高可用和容災能力的加強。如下圖，從 5.3.0 開始将支援雙中心對等部署，藉此獲得快速恢複多副本的能力：

圖 2

四、原了解讀

為了解決分布式共識算法天生在雙可用區（AZ）部署時容災能力的缺陷，我們對分布式共識算法做了加強。

為了獲得發生網絡隔離故障後的自動恢複能力，需要選用奇數個成員，我們以雙可用區部署 7 成員的 Raft 為例來說明這個技術方案。

圖 3

如圖 1 所示，一般的共識算法通過大多數成員（majority）來實作唯一修改送出并且容忍少數副本（minority）丢失。但是在跨雙可用區的情況下，奇數成員的 majority 不一定能容忍可用區損壞。

核心技術 1 —— commit group

與原生 Raft 不同，我們給 Raft 成員增加了送出組（commit group）的概念。每個成員會配置設定在最多一個組（group）裡。在進行日志送出時，除了要滿足多數派的前提，還需要滿足日志複制到至少兩個不同的組裡。多數派的前提保證了正确性；至少兩個不同組保證了資料的安全。

送出組是可以運作時動态開關的。當要進行同步複制時，開啟送出組，保證資料安全；當要切換成異步複制時，關閉送出組，保證可用性。而送出組的劃分與 Raft 解偶，由上層指定。在本方案裡，劃分方式根據地理位置屬性決定。

圖 4

如圖 2 所示，0、1、2、5 可以湊成大多數成員（majority），但是一旦 AZ 0 整個可用區損壞以後，最新的修改也将丢失。送出組将成員按照一定的規則給組織起來，分成不同的組。并且規定修改必須滿足大多數成員落實，且複制到至少兩個組才能送出。在這種情況下，上述 0、1、2、5 就不是一個符合要求的成員組合。雖然這個組合能滿足大多數成員落實，但這個組合隻包含了一個組 AZ 0。

圖 5

如圖 3 所示，圖中的 0、1、2、6 就是一個合格的組合。它一共包含 4 個成員，滿足了大多數成員落實的要求；這四個成員分布在兩個不同的組 AZ 0、AZ 1 中，是以它是一個符合要求的組合。

核心技術 2 —— 保障同步複制的請求阻塞視窗

阻塞視窗用于在發生雙可用區通信故障時，在一個預先設定的時間内，通過阻塞新請求的送出來保持雙可用區同步複制模式。

• 當阻塞視窗設定為 0 時，兩個可用區将保持在異步複制狀态。
• 當阻塞視窗設定為 1 分鐘時，網絡斷連或災備可用區發生整體故障的最初 1 分鐘内，主可用區會自動阻塞新的請求，來保障雙可用區複制的同步性。
• 當阻塞視窗設定為一個足夠大的時間時（如 1 年），網絡斷連或災備可用區發生整體故障的 1 年内，都會阻塞新的請求，在實際使用中可以認為雙可用區處于持久的同步複制狀态。

核心技術 3 —— 自适應複制狀态切換

圖 6

1. 同步狀态說明

• 同步複制狀态：即圖中“雙可用區同步模式”，此時 Raft 在送出組（commit group）模式下工作，以確定災備可用區具備同步（RPO=0）的資料；
• 異步複制狀态：即圖中“大多數成員模式”，此時采用經典的 Raft 大多數成員（majority ）模式做複制，不保證災備可用區具備同步的資料；
• 恢複同步狀态：即圖中“恢複同步模式”，此時逐漸追平資料，追數過程中不保證災備可用區具備同步的資料。

1. 狀态轉換說明

• 當叢集一切正常時，會轉換為同步複制狀态來最大化保障災備可用區的資料完整性；
• 當兩個可用區間的網絡斷連或災備可用區發生整體故障時，在經過一段提前設定好的阻塞視窗之後，叢集會進入異步複制狀态，來保障業務的可用性
• 當網絡重連或災備可用區整體恢複之後，災備可用區的成員會重新加入到叢集，逐漸同步資料并最終轉為同步複制模式；
• 當主可用區整體故障且無法恢複時，使用災備可用區的成員來恢複一緻性的資料。