數據庫｜TiDB多副本損壞，別著急！有損恢復幫你化險為夷！

本期摘要

在TiDB分布式數據庫中，采用多副本機制來確保數據的一致性和可用性。在正常情況下，即使一個副本發生故障，集群也能繼續提供服務。然而，當遭遇多個副本的損壞或丟失時，就需要考慮如何快速恢復數據并保證系統正常運行。

本文將重點介紹TiDB對多副本損壞或丟失的處理方法，并通過演示來說明如何應對這種情況，確保數據庫的可靠性和穩定性。

作者

高文鋒 |后端開發工程師

神州數碼云基地TiDB團隊成員

01

前言

TiDB分布式數據庫采用多副本機制，數據副本通過 Multi-Raft 協議同步事務日志，確保數據強一致性且少數副本發生故障時不影響數據的可用性。在三副本情況下，單副本損壞可以說對集群沒什么影響，但當遇到多副本損壞的損壞丟失的時候，如何快速恢復也是DBA需要面對的問題，本次主要講述對TiDB對多副本損壞丟失的處理方法。

02

TiDB數據庫的存儲架構

TiDB Server：SQL 層，對外暴露 MySQL 協議的連接 endpoint，負責接受客戶端的連接，執行 SQL 解析和優化，最終生成分布式執行計劃。TiDB 層本身是無狀態的，實踐中可以啟動多個 TiDB 實例，通過負載均衡組件（如 LVS、HAProxy 或 F5）對外提供統一的接入地址，客戶端的連接可以均勻地分攤在多個 TiDB 實例上以達到負載均衡的效果。TiDB Server 本身并不存儲數據，只是解析 SQL，將實際的數據讀取請求轉發給底層的存儲節點 TiKV（或 TiFlash）。

PD (Placement Driver) Server：整個 TiDB 集群的元信息管理模塊，負責存儲每個 TiKV 節點實時的數據分布情況和集群的整體拓撲結構，提供 TiDB Dashboard 管控界面，并為分布式事務分配事務 ID。PD 不僅存儲元信息，同時還會根據 TiKV 節點實時上報的數據分布狀態，下發數據調度命令給具體的 TiKV 節點，可以說是整個集群的“大腦”。此外，PD 本身也是由至少 3 個節點構成，擁有高可用的能力。建議部署奇數個 PD 節點。

存儲節點TiKV Server：負責存儲數據，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range（從 StartKey 到 EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region。TiKV 的 API 在 KV 鍵值對層面提供對分布式事務的原生支持，默認提供了 SI (Snapshot Isolation) 的隔離級別，這也是 TiDB 在 SQL 層面支持分布式事務的核心。TiDB 的 SQL 層做完 SQL 解析后，會將 SQL 的執行計劃轉換為對 TiKV API 的實際調用。所以，數據都存儲在 TiKV 中。另外，TiKV 中的數據都會自動維護多副本（默認為三副本），天然支持高可用和自動故障轉移。

TiFlash：TiFlash 是一類特殊的存儲節點。和普通 TiKV 節點不一樣的是，在 TiFlash 內部，數據是以列式的形式進行存儲，主要的功能是為分析型的場景加速。

03

集群信息

一、Store情況

192.168.2.81:20160 ---> id=4

192.168.2.82:20160 ---> id=5

192.168.2.83:20160 ---> id=1

192.168.2.81:20161 ---> id=6247

192.168.2.82:20161 ---> id=6246

192.168.2.83:20161 ---> id=6248

二、測試表db 1.sbtest 1的region分布情況

查看各4個region的分布情況

Region 5037 ---> leader:4 follower:1,5

Region 5015 ---> leader:6247 follower:1,4

Region 5029 ---> leader:6248 follower:4,6246

Region 6001 ---> leader:4 follower:1,6246

三、模擬tikv出現故障

當模擬192.168.2.81:20160和192.1-68.2.83:20160出現故障時，即store id為1和4時，Region 5037，Region 5015，Region 6001將同時失去兩個副本，包括leader和follower副本。

考慮到當前環境是虛擬機多實例環境，我們需要通過關閉系統服務的自動拉起功能來模擬tikv故障環境。

具體操作如下：

打開文件/etc/systemd/system/tikv-20160.service。

將Restart的值修改為no，原來默認是always，即總是拉起服務的意思，改為no后，服務掛掉后不會自動拉起。

使修改生效，執行命令systemctl daemon-reload。

殺掉192.168.2.81:20160和192.168.2.83:20160進程

查看集群狀態，192.168.2.81:20160和192.168.2.83:20160出現Disconnected

這時候查看db1.sbtest1的表，出現tikv超時

使用 pd-ctl 檢查大于等于一半副本數在故障節點上的 Region，并記錄它們的 ID（故障節點為store id 1，4）

db1.sbtest1表上面包含這3個region

{"id":5015,"peer_stores":[4,1,6247]}

{"id":5037,"peer_stores":[4,1,5]}

{"id":6001,"peer_stores":[4,1,6246]}

四、有損不安全恢復

現在由于三副本已損壞大于等于一半副本數的region,此時對應表訪問不了，這時通過有損恢復，但無法保證數據索引一致性和事務完整性。

在使用 Online Unsafe Recovery 功能進行數據有損恢復前，請確認以下事項：

離線節點導致部分數據確實不可用。

離線節點確實無法自動恢復或重啟。

檢查數據索引一致性

#若結果有不一致的索引，可以通過重命名舊索引、創建新索引，然后再刪除舊索引的步驟來修復數據索引不一致的問題

通過有損修復后，數據表可恢復讀寫

04

總結

1.在TiDB中，根據用戶定義的多種副本規則，一份數據可以同時存儲在多個節點中，這樣可以確保在單個或少數節點暫時離線或損壞時，讀寫數據不會受到任何影響。然而，當一個Region的多數或全部副本在短時間內全部下線時，該Region將變為暫時不可用的狀態，無法進行讀寫操作。

2.一旦執行了unsafe recovery，所指定的節點將被設為 Tombstone 狀態，不再允許啟動，執行過程中，所有調度以及 split/merge 都會被暫停，待恢復成功或失敗后自動恢復

“

Hello~

這里是神州數碼云基地編程大法，技術前沿，盡在其中超多原創技術干貨持續輸出ing~

想要第一時間獲取超硬技術干貨快快點擊關注+設為星標★

拜托拜托啦

這對“我們”都很重要哦~

- END -

往期精選

從源碼分析TiUP如何判斷TiDB集群狀態

TiDB災備切換實踐-部署

TiDB 數據庫大版本升級-基于TiCDC異機升級

了解云基地，就現在！

南京兆柏數據恢復中心 南京兆柏數據恢復中心