資訊專欄INFORMATION COLUMN
數(shù)據(jù)庫是每個企業(yè)的重中之重，存儲著公司業(yè)務數(shù)據(jù)，一旦出現(xiàn)永久性損壞，對公司的打擊會是災難性的（從這兩年刪庫跑路，企業(yè)經受的損失就可以感知）。分布式數(shù)據(jù)庫雖然采用數(shù)據(jù)多副本備份機制來保證數(shù)據(jù)的可靠性，但同樣也會面臨多副本丟失的風險。災難出現(xiàn)如何快速恢復也是DBA需要面對的問題，本案通過對具體示例的理解與操作介紹了分布式NEWSQL數(shù)據(jù)庫Tidb對多副本丟失的問題的處理。
TiDB 集群主要包括三個核心組件：TiDBServer，PDServer 和 TiKVServer。
TiDBServer
TiDB Server 負責接收 SQL請求，處理 SQL相關的邏輯，并通過 PD找到存儲計算所需數(shù)據(jù)的TiKV 地址，與TiKV 交互獲取數(shù)據(jù)，最終返回結果。TiDBServer 是無狀態(tài)的，其本身并不存儲數(shù)據(jù)，只負責計算，可以無限水平擴展，可以通過負載均衡組件（如LVS、HAProxy或 F5）對外提供統(tǒng)一的接入地址。
PDServer
Placement Driver (簡稱 PD)是整個集群的管理模塊，其主要工作有三個：一是存儲集群的元信息（某個Key 存儲在哪個TiKV 節(jié)點）；二是對TiKV 集群進行調度和負載均衡（如數(shù)據(jù)的遷移、Raftgroup leader 的遷移等）；三是分配全局唯一且遞增的事務ID。PD 通過 Raft協(xié)議保證數(shù)據(jù)的安全性。Raft的 leaderserver 負責處理所有操作，其余的PD server 僅用于保證高可用。
TiKVServer
TiKV Server 負責存儲數(shù)據(jù)，從外部看TiKV 是一個分布式的提供事務的Key-Value 存儲引擎。存儲數(shù)據(jù)的基本單位是Region，每個Region 負責存儲一個Key Range（從StartKey 到EndKey 的左閉右開區(qū)間）的數(shù)據(jù)，每個TiKV 節(jié)點會負責多個Region。TiKV使用 Raft協(xié)議做復制，保持數(shù)據(jù)的一致性和容災。副本以Region 為單位進行管理，不同節(jié)點上的多個Region 構成一個Raft Group，互為副本。數(shù)據(jù)在多個TiKV 之間的負載均衡由PD 調度，這里也是以Region 為單位進行調度。
TiDB 默認配置為3 副本，每一個Region 都會在集群中保存3 份，它們之間通過Raft 協(xié)議來選舉Leader 并同步數(shù)據(jù)。Raft協(xié)議可以保證在數(shù)量小于副本數(shù)（注意，不是節(jié)點數(shù)）一半的節(jié)點掛掉或者隔離的情況下，仍然能夠提供服務，并且不丟失任何數(shù)據(jù)。圖1中紫色部分為3副本的region。
對于 3副本集群，掛掉一個節(jié)點除了可能會導致性能有抖動之外，可用性和正確性理論上不會受影響；但是掛掉 2個副本，一些region 就會不可用，而且如果這2個副本無法完整地找回了，還存在永久丟失部分數(shù)據(jù)的可能。
圖1
在實際生產環(huán)境中，TiDB集群是可能會出現(xiàn)丟失數(shù)據(jù)情況，如：
一個 TiDB 集群可能會出現(xiàn)多臺 TiKV 機器短時間內接連故障且無法短期內恢復
一個雙機房部署的 TiDB 集群的其中一個機房整體故障等
在上述這些情形下，會出現(xiàn)部分Region的多個副本（包含全部副本的情況）同時故障，進而導致Region的數(shù)據(jù)部分或全部丟失的問題。這個時候，最重要的是快速地最大程度地恢復數(shù)據(jù)并恢復TiDB 集群正常服務。
本次演練采用較新的數(shù)據(jù)庫軟件版本v4.0.0-rc，主要關注Tikv中region的處理，此架構設計時將PD、TIDB、監(jiān)控部署在一臺機器之上，并未做冗余處理，Tikv選擇5臺機器，采用Tiup進行部署。下圖為部署設計：
為更好的理解，我們將以擁有三百萬條數(shù)據(jù)的t_user表作為操作的對象，在測試環(huán)境中模擬兩副本以及三副本丟失的災難場景，并進行對應的數(shù)據(jù)災難恢復。
T_user表結構：
CreateTable: CREATE TABLE `t_user` (
`id` int(11) NOT NULL,
`c_user_id` varchar(36) DEFAULT NULL,
`c_name` varchar(22) DEFAULT NULL,
`c_province_id` int(11) DEFAULT NULL,
`c_city_id` int(11) DEFAULT NULL,
`create_time` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
查看t_user表在store的分布：
SHOWTABLE REGIONS 語句用于顯示TiDB 中某個表的Region 信息。
從信息可以發(fā)現(xiàn)，t_user表有四個region，但是SQL命令未能詳細列出region在不同的store上的分布，例如region的leader以及folloer如何在store進行分布，這里信息有助于我們更好理解region的分布。
通過pd-ctl工具可以找到更加詳細的信息：
[root@tidb1bin]# ./pd-ctl -i -u http://172.16.134.133:2379
?region 4009
{
"id": 4009,
"start_key":"7480000000000000FF4D5F728000000000FF224A9A0000000000FA",
"end_key": "",
"epoch": {
"conf_ver": 23,
"version": 36
},
"peers": [
{
"id": 4010,
"store_id": 5
},
{
"id": 4011,
"store_id": 6
},
{
"id": 4012,
"store_id": 4
}
],
"leader": {
"id": 4010,
"store_id": 5
},
"written_bytes": 0,
"read_bytes": 0,
"written_keys": 0,
"read_keys": 0,
"approximate_size": 99,
"approximate_keys": 773985
}
為更好的理解，根據(jù)以上的多個region信息我們可以繪制針對表t_user的數(shù)據(jù)region的分布圖：
結合表t_user的region分布圖，我們可以推論出如下的情況：
1、如果只宕掉一臺機器：
由于是三副本集群，始終只有一個副本或者沒有副本掛掉，tikv可用性和正確性理論上不會受影響。
2、如果同時宕掉兩臺機器：
三副本集群中，存在只有一個副本掛掉，也會存在兩個副本同時掛掉的情況，當然只用一個副本掛掉，Tikv可用性和正確性理論上不會受影響。當有兩個副本掛掉，Tikv集群將不可用。
例如：在此例中，宕掉Tikv2135和宕掉Tikb5138這兩臺機器，只有兩個region的一個副本掛掉，并不會影響到整個集群，但是如果是宕掉Tikv3136和Tikv4137，則會出現(xiàn)兩個region的兩個副本均掛掉，對此表的SQL無法查詢，但由于還有一個副本的存在，通過復制幸存的副本進行復制并重新進行Leader的選舉進行災難恢復后數(shù)據(jù)任然能夠被找回，當然可能掛掉的兩個副本其中一個為Leader，部分數(shù)據(jù)未能從Leader同步到Follower則存在有少量未提交的數(shù)據(jù)的丟失。
3、如果同時宕掉三臺或更多機器：
理論上，一、二、三個副本掛掉的情況都有可能出現(xiàn)，然而會出現(xiàn)最為嚴重的情況，即為三副本的數(shù)據(jù)全部丟失，整個表的數(shù)據(jù)會因為某個region的丟失而出現(xiàn)數(shù)據(jù)庫災難恢復后表數(shù)據(jù)的丟失。例如如果是宕掉Tikv1 134、Tikv2135和Tikv3136，會出現(xiàn)region的兩副本掛掉的情況，通過災難恢復可以找回，但是如果掛掉的是Tikv1 134、Tikv3136和Tikv4137，將會有2個region的所有副本均丟失的情況，數(shù)據(jù)將出現(xiàn)丟失。
這里我們只是以一張表的region分布為例，實際環(huán)境中，表的region分布遠比此復雜，在三副本設置的情況下，同時兩臺主機宕掉的情況下，出現(xiàn)兩副本丟失的概率還是較大，當然實際生產中同時宕掉兩臺機器的情況較小，如果對容災有更高要求，也可以選擇五副本。
副本數(shù)據(jù)恢復包含兩個部分：故障Region 處理和丟失數(shù)據(jù)處理故障 Region處理，針對 Region數(shù)據(jù)丟失的嚴重情況，可分為兩種：
Region 至少還有 1個副本，恢復思路是在Region的剩余副本上移除掉所有位于故障節(jié)點上的副本，這樣可以用這些剩余副本來重新選舉和補充副本來恢復，但這些剩余副本中可能不包含最新的Raft Log 更新，這個時候就會丟失部分數(shù)據(jù)Region 的所有副本都丟失了，這個Region 的數(shù)據(jù)就丟失了，無法恢復。
可以通過創(chuàng)建1 個空 Region來解決 Region不可用的問題在恢復 Region故障的過程中，要詳細記錄下所處理Region 的信息，如Region ID、Region丟失副本的數(shù)量等丟失數(shù)據(jù)處理
根據(jù)故障 RegionID 找到對應的表，找到相關用戶并詢問用戶在故障前的某一段時間內（比如5 min），大概寫入了哪些數(shù)據(jù)表，是否有DDL 操作，是否可以重新消費更上游的數(shù)據(jù)來再次寫入，等等。
如果可以重導，則是最簡單的處理方式。否則的話，則只能對重要的數(shù)據(jù)表，檢查數(shù)據(jù)索引的一致性，保證還在的數(shù)據(jù)是正確無誤的。至此我們對Tidb副本的作用以及限制有也一定的了解，接下來我們會對region的兩副本丟失和三副本丟失的場景進行演練，下回見。
參考文檔https://book.tidb.io/session3/chapter5/recover-quorum.html
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://www.ezyhdfw.cn/yun/130204.html
摘要：為云計算災難做好準備要為云計算災難做好準備，企業(yè)需要不斷測試其數(shù)據(jù)恢復框架。與內部部署的災難恢復相比，云計算災難恢復更加簡單。云計算災難恢復的最佳實踐選擇合適的災難恢復計劃方法要制定合適的災難恢復計劃，企業(yè)了解其基礎設施非常重要?？紤]到當今商業(yè)環(huán)境中采用的云計算技術迅速增加，從導致服務中斷和停機的災難中有效恢復的能力變得更加重要?；谠朴嬎愕臑碾y恢復可以確保企業(yè)在盡可能短的時間內恢復其數(shù)據(jù)和...
摘要：基于云遷移的三個階段細分為八個主要步驟，評估階段主要包括項目啟動現(xiàn)狀梳理以及應用系統(tǒng)關聯(lián)關系分析三個步驟，設計階段包括云架構優(yōu)化設計和云遷移方案設計，實施階段包括目標架構遷移演練及實施和試運行三個步驟。 在云計算市場規(guī)模不斷擴大的大背景下，云遷移的需求越來越大且面臨挑戰(zhàn)。云遷移不是一個遷移軟件工具，而是一種服務。前IBM資深架構師姜亞杰從云遷移的三個階段、四個維度到八個步驟的方法，簡述...
摘要：物聯(lián)網也影響著數(shù)據(jù)中心的安全性，主要是隨著資源和數(shù)據(jù)數(shù)量和質量的增長，人們增加了對數(shù)據(jù)中心安全性的需求。新的物聯(lián)網設備是和執(zhí)行數(shù)據(jù)分析的其他系統(tǒng)的常見補充，這些設備會導致網絡使用和需求增加。網絡威脅對于數(shù)據(jù)中心來說是一個不幸的現(xiàn)實，這些數(shù)據(jù)中心在防止違規(guī)事件方面面臨許多挑戰(zhàn)。近年來，這種風險一直在增加，超過40％的受訪者在Carbonite公司進行的調查報告中表示，所面臨的黑客、勒索軟件和其...
摘要：在全世界的聚焦之下，為年倫敦奧運會運行基礎設施的團隊將更多重點放在了可靠性上，而不會展示尖端技術。這意味著熱門技術例如云計算將不會成為奧運會基礎設施的核心部分。表示，每屆奧運會相隔四年，這使確?；A設施保持狀況成為非常棘手的事情。 在全世界的聚焦之下，為2012年倫敦奧運會運行IT基礎設施的團隊將更多重點放在了可靠性上，而不會展示尖端技術。? 這意味著熱門技術(例如云計算)將不會成為奧運會I...
摘要：日前，廣東華興銀行總行與科華恒盛就總行災備數(shù)據(jù)中心規(guī)劃建設展開深入合作。項目建成后將全面提升廣東華興銀行數(shù)據(jù)安全保障及運維服務水平，為其總行全球業(yè)務提供小時不間斷的同城災備服務，為銀行業(yè)務穩(wěn)定運行實現(xiàn)高速增長奠定牢固的信息化基礎。隨著云計算、大數(shù)據(jù)等新ICT技術的高速發(fā)展，銀行業(yè)信息化建設的步伐愈行愈快。日前，廣東華興銀行總行與科華恒盛就總行災備數(shù)據(jù)中心規(guī)劃建設展開深入合作?？迫A恒盛將為其提...
閱讀 1459·2023-01-11 13:20
閱讀 1812·2023-01-11 13:20
閱讀 1263·2023-01-11 13:20
閱讀 2005·2023-01-11 13:20
閱讀 4226·2023-01-11 13:20
閱讀 2879·2023-01-11 13:20
閱讀 1488·2023-01-11 13:20
閱讀 3807·2023-01-11 13:20
