背景

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

描述FTWRL鎖對(duì)一致性的影響

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

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

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

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

1、刷新表flush tables 用來(lái)防止DDL操作。

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

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

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

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

物理備份xtrabackup，物理備份執(zhí)行FTWRL鎖的時(shí)間相對(duì)較長(zhǎng)，下面來(lái)看一下xtrabackup對(duì)FTWRL鎖的流程。

•  執(zhí)行FTWRL鎖。
•  拷貝frm、MYD、MYI、etc拷貝。
•  等待redo的拷貝完成。
•  記錄當(dāng)前的MySQLbinlog的位置，或者GTID信息。
•  解鎖。

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

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

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

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

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

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

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

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

要解答這個(gè)問(wèn)題，要簡(jiǎn)單說(shuō)一下TiDB的架構(gòu)設(shè)計(jì)。

TiDB的存儲(chǔ)節(jié)點(diǎn)是TiKV，下面主要針對(duì)TiKV來(lái)說(shuō)。先把TiKV，理解為很大的一個(gè)Key-value的存儲(chǔ)器。

（圖1選自TiDB官方文檔）

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

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

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

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

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

下面還是來(lái)一個(gè)問(wèn)答來(lái)解答上面的疑問(wèn)。

問(wèn)：TiDB是通過(guò)什么來(lái)保證數(shù)據(jù)的一致性的？

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

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

這個(gè)session就會(huì)讀到這個(gè)時(shí)間點(diǎn)的歷史版本的數(shù)據(jù)。

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

問(wèn)：通過(guò)MVCC實(shí)現(xiàn)的備份，能達(dá)到一致性嗎？(因?yàn)闆](méi)有鎖)

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

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

因?yàn)閭浞葸^(guò)程中提交的事務(wù)的tso(全局唯一遞增時(shí)間戳)會(huì)大于當(dāng)前的備份發(fā)起的tso(全局唯一遞增時(shí)間戳)。

問(wèn): 使用了MVCC的備份方式，會(huì)有哪些問(wèn)題?

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

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

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

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

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

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

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

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

開(kāi)始時(shí)間16:44:27.009 結(jié)束時(shí)間16:49:40.395

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

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

他備份的過(guò)程中把tidb壓的OOM了。

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

大概是我的機(jī)器配置低，而且mydumper和tidb-server是同一臺(tái)機(jī)器，這塊只是給大家提供一個(gè)參考。這塊我在后續(xù)測(cè)一下吧，會(huì)有一個(gè)完整的測(cè)試?yán)?，目前備份工具還是推薦mydumper。