备份集过期时间_TiDB备份恢复方式你知多少?
背景
學習一款數據庫,要學會備份和恢復。備份是一個嚴謹的工作,作為一個dba,掌握數據庫備份、恢復的各種手段。
下面讓我們一起來看看TiDB的備份恢復有那些手段吧。
基于MVCC的恢復方式
相關原理已經在上一篇文章寫過了,這里就不在做過多的描述了。
TiDB用什么保證備份的一致性?
簡單的回顧一下,TiDB的TiKV里面的MVCC的格式是基于時間戳的。
(key-versionT(SO全局唯一遞增時間戳)-->vlues)
會有定時GC來清理過期的版本(數據)。
下面的工具都是基于MVCC的方式,假設數據以及被GC清理掉了,那么數據就不能恢復過來。
第一款工具 snapshot
TiDB自帶工具,可以針對當前會話讀到指定的歷史版本。
UPDATE mysql.tidb SET VARIABLE_VALUE = '80h' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
#更改GC時間
sql="SET SESSION tidb_snapshot = '415599012634951683'"。
#跳轉GC時間
#微信公眾號只能傳3個視頻,我把不能傳的視頻發百度云盤了
鏈接:https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ
提取碼:anxp
工具說明:只能恢復dml,不能恢復ddl。
第二款工具 RecoverTiDB自帶工具,可以針對drop ?table 語句進行恢復。drop table t2;#刪除表
recover table t2; #恢復表
#微信公眾號只能傳3個視頻,我把不能傳的視頻發百度云盤了
鏈接:https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ
提取碼:anxp
工具限制:只能恢復drop table的操作,不能恢復truncate table,delete操作。未來可能會被 Flashback取代。
第三款工具?Flashback
TiDB自帶工具,可以針對truncate操作。
工具限制:只能恢復truncate,drop等ddl的操作,沒有辦法恢復dml操作。工具總結:- 如果使用上述三種工具?要保證誤操作的范圍在GC清理之前。如果數據以及被GC清理了,則無法使用。
- 目前推薦大家要了解掌握上述三種工具的基礎的操作,避免在真正的誤操作發生的時候,能快速恢復。
./bin/mydumper -h 127.0.0.1 -u root -P 4000 #執行備份
./bin/loader -d 備份路徑 -h 127.0.0.1 -u root -P 4000 #恢復備份
#微信公眾號只能傳3個視頻,我把不能傳的視頻發百度云盤了
鏈接:https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ
提取碼:anxp
如果大家嫌棄導入慢,可以用TiDB官方推薦的生態工具TiDB Lightning 。能給提升TiDB的導入效率。
第二款工具TiDB binlogTiDB binlog,可以用于增量恢復TiDB集群。還可以適用于 TiDB同步下游TiDB集群、MySQL、Kafka。TiDB binlog分為2個組件Pump和Drainer 兩個組件,先給大家介紹一下。Pump組件:- 用于實時記錄TiDB產生的Binlog。
- 將binlog按照時間提交時間進行排序。
- 在提個給Drainer組件進行消費。
- 收集各個Pump中收集的Binlog進行歸并。
- 將Binlog轉行成SQL或者指定格式的數據。
TiDB最近提供的一款分布式備份恢復工具BR,可以針對TiDB集群進行備份和恢復。
使用限制:- 只支持TiDBv3.1及以上版本
- 目前需要nfs作為共享磁盤
- 從pd中獲取當前的TSO作為備份快照的時間點。
- 當前集群的TiKV節點信息。
[2020/04/04 17:16:37.610 +08:00] [INFO] [log-file=/tmp/br.log.2020-04-04T17:16:37+08:00] [pd="[10.206.0.3:2379]"] [storage=local:///export/backup] [timeago=0s]
#說明備份日志輸出位置,pd節點,備份結果集
[2020/04/04 17:16:37.612 +08:00] [INFO] [base_client.go:226] ["[pd] update member urls"] [old-urls="[http://10.206.0.3:2379]"] [new-urls="[http://10.206.0.16:2379,http://10.206.0.3:2379,http://10.206.0.6:2379]"]
#獲取整個pd集群
[2020/04/04 17:16:37.622 +08:00] [INFO] [ddl.go:321] ["[ddl] start DDL"] [ID=b823eca8-e3e5-4969-a67f-5ff3b6210d1d] [runWorker=false]
[2020/04/04 17:16:37.647 +08:00] [INFO] [domain.go:144] ["full load InfoSchema success"] [usedSchemaVersion=0] [neededSchemaVersion=87] ["start time"=5.263313ms]
[2020/04/04 17:16:37.648 +08:00] [INFO] [domain.go:368] ["full load and reset schema validator"]
#獲取對應的表結構
[2020/04/04 17:16:37.650 +08:00] [INFO] [client.go:112] ["backup encode timestamp"] [BackupTS=415758233800278018]
#獲取備份的時間點tso
[2020/04/04 17:16:37.657 +08:00] [INFO] [client.go:222] ["change table AutoIncID"] [db=tian] [table=t1] [AutoIncID=2000001]
#開始執行db為tian,table為t1的備份
這段話來自官方文檔,我簡單的描述,大家會更好的理解。此時根據備份子命令,會有兩種備份邏輯:
全量備份:BR 遍歷全部庫表,并且根據每一張表構建需要備份的 KV Range
單表備份:BR 根據該表構建需要備份的 KV Range
最后,BR 將需要備份的 KV Range 收集后,構造完整的備份請求分發給集群內的 TiKV 節點。
https://pingcap.com/docs-cn/dev/reference/tools/br/br/
- 每個Region都有Region Leader,每個Region Leader都分布在不同的TiKV上。
- BR 首先知道備份哪些KV Range,然后把備份的KV Range收集后。構建一個完整的備份請求,下發給所有的TiKV節點。
- TiKV收到這些備份請求,開始執行備份命令。
[2020/04/04 19:17:30.808 +08:00] [INFO] ["Full backup Success summary: total backup ranges: 15,total success: 15, total failed: 0, total take(s): 544.32, total kv: 285323076, total size(MB): 58774.74, avg speed(MB/s): 107.98"]["backup checksum"=1m51.113016071s]["backup fast checksum"=59.215757ms]["backup total regions"=699]備份時性能影響:br備份影響相對較小,因為備份指令都下發到不同的TiKV節點,TiKV會承擔備份壓力。
總結相信大家看了這么多內容,大家應該會TiDB備份恢復方式有了一定的了解。可以對集群設置N個小時的GC超時時間:沒超過這N個小時的誤操作,可以通過基于MVCC的方式進行恢復。可以根據不同的語句來,選擇不同的恢復方式。如果超過了N個小時,可以選擇binlog的方式進行增量恢復。mydumper和br工具,我個人感覺更適合- 災難式恢復(整個集群都掛了,例如所有磁盤壞了,機柜宕機。但TiDB本身就是分布式,所以這個可能性不大。
- 構建新的集群,做集群之間的同步。
總結
以上是生活随笔為你收集整理的备份集过期时间_TiDB备份恢复方式你知多少?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 猫眼石手镯一般多少钱
- 下一篇: windows优化大师8周年纪念版_《数