數(shù)據(jù)庫(kù)｜TiDB多副本損壞，別著急！有損恢復(fù)幫你化險(xiǎn)為夷！

本期摘要

在TiDB分布式數(shù)據(jù)庫(kù)中，采用多副本機(jī)制來(lái)確保數(shù)據(jù)的一致性和可用性。在正常情況下，即使一個(gè)副本發(fā)生故障，集群也能繼續(xù)提供服務(wù)。然而，當(dāng)遭遇多個(gè)副本的損壞或丟失時(shí)，就需要考慮如何快速恢復(fù)數(shù)據(jù)并保證系統(tǒng)正常運(yùn)行。

本文將重點(diǎn)介紹TiDB對(duì)多副本損壞或丟失的處理方法，并通過(guò)演示來(lái)說(shuō)明如何應(yīng)對(duì)這種情況，確保數(shù)據(jù)庫(kù)的可靠性和穩(wěn)定性。

作者

高文鋒 |后端開(kāi)發(fā)工程師

神州數(shù)碼云基地TiDB團(tuán)隊(duì)成員

01

前言

TiDB分布式數(shù)據(jù)庫(kù)采用多副本機(jī)制，數(shù)據(jù)副本通過(guò) Multi-Raft 協(xié)議同步事務(wù)日志，確保數(shù)據(jù)強(qiáng)一致性且少數(shù)副本發(fā)生故障時(shí)不影響數(shù)據(jù)的可用性。在三副本情況下，單副本損壞可以說(shuō)對(duì)集群沒(méi)什么影響，但當(dāng)遇到多副本損壞的損壞丟失的時(shí)候，如何快速恢復(fù)也是DBA需要面對(duì)的問(wèn)題，本次主要講述對(duì)TiDB對(duì)多副本損壞丟失的處理方法。

02

TiDB數(shù)據(jù)庫(kù)的存儲(chǔ)架構(gòu)

TiDB Server：SQL 層，對(duì)外暴露 MySQL 協(xié)議的連接 endpoint，負(fù)責(zé)接受客戶端的連接，執(zhí)行 SQL 解析和優(yōu)化，最終生成分布式執(zhí)行計(jì)劃。TiDB 層本身是無(wú)狀態(tài)的，實(shí)踐中可以啟動(dòng)多個(gè) TiDB 實(shí)例，通過(guò)負(fù)載均衡組件（如 LVS、HAProxy 或 F5）對(duì)外提供統(tǒng)一的接入地址，客戶端的連接可以均勻地分?jǐn)傇诙鄠€(gè) TiDB 實(shí)例上以達(dá)到負(fù)載均衡的效果。TiDB Server 本身并不存儲(chǔ)數(shù)據(jù)，只是解析 SQL，將實(shí)際的數(shù)據(jù)讀取請(qǐng)求轉(zhuǎn)發(fā)給底層的存儲(chǔ)節(jié)點(diǎn) TiKV（或 TiFlash）。

PD (Placement Driver) Server：整個(gè) TiDB 集群的元信息管理模塊，負(fù)責(zé)存儲(chǔ)每個(gè) TiKV 節(jié)點(diǎn)實(shí)時(shí)的數(shù)據(jù)分布情況和集群的整體拓?fù)浣Y(jié)構(gòu)，提供 TiDB Dashboard 管控界面，并為分布式事務(wù)分配事務(wù) ID。PD 不僅存儲(chǔ)元信息，同時(shí)還會(huì)根據(jù) TiKV 節(jié)點(diǎn)實(shí)時(shí)上報(bào)的數(shù)據(jù)分布狀態(tài)，下發(fā)數(shù)據(jù)調(diào)度命令給具體的 TiKV 節(jié)點(diǎn)，可以說(shuō)是整個(gè)集群的“大腦”。此外，PD 本身也是由至少 3 個(gè)節(jié)點(diǎn)構(gòu)成，擁有高可用的能力。建議部署奇數(shù)個(gè) PD 節(jié)點(diǎn)。

存儲(chǔ)節(jié)點(diǎn)TiKV Server：負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，從外部看 TiKV 是一個(gè)分布式的提供事務(wù)的 Key-Value 存儲(chǔ)引擎。存儲(chǔ)數(shù)據(jù)的基本單位是 Region，每個(gè) Region 負(fù)責(zé)存儲(chǔ)一個(gè) Key Range（從 StartKey 到 EndKey 的左閉右開(kāi)區(qū)間）的數(shù)據(jù)，每個(gè) TiKV 節(jié)點(diǎn)會(huì)負(fù)責(zé)多個(gè) Region。TiKV 的 API 在 KV 鍵值對(duì)層面提供對(duì)分布式事務(wù)的原生支持，默認(rèn)提供了 SI (Snapshot Isolation) 的隔離級(jí)別，這也是 TiDB 在 SQL 層面支持分布式事務(wù)的核心。TiDB 的 SQL 層做完 SQL 解析后，會(huì)將 SQL 的執(zhí)行計(jì)劃轉(zhuǎn)換為對(duì) TiKV API 的實(shí)際調(diào)用。所以，數(shù)據(jù)都存儲(chǔ)在 TiKV 中。另外，TiKV 中的數(shù)據(jù)都會(huì)自動(dòng)維護(hù)多副本（默認(rèn)為三副本），天然支持高可用和自動(dòng)故障轉(zhuǎn)移。

TiFlash：TiFlash 是一類特殊的存儲(chǔ)節(jié)點(diǎn)。和普通 TiKV 節(jié)點(diǎn)不一樣的是，在 TiFlash 內(nèi)部，數(shù)據(jù)是以列式的形式進(jìn)行存儲(chǔ)，主要的功能是為分析型的場(chǎng)景加速。

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

二、測(cè)試表db 1.sbtest 1的region分布情況

查看各4個(gè)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出現(xiàn)故障

當(dāng)模擬192.168.2.81:20160和192.1-68.2.83:20160出現(xiàn)故障時(shí)，即store id為1和4時(shí)，Region 5037，Region 5015，Region 6001將同時(shí)失去兩個(gè)副本，包括leader和follower副本。

考慮到當(dāng)前環(huán)境是虛擬機(jī)多實(shí)例環(huán)境，我們需要通過(guò)關(guān)閉系統(tǒng)服務(wù)的自動(dòng)拉起功能來(lái)模擬tikv故障環(huán)境。

具體操作如下：

打開(kāi)文件/etc/systemd/system/tikv-20160.service。

將Restart的值修改為no，原來(lái)默認(rèn)是always，即總是拉起服務(wù)的意思，改為no后，服務(wù)掛掉后不會(huì)自動(dòng)拉起。

使修改生效，執(zhí)行命令systemctl daemon-reload。

殺掉192.168.2.81:20160和192.168.2.83:20160進(jìn)程

查看集群狀態(tài)，192.168.2.81:20160和192.168.2.83:20160出現(xiàn)Disconnected

這時(shí)候查看db1.sbtest1的表，出現(xiàn)tikv超時(shí)

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

db1.sbtest1表上面包含這3個(gè)region

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

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

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

四、有損不安全恢復(fù)

現(xiàn)在由于三副本已損壞大于等于一半副本數(shù)的region,此時(shí)對(duì)應(yīng)表訪問(wèn)不了，這時(shí)通過(guò)有損恢復(fù)，但無(wú)法保證數(shù)據(jù)索引一致性和事務(wù)完整性。

在使用 Online Unsafe Recovery 功能進(jìn)行數(shù)據(jù)有損恢復(fù)前，請(qǐng)確認(rèn)以下事項(xiàng)：

離線節(jié)點(diǎn)導(dǎo)致部分?jǐn)?shù)據(jù)確實(shí)不可用。

離線節(jié)點(diǎn)確實(shí)無(wú)法自動(dòng)恢復(fù)或重啟。

檢查數(shù)據(jù)索引一致性

#若結(jié)果有不一致的索引，可以通過(guò)重命名舊索引、創(chuàng)建新索引，然后再刪除舊索引的步驟來(lái)修復(fù)數(shù)據(jù)索引不一致的問(wèn)題

通過(guò)有損修復(fù)后，數(shù)據(jù)表可恢復(fù)讀寫(xiě)

04

總結(jié)

1.在TiDB中，根據(jù)用戶定義的多種副本規(guī)則，一份數(shù)據(jù)可以同時(shí)存儲(chǔ)在多個(gè)節(jié)點(diǎn)中，這樣可以確保在單個(gè)或少數(shù)節(jié)點(diǎn)暫時(shí)離線或損壞時(shí)，讀寫(xiě)數(shù)據(jù)不會(huì)受到任何影響。然而，當(dāng)一個(gè)Region的多數(shù)或全部副本在短時(shí)間內(nèi)全部下線時(shí)，該Region將變?yōu)闀簳r(shí)不可用的狀態(tài)，無(wú)法進(jìn)行讀寫(xiě)操作。

2.一旦執(zhí)行了unsafe recovery，所指定的節(jié)點(diǎn)將被設(shè)為 Tombstone 狀態(tài)，不再允許啟動(dòng)，執(zhí)行過(guò)程中，所有調(diào)度以及 split/merge 都會(huì)被暫停，待恢復(fù)成功或失敗后自動(dòng)恢復(fù)

“

Hello~

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

想要第一時(shí)間獲取超硬技術(shù)干貨快快點(diǎn)擊關(guān)注+設(shè)為星標(biāo)★

拜托拜托啦

這對(duì)“我們”都很重要哦~

- END -

往期精選

從源碼分析TiUP如何判斷TiDB集群狀態(tài)

TiDB災(zāi)備切換實(shí)踐-部署

TiDB 數(shù)據(jù)庫(kù)大版本升級(jí)-基于TiCDC異機(jī)升級(jí)

了解云基地，就現(xiàn)在！

南京兆柏數(shù)據(jù)恢復(fù)中心 南京兆柏?cái)?shù)據(jù)恢復(fù)中心