資訊專欄INFORMATION COLUMN
數據庫是每個企業的重中之重，存儲著公司業務數據，一旦出現永久性損壞，對公司的打擊會是災難性的（從這兩年刪庫跑路，企業經受的損失就可以感知）。分布式數據庫雖然采用數據多副本備份機制來保證數據的可靠性，但同樣也會面臨多副本丟失的風險。災難出現如何快速恢復也是DBA需要面對的問題，本案通過對具體示例的理解與操作介紹了分布式NEWSQL數據庫Tidb對多副本丟失的問題的處理。
TiDB 集群主要包括三個核心組件：TiDBServer，PDServer 和 TiKVServer。
TiDBServer
TiDB Server 負責接收 SQL請求，處理 SQL相關的邏輯，并通過 PD找到存儲計算所需數據的TiKV 地址，與TiKV 交互獲取數據，最終返回結果。TiDBServer 是無狀態的，其本身并不存儲數據，只負責計算，可以無限水平擴展，可以通過負載均衡組件（如LVS、HAProxy或 F5）對外提供統一的接入地址。
PDServer
Placement Driver (簡稱 PD)是整個集群的管理模塊，其主要工作有三個：一是存儲集群的元信息（某個Key 存儲在哪個TiKV 節點）；二是對TiKV 集群進行調度和負載均衡（如數據的遷移、Raftgroup leader 的遷移等）；三是分配全局唯一且遞增的事務ID。PD 通過 Raft協議保證數據的安全性。Raft的 leaderserver 負責處理所有操作，其余的PD server 僅用于保證高可用。
TiKVServer
TiKV Server 負責存儲數據，從外部看TiKV 是一個分布式的提供事務的Key-Value 存儲引擎。存儲數據的基本單位是Region，每個Region 負責存儲一個Key Range（從StartKey 到EndKey 的左閉右開區間）的數據，每個TiKV 節點會負責多個Region。TiKV使用 Raft協議做復制，保持數據的一致性和容災。副本以Region 為單位進行管理，不同節點上的多個Region 構成一個Raft Group，互為副本。數據在多個TiKV 之間的負載均衡由PD 調度，這里也是以Region 為單位進行調度。
TiDB 默認配置為3 副本，每一個Region 都會在集群中保存3 份，它們之間通過Raft 協議來選舉Leader 并同步數據。Raft協議可以保證在數量小于副本數（注意，不是節點數）一半的節點掛掉或者隔離的情況下，仍然能夠提供服務，并且不丟失任何數據。圖1中紫色部分為3副本的region。
對于 3副本集群，掛掉一個節點除了可能會導致性能有抖動之外，可用性和正確性理論上不會受影響；但是掛掉 2個副本，一些region 就會不可用，而且如果這2個副本無法完整地找回了，還存在永久丟失部分數據的可能。
圖1
在實際生產環境中，TiDB集群是可能會出現丟失數據情況，如：
一個 TiDB 集群可能會出現多臺 TiKV 機器短時間內接連故障且無法短期內恢復
一個雙機房部署的 TiDB 集群的其中一個機房整體故障等
在上述這些情形下，會出現部分Region的多個副本（包含全部副本的情況）同時故障，進而導致Region的數據部分或全部丟失的問題。這個時候，最重要的是快速地最大程度地恢復數據并恢復TiDB 集群正常服務。
本次演練采用較新的數據庫軟件版本v4.0.0-rc，主要關注Tikv中region的處理，此架構設計時將PD、TIDB、監控部署在一臺機器之上，并未做冗余處理，Tikv選擇5臺機器，采用Tiup進行部署。下圖為部署設計：
為更好的理解，我們將以擁有三百萬條數據的t_user表作為操作的對象，在測試環境中模擬兩副本以及三副本丟失的災難場景，并進行對應的數據災難恢復。
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 信息。
從信息可以發現，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
}
為更好的理解，根據以上的多個region信息我們可以繪制針對表t_user的數據region的分布圖：
結合表t_user的region分布圖，我們可以推論出如下的情況：
1、如果只宕掉一臺機器：
由于是三副本集群，始終只有一個副本或者沒有副本掛掉，tikv可用性和正確性理論上不會受影響。
2、如果同時宕掉兩臺機器：
三副本集群中，存在只有一個副本掛掉，也會存在兩個副本同時掛掉的情況，當然只用一個副本掛掉，Tikv可用性和正確性理論上不會受影響。當有兩個副本掛掉，Tikv集群將不可用。
例如：在此例中，宕掉Tikv2135和宕掉Tikb5138這兩臺機器，只有兩個region的一個副本掛掉，并不會影響到整個集群，但是如果是宕掉Tikv3136和Tikv4137，則會出現兩個region的兩個副本均掛掉，對此表的SQL無法查詢，但由于還有一個副本的存在，通過復制幸存的副本進行復制并重新進行Leader的選舉進行災難恢復后數據任然能夠被找回，當然可能掛掉的兩個副本其中一個為Leader，部分數據未能從Leader同步到Follower則存在有少量未提交的數據的丟失。
3、如果同時宕掉三臺或更多機器：
理論上，一、二、三個副本掛掉的情況都有可能出現，然而會出現最為嚴重的情況，即為三副本的數據全部丟失，整個表的數據會因為某個region的丟失而出現數據庫災難恢復后表數據的丟失。例如如果是宕掉Tikv1 134、Tikv2135和Tikv3136，會出現region的兩副本掛掉的情況，通過災難恢復可以找回，但是如果掛掉的是Tikv1 134、Tikv3136和Tikv4137，將會有2個region的所有副本均丟失的情況，數據將出現丟失。
這里我們只是以一張表的region分布為例，實際環境中，表的region分布遠比此復雜，在三副本設置的情況下，同時兩臺主機宕掉的情況下，出現兩副本丟失的概率還是較大，當然實際生產中同時宕掉兩臺機器的情況較小，如果對容災有更高要求，也可以選擇五副本。
副本數據恢復包含兩個部分：故障Region 處理和丟失數據處理故障 Region處理，針對 Region數據丟失的嚴重情況，可分為兩種：
Region 至少還有 1個副本，恢復思路是在Region的剩余副本上移除掉所有位于故障節點上的副本，這樣可以用這些剩余副本來重新選舉和補充副本來恢復，但這些剩余副本中可能不包含最新的Raft Log 更新，這個時候就會丟失部分數據Region 的所有副本都丟失了，這個Region 的數據就丟失了，無法恢復。
可以通過創建1 個空 Region來解決 Region不可用的問題在恢復 Region故障的過程中，要詳細記錄下所處理Region 的信息，如Region ID、Region丟失副本的數量等丟失數據處理
根據故障 RegionID 找到對應的表，找到相關用戶并詢問用戶在故障前的某一段時間內（比如5 min），大概寫入了哪些數據表，是否有DDL 操作，是否可以重新消費更上游的數據來再次寫入，等等。
如果可以重導，則是最簡單的處理方式。否則的話，則只能對重要的數據表，檢查數據索引的一致性，保證還在的數據是正確無誤的。至此我們對Tidb副本的作用以及限制有也一定的了解，接下來我們會對region的兩副本丟失和三副本丟失的場景進行演練，下回見。
參考文檔https://book.tidb.io/session3/chapter5/recover-quorum.html
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130204.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
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
