TiDB用什么保證備份的一致性，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

站在用戶的角度思考問題，與客戶深入溝通，找到郎溪網(wǎng)站設(shè)計與郎溪網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站建設(shè)、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)站空間、企業(yè)郵箱。業(yè)務(wù)覆蓋郎溪地區(qū)。

背景

作為一名MySQL DBA，就應(yīng)該了解MySQL備份無論是邏輯備份還是物理備份，都會使用FLUSH TABLES WITH READ LOCK（下面簡稱FTWRL）鎖來保證數(shù)據(jù)庫備份的一致性。

描述FTWRL鎖對一致性的影響

先拿，MySQL邏輯備份MySQLDump舉例。

MySQLDump，為了保證備份一致性，需要添加2個參數(shù)     

--single-transaction  --master-data=2 。

在開啟--single-transaction后，MySQLDump的備份流程大概就是，在MySQL中會執(zhí)行如下操作。

1、刷新表flush tables 用來防止DDL操作。

2、執(zhí)行FTWRL鎖，這個時候整個數(shù)據(jù)庫整體被鎖住，讓數(shù)據(jù)庫處于一個一致性的狀態(tài)。

3、設(shè)置當(dāng)前session（回話）事務(wù)的隔離級別為RR。

4、記錄當(dāng)前的MySQLbinlog的位置，或者GTID信息。

5、解鎖。#從加鎖到解鎖執(zhí)行速度會很快，前提是沒有鎖沖突，如果有鎖沖突，就會到鎖等待的一個狀態(tài)。

物理備份xtrabackup，物理備份執(zhí)行FTWRL鎖的時間相對較長，下面來看一下xtrabackup對FTWRL鎖的流程。

•  執(zhí)行FTWRL鎖。

•  拷貝frm、MYD、MYI、etc拷貝。

•  等待redo的拷貝完成。

•  記錄當(dāng)前的MySQLbinlog的位置，或者GTID信息。

•  解鎖。

xtrabackup加鎖是為了保證在數(shù)據(jù)庫中如果有MyiSAM表，盡量保證MyiSAM表的備份一致性。

#之前有個同學(xué)說。物理備份加FTWRL鎖會比邏輯備份加鎖時間短，這個結(jié)論其實是錯誤的。物理備份加鎖的時間完全取決一下當(dāng)前數(shù)據(jù)庫里有沒有MyiSAM表，MyiSAM表的大小。

TiDB是用什么保證數(shù)據(jù)庫一致性的

先說TiDB官方推薦的邏輯備份mydumper， 一開始我以為mydumper也是用FTWRL鎖來保證備份的一致性。結(jié)果我今天在看文檔的時候發(fā)現(xiàn)，這個結(jié)論是錯誤的。

官方對mydumper進行了優(yōu)化和修改。先看一下官方的描述。下面內(nèi)容來自TiDB官方文檔。

1、對于 TiDB 可以設(shè)置 tidb_snapshot 的值指定備份數(shù)據(jù)的時間點，從而保證備份的一致性，而不是通過 FLUSH TABLES WITH READ LOCK 來保證備份一致性。

2、使用 TiDB 的隱藏列 _tidb_rowid 優(yōu)化了單表內(nèi)數(shù)據(jù)的并發(fā)導(dǎo)出性能。

大家先記住 TiDB 是通過 tidb_snapshot，來實現(xiàn)備份，而不是FTWRL鎖來保證。這么設(shè)計會有什么問題？能保證數(shù)據(jù)備份的一致性嗎？

要解答這個問題，要簡單說一下TiDB的架構(gòu)設(shè)計。

TiDB的存儲節(jié)點是TiKV，下面主要針對TiKV來說。先把TiKV，理解為很大的一個Key-value的存儲器。

（圖1選自TiDB官方文檔）

這塊跟備份其實沒有什么關(guān)系，先讓大家大概了解一下TiKV存什么。

下面的內(nèi)容就跟備份有關(guān)系了，TiDB 的MVCC(多版本控制器）實現(xiàn)是在TiKV中。TiKV中加了MVCC，key和value這樣的。

我認(rèn)為version就是TSO（全局唯一遞增時間戳），我是通過TiDB二階段提交中發(fā)現(xiàn)的。

如果不是的話version的版本信息就會存在PD里面，這樣設(shè)計的話會增加PD的壓力，感覺不現(xiàn)實。

針對上面描述有一個小的結(jié)論TiKV里面會存儲歷史key的信息。

下面還是來一個問答來解答上面的疑問。

問：TiDB是通過什么來保證數(shù)據(jù)的一致性的？

答：是基于TiKV里面的MVCC來保證的，根據(jù)當(dāng)前的的時間戳信息，來下發(fā)命令 

sql="SET SESSION tidb_snapshot = '415599012634951683'"。

這個session就會讀到這個時間點的歷史版本的數(shù)據(jù)。

下一步的操作，只要把所有的表和里面的數(shù)據(jù)掃出來就可以了。

問：通過MVCC實現(xiàn)的備份，能達(dá)到一致性嗎？(因為沒有鎖)

答：是可以的，大家可以看一下我之前寫的《淺析TiDB二階段提交》那篇文章中里面有寫到，只有事務(wù)成功提交才能會寫入到TiKV中，才會有TSO(全局唯一遞增時間戳)。也就是TiKV中里面的key都是成功提交的。

那么在備份的過程中提交的成功的事務(wù)是不會被掃到的。

因為備份過程中提交的事務(wù)的tso(全局唯一遞增時間戳)會大于當(dāng)前的備份發(fā)起的tso(全局唯一遞增時間戳)。

問: 使用了MVCC的備份方式，會有哪些問題?

答：我認(rèn)為最大的問題就是 在備份的過程中老的key被GC(垃圾清理)掉，解決這個問題的最好的辦法，可以把GC(垃圾清理)時間設(shè)置的長一點。

UPDATE mysql.tidb SET VARIABLE_VALUE = '800h' WHERE VARIABLE_NAME = 'tikv_gc_life_time';

可以設(shè)置為800h（根據(jù)時間情況而定），備份結(jié)束后要修改回來，否則會浪費存儲空間。

通過上面的描述，大家應(yīng)該會了解到TiDB對備份的一致性處理的相關(guān)細(xì)節(jié)。

在TiDB4.0的分布式備份恢復(fù)工具br，在這塊處理是類似的。也是利用MVCC的方式來實現(xiàn)的。

最后在安利一下TiDB4.0的備份工具br。備份的速度快，消耗資源相對較低。下面的案例僅供參考大家感興趣的話 我可以做一下詳細(xì)的測試，留言刷起來。

機器描述：三臺騰訊云4C8G SSD50G，Sysbench 壓力10張表每張表1千萬條數(shù)據(jù)。

整體大概5分鐘左右，brlog里面會記錄相關(guān)信息。

開始時間16:44:27.009 結(jié)束時間16:49:40.395

相同環(huán)境我用mydumper測，mydumper運行在tidb的節(jié)點上。

mydumper是4個線程數(shù)(默認(rèn)線程數(shù))

他備份的過程中把tidb壓的OOM了。

#可以用-r參數(shù)控制每個并發(fā)處理的數(shù)據(jù)量來避免。

大概是我的機器配置低，而且mydumper和tidb-server是同一臺機器。

關(guān)于TiDB用什么保證備份的一致性問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。

分享標(biāo)題：TiDB用什么保證備份的一致性
網(wǎng)頁URL：http://chinadenli.net/article4/joiiie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、搜索引擎優(yōu)化、品牌網(wǎng)站建設(shè)、電子商務(wù)、面包屑導(dǎo)航、全網(wǎng)營銷推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)