接上回,我們開始對三副本丟失進行演練。
便于理解,先看表t_user新的region分布:
我們這次選擇宕掉Tikv2135、Tikv3136和Tikv4137,從分布圖可以判斷有兩region會丟失三副本,一個region丟失兩個副本,最后一個region丟失一個副本的情況。
同樣的先檢查宕機前測試表的狀況:
MySQL[sbtest2]> select count(*) from t_user;
+----------+
|count(*) |
+----------+
| 3000000 |
+----------+
1row in set (1.88 sec)
同時宕掉Tikv2135、Tikv3136和Tikv4137兩臺機器后測試表的情況:
MySQL[sbtest2]> select count(*) from t_user;
ERROR9005 (HY000): Region is unavailable
集群狀態:
檢查宕機的兩臺機器對應的store_id:
[root@tidb1bin]# /root/tidb-v4.0.0-linux-amd64/bin/pd-ctl -i -uhttp://172.16.134.133:2379
?store
這里是1,5,6
通過 pd-ctlconfig get 獲取region-schedule-limit、replica-schedule-limit、leader-schedule-limit、merge-schedule-limit并通過 pd-ctlconfig set 將這 4個參數設為 0
使用pd-ctl 檢查大于等于一半副本數在故障節點上的Region,并記錄它們的ID(故障節點為storeid 1,5,6):
? region --jq=".regions[] | {id: .id,peer_stores: [.peers[].store_id] | select(length as $total | map(if.==(1,5,6) then . else empty end) | length>=$total-length) }"
{"id":3089,"peer_stores":[5,4,6]}
{"id":47,"peer_stores":[4,5,6]}
{"id":75,"peer_stores":[4,5,6]}
{"id":30,"peer_stores":[6,4,5]}
{"id":135,"peer_stores":[6,4,5]}
{"id":4017,"peer_stores":[6,7,5]}
{"id":67,"peer_stores":[4,5,1]}
{"id":2289,"peer_stores":[4,6,5]}
{"id":18,"peer_stores":[6,4,5]}
{"id":39,"peer_stores":[6,4,5]}
{"id":51,"peer_stores":[4,6,5]}
{"id":10,"peer_stores":[4,5,6]}
{"id":14,"peer_stores":[6,5,4]}
{"id":83,"peer_stores":[6,4,5]}
{"id":59,"peer_stores":[6,4,5]}
{"id":6768,"peer_stores":[1,6,4]}
{"id":22,"peer_stores":[4,5,6]}
{"id":26,"peer_stores":[6,4,5]}
{"id":43,"peer_stores":[6,4,5]}
{"id":131,"peer_stores":[6,4,5]}
{"id":4009,"peer_stores":[6,1,5]}
{"id":2,"peer_stores":[7,6,5]}
{"id":63,"peer_stores":[4,5,1]}
{"id":87,"peer_stores":[6,4,5]}
{"id":6734,"peer_stores":[6,1,5]}
{"id":3080,"peer_stores":[6,4,5]}
{"id":3084,"peer_stores":[6,4,5]}
{"id":3076,"peer_stores":[6,4,5]}
{"id":34,"peer_stores":[6,4,5]}
{"id":127,"peer_stores":[6,4,5]}
{"id":3070,"peer_stores":[6,4,5]}
我們可以看到表的三個regionID均在列表中,另外的一個region由于只丟失一個副本,并未出現在列表中。
在剩余正常的kv節點上執行停Tikv的操作:
[root@tidb1bin]# tiup cluster stop tidb-test -R=tikv
在所有健康的節點上執行(操作需要確保健康的節點關閉了Tikv):
[root@tidb2 bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/dbunsafe-recover remove-fail-stores -s 1,5,6 --all-regions
removingstores [1, 5, 6] from configurations...
success
[root@tidb6bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/db unsafe-recoverremove-fail-stores -s 1,5,6 --all-regions
removingstores [1, 5, 6] from configurations...
success
停止PD節點:
[root@tidb1~]# tiup cluster stop tidb-test -R=pd
Startingcomponent `cluster`: /root/.tiup/component
重啟啟動PDtikv節點:
[root@tidb1~]# tiup cluster start tidb-test -R=pd,tikv
檢查沒有處于leader狀態的region(要保持沒有):
[root@tidb1~]# pd-ctl -i -u http://172.16.134.133:2379
?region --jq .regions[]|select(has("leader")|not)|{id:.id,peer_stores: [.peers[].store_id]}
{"id":4009,"peer_stores":[6,1,5]}
{"id":6734,"peer_stores":[6,1,5]}
?
這里沒有發現任然有兩個region處于沒有leader的狀態。另外丟失兩副本的一個region以及通過unsafe-recover的方式進行了復制。
嘗試訪問表t_user
MySQL[sbtest2]> select count(*) from t_user;
ERROR9002 (HY000): TiKV server timeout
或者
MySQL[sbtest2]> select count(*) from t_user;
ERROR9005 (HY000): Region is unavailable
兩次執行的結果有所不一樣。
根據regionID,確認region屬于哪張表,以備后續同步數據需要。
[root@tidb1~]# curl http://172.16.134.133:10080/regions/4009
{
"region_id": 4009,
"start_key": "dIAAAAAAAABN",
"end_key": "dIAAAAAAAABNX3KAAAAAAAt8fw==",
"frames": [
{
"db_name": "sbtest2",
"table_name": "t_user",
"table_id": 77,
"is_record": true,
"record_id": 752767
}
]
兩個regionID均屬于同一張表。
創建空Region 解決Unavailable 報錯。任選一個Store,關閉上面的TiKV,然后執行:
[root@tidb2bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/db recreate-region-p 172.16.134.133:2379 -r 4009
initingempty region 17001 with peer_id 17002...
success
[root@tidb2bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/db recreate-region-p 172.16.134.133:2379 -r 6734
initingempty region 17003 with peer_id 17004...
success
如果不關閉tikv會報錯:
[root@tidb2bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/db recreate-region-p 172.16.134.133:2379 -r 4009
threadmain panicked at called `Result::unwrap()` on an `Err` value:RocksDb("IO error: While lock file:/data1/tidb-data/tikv-20160/db/LOCK: Resource temporarilyunavailable"), src/libcore/result.rs:1188:5
note:run with `RUST_BACKTRACE=1` environment variable to display abacktrace.
停止PD節點:
[root@tidb1~]# tiup cluster stop tidb-test -R=pd
Startingcomponent `cluster`: /root/.tiup/component
重啟啟動PDtikv節點:
[root@tidb1~]# tiup cluster start tidb-test -R=pd,tikv
檢查沒有處于leader狀態的region(要保持沒有):
[root@tidb1~]# pd-ctl -i -u http://172.16.134.133:2379
?region --jq .regions[]|select(has("leader")|not)|{id:.id,peer_stores: [.peers[].store_id]}
?
重新修改PD的參數并嘗試訪問表t_user
MySQL[sbtest2]> select count(*) from t_user;
+----------+
|count(*) |
+----------+
| 1494555 |
+----------+
1row in set (1.92 sec)
由于丟失掉兩個region的所有副本,所以我們查詢出的數據量減少,至此恢復測試結束。
我們再看看region的分布情況:
發現原來三副本丟失的regionID發生了改變。
可以看到表t_user的所有region只有兩副本。
TiDB集群中數據存儲Tikv如果宕了一臺機器,那么并不影響集群的運行,數據庫自身會進行處理,PD會將其上的數據region遷移到其他的TiKV節點上。但如果同時宕機兩臺,甚至3臺及以上災難情況,相信通過上文的介紹理解和相關命令的查詢以及修復,能迅速進行對應的恢復操作。筆者后續會基于平臺將上述過程實現,到時再來和大家分享。
參考文檔https://book.tidb.io/session3/chapter5/recover-quorum.html
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/130198.html
摘要:基于云遷移的三個階段細分為八個主要步驟,評估階段主要包括項目啟動現狀梳理以及應用系統關聯關系分析三個步驟,設計階段包括云架構優化設計和云遷移方案設計,實施階段包括目標架構遷移演練及實施和試運行三個步驟。 在云計算市場規模不斷擴大的大背景下,云遷移的需求越來越大且面臨挑戰。云遷移不是一個遷移軟件工具,而是一種服務。前IBM資深架構師姜亞杰從云遷移的三個階段、四個維度到八個步驟的方法,簡述...
摘要:為云計算災難做好準備要為云計算災難做好準備,企業需要不斷測試其數據恢復框架。與內部部署的災難恢復相比,云計算災難恢復更加簡單。云計算災難恢復的最佳實踐選擇合適的災難恢復計劃方法要制定合適的災難恢復計劃,企業了解其基礎設施非常重要。考慮到當今商業環境中采用的云計算技術迅速增加,從導致服務中斷和停機的災難中有效恢復的能力變得更加重要。基于云計算的災難恢復可以確保企業在盡可能短的時間內恢復其數據和...
摘要:物聯網也影響著數據中心的安全性,主要是隨著資源和數據數量和質量的增長,人們增加了對數據中心安全性的需求。新的物聯網設備是和執行數據分析的其他系統的常見補充,這些設備會導致網絡使用和需求增加。網絡威脅對于數據中心來說是一個不幸的現實,這些數據中心在防止違規事件方面面臨許多挑戰。近年來,這種風險一直在增加,超過40%的受訪者在Carbonite公司進行的調查報告中表示,所面臨的黑客、勒索軟件和其...
摘要:在全世界的聚焦之下,為年倫敦奧運會運行基礎設施的團隊將更多重點放在了可靠性上,而不會展示尖端技術。這意味著熱門技術例如云計算將不會成為奧運會基礎設施的核心部分。表示,每屆奧運會相隔四年,這使確保基礎設施保持狀況成為非常棘手的事情。 在全世界的聚焦之下,為2012年倫敦奧運會運行IT基礎設施的團隊將更多重點放在了可靠性上,而不會展示尖端技術。? 這意味著熱門技術(例如云計算)將不會成為奧運會I...
摘要:日前,廣東華興銀行總行與科華恒盛就總行災備數據中心規劃建設展開深入合作。項目建成后將全面提升廣東華興銀行數據安全保障及運維服務水平,為其總行全球業務提供小時不間斷的同城災備服務,為銀行業務穩定運行實現高速增長奠定牢固的信息化基礎。隨著云計算、大數據等新ICT技術的高速發展,銀行業信息化建設的步伐愈行愈快。日前,廣東華興銀行總行與科華恒盛就總行災備數據中心規劃建設展開深入合作。科華恒盛將為其提...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4099·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3594·2023-01-11 13:20