作者：劉強
v5.0.1 版本tidb 叢集故障演練
參考文章:
Tidb災難恢複演練-多副本丢失 運維實戰
資料庫是每個公司的重中之重，它往往存儲了公司的核心資料，一旦出現永久性損壞，對公司的打擊會是災難性的。分布式資料庫雖然采用資料多副本備份機制來保證資料的可靠性，但同樣也會面臨多副本丢失的風險。災難出現如何快速恢複也是DBA需要面對的問題，本案通過對具體示例的了解與操作介紹了分布式NEWSQL資料庫Tidb對多副本丢失問題的處理。 一、TiDB 的整體架構: TiDB 叢集主要包括三個核心元件：T…
\
一篇文章帶你玩轉 TiDB 災難恢複 運維實戰
一篇文章帶你玩轉TiDB災難恢複 一、背景 高可用是 TiDB 的另一大特點，TiDB/TiKV/PD 這三個元件都能容忍部分執行個體失效，不影響整個叢集的可用性。下面分别說明這三個元件的可用性、單個執行個體失效後的後果以及如何恢複。 TiDB TiDB 是無狀态的，推薦至少部署兩個執行個體，前端通過負載均衡元件對外提供服務。當單個執行個體失效時，會影響正在這個執行個體上進行的 Session，從應用的角度看，會…
https://docs.pingcap.com/zh/tidb/stable/tikv-control
演練背景&目标: 目的是打造雙雲機房部署tidb 叢集，在主機房故障時可以緊急使用少數的pd 節點和tikv 節點恢複服務 pd 節點的演練文檔: 使用pd-recover 恢複pd 多數節點故障的場景
測試環境部署資訊:
A,B 兩個機房: 所有的region 的leader 排程到A 機房
使用label 标簽保證B 機房的那個tikv 節點擁有完整的資料副本
1.設定标簽(如果之前是單機房可通過如下設定新的标簽)
» config set location-labels dc,host
» store label 4 dc bjtx
» store label 24045 dc bjtx
» store label 1001 dc bjtx
» store label 22508 dc bjbd
-- 檢視store 基本資訊
» store --jq=".stores[].store |{id,address,state_name,labels}"
{"id":24045,"address":"172.29.238.197:20174","state_name":"Up","labels":[{"key":"host","value":"tikv4"},{"key":"dc","value":"bjtx"}]}
{"id":4,"address":"172.29.238.238:20174","state_name":"Up","labels":[{"key":"host","value":"tikv1"},{"key":"dc","value":"bjtx"}]}
{"id":1001,"address":"172.29.238.146:20174","state_name":"Up","labels":[{"key":"host","value":"tikv1"},{"key":"dc","value":"bjtx"}]}
{"id":22508,"address":"192.168.149.156:20174","state_name":"Up","labels":[{"key":"host","value":"tikv3"},{"key":"dc","value":"bjbd"}]} 2.使用pd-ctl 将所有region 的leader 排程到bjtx 機房，并通過監控确認所有的region leader 是否都排程到A 機房
» config show label-property
{}
» config set label-property reject-leader dc bjbd
Success!
» config show label-property
{
"reject-leader": [
{
"key": "dc",
"value": "bjbd"
}
]
}
-- 檢視bjbd機房是否包含了所有的region副本資料(保證在主機房挂掉後備用機房擁有完整的資料副本)
» region --jq=".regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(all(.!=22508))}" 模拟tikv 主機房故障(手動快速 kill 主機房的pd 節點以及tikv 節點，并mv 相關資料目錄)
pd 服務的恢複見上面連結。在pd 恢複服務之後,進行tikv 的恢複
1.使用tiup 關閉健康的tikv 節點192.168.149.156:20174
2.使用tikv-ctl 對所有 Region 移除掉所有位于故障節點上的 Peer
bin/tiup ctl tikv --db /data/tidb/data/tikv-20174/db unsafe-recover remove-fail-stores -s 24045,4,1001 --all-regions
removing stores [24045, 4, 1001] from configurations...
success
-- 注意此操作需要在每一個健康的tikv 節點上執行該指令。是以需要在每個tikv 節點上部署tikv-ctl 工具 a. 此時reload pd,tikv 是失敗的(報錯如下圖)
b.使用scale-in 操作下線故障的tikv 節點,叢集整體狀态大緻如下圖所示。此時reload pd,tikv 還是失敗的\
c.使用–force 強制下線故障的tikv 節點(3個)
bin/tiup cluster scale-in tidb-louis_cluster -N 172.29.238.146:20174 --force
...... 3.reload pd,tikv
bin/tiup cluster reload tidb-louis_cluster -R=pd,tikv 再次檢視監控大盤如下\