一赶舆、分布式數(shù)據(jù)庫誕生背景
隨著互聯(lián)網(wǎng)的飛速發(fā)展，業(yè)務(wù)量可能在短短的時(shí)間內(nèi)爆發(fā)式地增長趾唱，對應(yīng)的數(shù)據(jù)量可能快速地從幾百 GB 漲到幾百個(gè)TB涌乳，傳統(tǒng)的單機(jī)數(shù)據(jù)庫提供的服務(wù)，在系統(tǒng)的可擴(kuò)展性甜癞、性價(jià)比方面已經(jīng)不再適用夕晓。比如MySQL數(shù)據(jù)庫，可以說絕大部分公司核心的數(shù)據(jù)都存儲(chǔ)在MySQL中悠咱。MySQL的優(yōu)點(diǎn)不用多說蒸辆，缺點(diǎn)是沒法做到水平擴(kuò)展。MySQL要想能做到水平擴(kuò)展析既，唯一的方法就業(yè)務(wù)層的分庫分表或者使用中間件等方案躬贡。因此幾年前就出現(xiàn)了各大公司重復(fù)造輪子，不斷涌現(xiàn)出中間層分庫分表解決方案眼坏，比如百度的DDBS拂玻，淘寶的 TDDL，360 的Atlas宰译，及MyCAT檐蚜，以愛可生基于MyCAT二次改造的DBLE等。但是沿侈，這些中間層方案也有很大局限性闯第，執(zhí)行計(jì)劃不是最優(yōu)，分布式事務(wù)缀拭，跨節(jié)點(diǎn)join咳短，擴(kuò)容復(fù)雜等填帽。
隨著業(yè)界相關(guān)分布式數(shù)據(jù)庫論文的發(fā)布，分布式數(shù)據(jù)庫應(yīng)運(yùn)而生咙好，可以預(yù)見分布式數(shù)據(jù)庫必將成為海量數(shù)據(jù)處理技術(shù)發(fā)展的又一個(gè)核心篡腌。目前業(yè)界最流行的分布式數(shù)據(jù)庫有兩類，一個(gè)是以Google Spanner為代表敷扫，一個(gè)是以AWS Auraro為代表哀蘑。
Spanner 是 shared nothing 的架構(gòu)诚卸，內(nèi)部維護(hù)了自動(dòng)分片葵第、分布式事務(wù)、彈性擴(kuò)展能力合溺，數(shù)據(jù)存儲(chǔ)還是需要sharding卒密，plan計(jì)算也需要涉及多臺(tái)機(jī)器，也就涉及了分布式計(jì)算和分布式事務(wù)棠赛。主要產(chǎn)品代表為TiDB哮奇、CockroachDB、OceanBase等睛约；這三個(gè)產(chǎn)品可以說目前話題量不相下鼎俘，TiDB屬于國產(chǎn)PingCAP公司的、CockroachDB比TiDB早出來一年辩涝、OceanBase阿里團(tuán)隊(duì)的贸伐，2017年雙11交出4200萬/秒的處理能力。Auraro主要思想是計(jì)算和存儲(chǔ)分離架構(gòu)怔揩，使用共享存儲(chǔ)技術(shù)捉邢，這樣就提高了容災(zāi)和總?cè)萘康臄U(kuò)展。但是在協(xié)議層商膊，只要是不涉及到存儲(chǔ)的部分本質(zhì)還是單機(jī)實(shí)例的MySQL伏伐，不涉及分布式存儲(chǔ)和分布式計(jì)算，這樣就和 MySQL 兼容性非常高晕拆。主要產(chǎn)品代表為 PolarDB藐翎。
二、TiDB簡介
TiDB 是 PingCAP 公司基于 GoogleSpanner/F1論文實(shí)現(xiàn)的開源分布式 NewSQL 數(shù)據(jù)庫实幕。實(shí)現(xiàn)了自動(dòng)的水平伸縮吝镣，強(qiáng)一致性的分布式事務(wù)，基于 Raft 算法的多副本復(fù)制等重要 NewSQL 特性茬缩。 TiDB 結(jié)合了 RDBMS 和 NoSQL 的優(yōu)點(diǎn)赤惊，部署簡單，在線彈性擴(kuò)容和異步表結(jié)構(gòu)變更不影響業(yè)務(wù)凰锡， 真正的異地多活及自動(dòng)故障恢復(fù)保障數(shù)據(jù)安全未舟，同時(shí)兼容 MySQL 協(xié)議圈暗，使遷移使用成本降到極低缆毁。
TiDB 具備如下 NewSQL 核心特性：
SQL支持 （TiDB 是 MySQL 兼容的）
水平線性彈性擴(kuò)展
分布式事務(wù)
跨數(shù)據(jù)中心數(shù)據(jù)強(qiáng)一致性保證
故障自恢復(fù)的高可用
TiDB 的設(shè)計(jì)目標(biāo)是 100% 的 OLTP 場景和 80% 的 OLAP 場景产徊。
TiDB 對業(yè)務(wù)沒有任何侵入性，能優(yōu)雅的替換傳統(tǒng)的數(shù)據(jù)庫中間件壕曼、數(shù)據(jù)庫分庫分表等 Sharding 方案昼扛。同時(shí)它也讓開發(fā)運(yùn)維人員不用關(guān)注數(shù)據(jù)庫 Scale 的細(xì)節(jié)問題寸齐，專注于業(yè)務(wù)開發(fā)，極大的提升研發(fā)的生產(chǎn)力抄谐。
三渺鹦、TiDB整體架構(gòu)
要深入了解 TiDB 的水平擴(kuò)展和高可用特點(diǎn)，首先需要了解 TiDB 的整體架構(gòu)蛹含。
TiDB 集群主要分為三個(gè)組件：
TiDB Server
TiDB Server 負(fù)責(zé)接收 SQL 請求毅厚，處理 SQL 相關(guān)的邏輯，并通過 PD 找到存儲(chǔ)計(jì)算所需數(shù)據(jù)的 TiKV 地址浦箱，與TiKV 交互獲取數(shù)據(jù)吸耿，最終返回結(jié)果。 TiDB Server是無狀態(tài)的酷窥，其本身并不存儲(chǔ)數(shù)據(jù)咽安，只負(fù)責(zé)計(jì)算，可以無限水平擴(kuò)展蓬推，可以通過負(fù)載均衡組件（如LVS妆棒、HAProxy 或 F5）對外提供統(tǒng)一的接入地址。
PD Server
Placement Driver (簡稱 PD) 是整個(gè)集群的管理模塊拳氢，其主要工作有三個(gè)： 一是存儲(chǔ)集群的元信息（某個(gè) Key 存儲(chǔ)在哪個(gè)TiKV 節(jié)點(diǎn)）募逞；二是對 TiKV 集群進(jìn)行調(diào)度和負(fù)載均衡（如數(shù)據(jù)的遷移、Raft group leader的遷移等）馋评；三是分配全局唯一且遞增的事務(wù) ID放接。PD 是一個(gè)集群，需要部署奇數(shù)個(gè)節(jié)點(diǎn)留特，一般線上推薦至少部署 3 個(gè)節(jié)點(diǎn)纠脾。
TiKV Server
TiKV Server 負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，從外部看 TiKV 是一個(gè)分布式的提供事務(wù)的 Key-Value 存儲(chǔ)引擎蜕青。存儲(chǔ)數(shù)據(jù)的基本單位是Region（區(qū)域）苟蹈，每個(gè)Region 負(fù)責(zé)存儲(chǔ)一個(gè) Key Range （從 StartKey 到 EndKey的左閉右開區(qū)間）的數(shù)據(jù)，每個(gè) TiKV 節(jié)點(diǎn)會(huì)負(fù)責(zé)多個(gè) Region 右核。TiKV 使用 Raft 協(xié)議做復(fù)制慧脱，保持?jǐn)?shù)據(jù)的一致性和容災(zāi)。副本以Region 為單位進(jìn)行管理贺喝，不同節(jié)點(diǎn)上的多個(gè) Region 構(gòu)成一個(gè) Raft Group菱鸥，互為副本宗兼。數(shù)據(jù)在多個(gè) TiKV 之間的負(fù)載均衡由PD 調(diào)度，這里也是以 Region 為單位進(jìn)行調(diào)度氮采。
核心特性
水平擴(kuò)展
無限水平擴(kuò)展是 TiDB 的一大特點(diǎn)殷绍，這里說的水平擴(kuò)展包括兩方面：計(jì)算能力和存儲(chǔ)能力。TiDB Server 負(fù)責(zé)處理 SQL請求鹊漠，隨著業(yè)務(wù)的增長主到，可以簡單的添加 TiDB Server 節(jié)點(diǎn)，提高整體的處理能力躯概，提供更高的吞吐登钥。TiKV負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，隨著數(shù)據(jù)量的增長楞陷，可以部署更多的 TiKV Server 節(jié)點(diǎn)解決數(shù)據(jù) Scale 的問題怔鳖。PD 會(huì)在 TiKV 節(jié)點(diǎn)之間以Region 為單位做調(diào)度，將部分?jǐn)?shù)據(jù)遷移到新加的節(jié)點(diǎn)上固蛾。所以在業(yè)務(wù)的早期，可以只部署少量的服務(wù)實(shí)例（推薦至少部署 3 個(gè) TiKV度陆， 3 個(gè)PD艾凯，2 個(gè) TiDB），隨著業(yè)務(wù)量的增長懂傀，按照需求添加 TiKV 或者 TiDB 實(shí)例趾诗。
高可用
高可用是 TiDB 的另一大特點(diǎn)，TiDB/TiKV/PD 這三個(gè)組件都能容忍部分實(shí)例失效蹬蚁，不影響整個(gè)集群的可用性恃泪。下面分別說明這三個(gè)組件的可用性、單個(gè)實(shí)例失效后的后果以及如何恢復(fù)犀斋。
TiDB
TiDB 是無狀態(tài)的贝乎，推薦至少部署兩個(gè)實(shí)例，前端通過負(fù)載均衡組件對外提供服務(wù)叽粹。當(dāng)單個(gè)實(shí)例失效時(shí)览效，會(huì)影響正在這個(gè)實(shí)例上進(jìn)行的Session，從應(yīng)用的角度看虫几，會(huì)出現(xiàn)單次請求失敗的情況锤灿，重新連接后即可繼續(xù)獲得服務(wù)。單個(gè)實(shí)例失效后辆脸，可以重啟這個(gè)實(shí)例或者部署一個(gè)新的實(shí)例但校。
PD
PD 是一個(gè)集群，通過 Raft 協(xié)議保持?jǐn)?shù)據(jù)的一致性啡氢，單個(gè)實(shí)例失效時(shí)状囱，如果這個(gè)實(shí)例不是 Raft 的leader州刽，那么服務(wù)完全不受影響；如果這個(gè)實(shí)例是 Raft 的 leader浪箭，會(huì)重新選出新的 Raft leader穗椅，自動(dòng)恢復(fù)服務(wù)。PD在選舉的過程中無法對外提供服務(wù)奶栖，這個(gè)時(shí)間大約是3秒鐘匹表。推薦至少部署三個(gè) PD 實(shí)例，單個(gè)實(shí)例失效后宣鄙，重啟這個(gè)實(shí)例或者添加新的實(shí)例袍镀。
TiKV
TiKV 是一個(gè)集群，通過 Raft 協(xié)議保持?jǐn)?shù)據(jù)的一致性（副本數(shù)量可配置冻晤，默認(rèn)保存三副本）苇羡，并通過 PD做負(fù)載均衡調(diào)度。單個(gè)節(jié)點(diǎn)失效時(shí)鼻弧，會(huì)影響這個(gè)節(jié)點(diǎn)上存儲(chǔ)的所有 Region设江。對于 Region 中的 Leader結(jié)點(diǎn)，會(huì)中斷服務(wù)攘轩，等待重新選舉叉存；對于 Region 中的 Follower 節(jié)點(diǎn)，不會(huì)影響服務(wù)度帮。當(dāng)某個(gè) TiKV節(jié)點(diǎn)失效歼捏，并且在一段時(shí)間內(nèi)（默認(rèn) 10 分鐘）無法恢復(fù)，PD 會(huì)將其上的數(shù)據(jù)遷移到其他的 TiKV 節(jié)點(diǎn)上笨篷。
四瞳秽、TiDB原理與實(shí)現(xiàn)
三篇文章了解 TiDB 技術(shù)內(nèi)幕：
TiDB 架構(gòu)是 SQL 層和 KV 存儲(chǔ)層分離，相當(dāng)于?InnoDB 插件存儲(chǔ)引擎與 MySQL的關(guān)系率翅。從下圖可以看出整個(gè)系統(tǒng)是高度分層的练俐，最底層選用了當(dāng)前比較流行的存儲(chǔ)引擎 RocksDB，RockDB性能很好但是是單機(jī)的安聘，為了保證高可用所以寫多份（一般為 3 份）痰洒，上層使用 Raft 協(xié)議來保證單機(jī)失效后數(shù)據(jù)不丟失不出錯(cuò)。保證有了比較安全的KV 存儲(chǔ)的基礎(chǔ)上再去構(gòu)建多版本浴韭，再去構(gòu)建分布式事務(wù)丘喻，這樣就構(gòu)成了存儲(chǔ)層 TiKV。有了TiKV念颈，TiDB 層只需要實(shí)現(xiàn) SQL 層泉粉，再加上MySQL 協(xié)議的支持，應(yīng)用程序就能像訪問 MySQL 那樣去訪問 TiDB 了。
這里還有個(gè)非常重要的概念叫做 Region嗡靡。MySQL分庫分表是將大的數(shù)據(jù)分成一張一張小表然后分散在多個(gè)集群的多臺(tái)機(jī)器上跺撼，以實(shí)現(xiàn)水平擴(kuò)展。同理讨彼，分布式數(shù)據(jù)庫為了實(shí)現(xiàn)水平擴(kuò)展歉井，就需要對大的數(shù)據(jù)集進(jìn)行分片，一個(gè)分片也就成為了一個(gè)Region哈误。數(shù)據(jù)分片有兩個(gè)典型的方案：一是按照 Key 來做 Hash哩至，同樣 Hash 值的 Key 在同一個(gè) Region 上，二是Range蜜自，某一段連續(xù)的 Key 在同一個(gè) Region 上菩貌，兩種分片各有優(yōu)劣，TiKV 選擇了 Range partition重荠。TiKV 以Region 作為最小調(diào)度單位箭阶，分散在各個(gè)節(jié)點(diǎn)上，實(shí)現(xiàn)負(fù)載均衡戈鲁。另外 TiKV 以 Region 為單位做數(shù)據(jù)復(fù)制仇参，也就是一個(gè) Region保留多個(gè)副本，副本之間通過 Raft 來保持?jǐn)?shù)據(jù)的一致荞彼。每個(gè) Region 的所有副本組成一個(gè) Raft Group,整個(gè)系統(tǒng)可以看到很多這樣的 Raft groups冈敛。
最后簡單說一下調(diào)度。 TiKV 節(jié)點(diǎn)會(huì)定期向 PD 匯報(bào)節(jié)點(diǎn)的整體信息鸣皂，每個(gè) Region Raft Group 的 Leader 也會(huì)定期向 PD 匯報(bào)信息，PD 不斷的通過這些心跳包收集信息暮蹂，獲得整個(gè)集群的詳細(xì)數(shù)據(jù)寞缝，從而進(jìn)行調(diào)度，實(shí)現(xiàn)負(fù)載均衡仰泻。
五荆陆、TiDB軟硬件環(huán)境
TiDB 作為一款開源分布式 NewSQL 數(shù)據(jù)庫，可以很好的部署和運(yùn)行在 Intel 架構(gòu)服務(wù)器環(huán)境及主流虛擬化環(huán)境集侯，并支持絕大多數(shù)的主流硬件網(wǎng)絡(luò)被啼。作為一款高性能數(shù)據(jù)庫系統(tǒng)，TiDB 支持主流的 Linux 操作系統(tǒng)環(huán)境棠枉。
TiDB 支持部署和運(yùn)行在 Intel x86-64 架構(gòu)的 64 位通用硬件服務(wù)器平臺(tái)浓体。對于開發(fā)，測試辈讶，及生產(chǎn)環(huán)境的服務(wù)器硬件配置有以下要求和建議：
開發(fā)及測試環(huán)境
組件CPU內(nèi)存本地存儲(chǔ)網(wǎng)絡(luò)實(shí)例數(shù)量(最低要求)
TiDB16核+16 GB+SAS, 200 GB+千兆網(wǎng)卡1
PD16核+16 GB+SAS, 200 GB+千兆網(wǎng)卡-
TiKV16核+32 GB+SAS, 200 GB+千兆網(wǎng)卡3
服務(wù)器總計(jì)4
生產(chǎn)環(huán)境
組件CPU內(nèi)存硬盤類型硬盤數(shù)量單塊硬盤大小網(wǎng)絡(luò)實(shí)例數(shù)量(最低要求)
TiDB32核+128 GB+SSD最低2塊500 GB+2塊+ 萬兆網(wǎng)卡2
PD16核+32 GB+SSD最低2塊200 GB+2塊+ 萬兆網(wǎng)卡3
TiKV32核+128 GB+SSD最低2塊200~500 GB2塊+ 萬兆網(wǎng)卡3
監(jiān)控16核+32 GB+SAS最低4塊200 GB+2塊+ 千兆網(wǎng)卡1
服務(wù)器總計(jì)9
對于生產(chǎn)環(huán)境命浴，這個(gè)配置要求還是挺高的，光硬件費(fèi)用都是一筆不小的開銷。再說目前TiDB還屬于小步慢跑階段生闲，一般拿來都是在非核心業(yè)務(wù)使用媳溺，積累運(yùn)維經(jīng)驗(yàn)，所以這個(gè)配置對于現(xiàn)實(shí)環(huán)境來說還是有點(diǎn)高了碍讯，所以剛開始試水也是可以折中悬蔽。
比如，因 TiDB 和 PD 對磁盤 IO 要求不高捉兴，所以只需要普通磁盤即可蝎困。TiKV 對磁盤 IO 要求較高，可以選擇SSD轴术，另官方建議 TiKV 硬盤大小建議不超過 500G难衰，以防止硬盤損害時(shí)，數(shù)據(jù)恢復(fù)耗時(shí)過長逗栽。其TiDB 節(jié)點(diǎn)和 PD節(jié)點(diǎn)也可以部署在同臺(tái)服務(wù)器上盖袭，而 TiKV 節(jié)點(diǎn)獨(dú)立部署在服務(wù)上，最少 3 臺(tái)彼宠，保持 3 副本鳄虱，根據(jù)容量大小進(jìn)行擴(kuò)展。如對性能和可靠性有更高的要求凭峡，應(yīng)盡可能分開部署拙已。強(qiáng)烈建議使用萬兆網(wǎng)卡。
網(wǎng)絡(luò)環(huán)境
TiDB其正常運(yùn)行需要網(wǎng)絡(luò)環(huán)境提供如下的網(wǎng)絡(luò)端口配置要求摧冀，管理員可根據(jù)實(shí)際環(huán)境中 TiDB 組件部署的方案倍踪，在網(wǎng)絡(luò)側(cè)和主機(jī)側(cè)啟用相關(guān)端口：
組件默認(rèn)端口說明
TiDB4000應(yīng)用及 DBA 工具訪問通信端口
TiDB10080TiDB 狀態(tài)信息上報(bào)通信端口
TiKV20160TiKV 通信端口
PD2379提供 TiDB 和 PD 通信端口
PD2380PD 集群節(jié)點(diǎn)間通信端口
Prometheus9090Prometheus 服務(wù)通信端口
Pushgateway9091TiDB, TiKV, PD 監(jiān)控聚合和上報(bào)端口
Node_exporter9100TiDB 集群每個(gè)節(jié)點(diǎn)的系統(tǒng)信息上報(bào)通信端口
Grafana3000Web 監(jiān)控服務(wù)對外服務(wù)和客戶端(瀏覽器)訪問端口
六、TiDB部署方案
Ansible 是一款自動(dòng)化運(yùn)維工具索昂，TiDB-Ansible是 PingCAP 基于 Ansible playbook 功能編寫的集群部署工具建车。使用 TiDB-Ansible 可以快速部署一個(gè)完整的 TiDB 集群（包括 PD、TiDB椒惨、TiKV 和集群監(jiān)控模塊)缤至。
本部署工具可以通過配置文件設(shè)置集群拓?fù)洌绘I完成以下各項(xiàng)運(yùn)維工作：
初始化操作系統(tǒng)康谆，包括創(chuàng)建部署用戶领斥、設(shè)置 hostname 等
部署組件
滾動(dòng)升級(jí)，滾動(dòng)升級(jí)時(shí)支持模塊存活檢測
數(shù)據(jù)清理
環(huán)境清理
配置監(jiān)控模塊
TiDB-Ansible?工具還支持?jǐn)U容及縮容操作沃暗。另外月洛， TiDB也同樣支持二進(jìn)制部署、Docker部署描睦、跨機(jī)房部署等不同方案膊存。
七、TiDB監(jiān)控方案
Pincap 團(tuán)隊(duì)給 TiDB 提供了一整套監(jiān)控的方案，他們使用開源時(shí)序數(shù)據(jù)庫 Prometheus 作為監(jiān)控和性能指標(biāo)信息存儲(chǔ)方案隔崎，使用Grafana 作為可視化組件進(jìn)行展示今艺。具體如下圖，在 client 端程序中定制需要的 Metric 爵卒。Push GateWay 來接收Client Push 上來的數(shù)據(jù)虚缎，統(tǒng)一供 Prometheus 主服務(wù)器抓取。AlertManager 用來實(shí)現(xiàn)報(bào)警機(jī)制钓株，使用 Grafana來進(jìn)行展示实牡。
Grafana 是一個(gè)開源的 metric 分析及可視化系統(tǒng)。使用 Grafana 來展示 TiDB 的各項(xiàng)性能指標(biāo) 轴合。如下圖所示:
八创坞、TiSpark助力OLAP
TiSpark 是 PingCAP 為解決用戶復(fù)雜 OLAP 需求而推出的產(chǎn)品。借助 Spark 平臺(tái)受葛，同時(shí)融合 TiKV分布式集群的優(yōu)勢题涨，和 TiDB 一起為用戶一站式解決 HTAP （Hybrid Transactional/AnalyticalProcessing）需求。 TiSpark 依賴于 TiKV 集群和 Placement Driver(PD)总滩。當(dāng)然纲堵，TiSpark也需要您搭建一個(gè) Spark 集群。
TiSpark 是將 Spark SQL 直接運(yùn)行在分布式存儲(chǔ)引擎 TiKV 上的 OLAP 解決方案闰渔。其架構(gòu)圖如下：
TiSpark 深度整合了 Spark Catalyst 引擎, 可以對計(jì)算提供精確的控制席函，使 Spark 能夠高效的讀取 TiKV 中的數(shù)據(jù)，提供索引支持以實(shí)現(xiàn)高速的點(diǎn)查冈涧。通過多種計(jì)算下推減少 Spark SQL 需要處理的數(shù)據(jù)大小茂附，以加速查詢；利用 TiDB 的內(nèi)建的統(tǒng)計(jì)信息選擇更優(yōu)的查詢計(jì)劃督弓。從數(shù)據(jù)集群的角度看何之，TiSpark + TiDB 可以讓用戶無需進(jìn)行脆弱和難以維護(hù)的 ETL，直接在同一個(gè)平臺(tái)進(jìn)行事務(wù)和分析兩種工作咽筋，簡化了系統(tǒng)架構(gòu)和運(yùn)維。
除此之外徊件，用戶借助 TiSpark 項(xiàng)目可以在 TiDB 上使用 Spark 生態(tài)圈提供的多種工具進(jìn)行數(shù)據(jù)處理奸攻。例如使用 TiSpark 進(jìn)行數(shù)據(jù)分析和 ETL；使用 TiKV 作為機(jī)器學(xué)習(xí)的數(shù)據(jù)源虱痕；借助調(diào)度系統(tǒng)產(chǎn)生定時(shí)報(bào)表等等睹耐。
九、TiDB周邊工具
mydumper/loader
備份恢復(fù)工具部翘，使用 mydumper 從 TiDB 導(dǎo)出數(shù)據(jù)進(jìn)行備份硝训，然后用 loader 將其導(dǎo)入到 TiDB 里面進(jìn)行恢復(fù)。雖然TiDB 也支持使用 MySQL 官方的 mysqldump 工具來進(jìn)行數(shù)據(jù)的備份恢復(fù)工作，但相比于 mydumper /loader窖梁，性能會(huì)慢很多赘风，大量數(shù)據(jù)的備份恢復(fù)會(huì)花費(fèi)很多時(shí)間，因此并不推薦纵刘。
其mydumper/myloader是Percona開源產(chǎn)品邀窃，多線程MySQL邏輯備份和恢復(fù)工具。那為什么PingCAP還開發(fā)loader工具呢假哎？官方是這么說的：在使用過程中瞬捕，mydumper問題不大，但是 myloader 由于缺乏出錯(cuò)重試舵抹、斷點(diǎn)續(xù)傳這樣的功能肪虎，使用起來很不方便。所以我們開發(fā)了 loader惧蛹，能夠讀取mydumper 的輸出數(shù)據(jù)文件扇救，通過 mysql protocol 向 TiDB/MySQL 中導(dǎo)入數(shù)據(jù)。
syncer
根據(jù)MySQL binlog增量同步工具赊淑，Syncer 可以部署在任一臺(tái)可以連通對應(yīng)的 MySQL 和 TiDB 集群的機(jī)器上爵政，推薦部署在 TiDB 集群。
架構(gòu)圖如下：
TiDB-Binlog
TiDB-Binlog 用于收集 TiDB 的 Binlog陶缺，并提供實(shí)時(shí)備份和同步功能的商業(yè)工具钾挟。
TiDB-Binlog 支持以下功能場景:
數(shù)據(jù)同步: 同步 TiDB 集群數(shù)據(jù)到其他數(shù)據(jù)庫
實(shí)時(shí)備份和恢復(fù): 備份 TiDB 集群數(shù)據(jù)，同時(shí)可以用于 TiDB 集群故障時(shí)恢復(fù)
PD Control
PD Control 是 PD 的命令行工具饱岸，用于獲取集群狀態(tài)信息和調(diào)整集群掺出。
TiDB官方：https://pingcap.com
該文轉(zhuǎn)載自 http://www.ywnds.com/?p=12418
