共計 2526 個字符，預計需要花費 7 分鐘才能閱讀完成。
TiDB 用什么保證備份的一致性，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
背景
作為一名 MySQL DBA，就應該了解 MySQL 備份無論是邏輯備份還是物理備份，都會使用 FLUSH TABLES WITH READ LOCK（下面簡稱 FTWRL）鎖來保證數據庫備份的一致性。
描述 FTWRL 鎖對一致性的影響
先拿，MySQL 邏輯備份 MySQLDump 舉例。
MySQLDump，為了保證備份一致性，需要添加 2 個參數
–single-transaction –master-data=2。
在開啟 –single-transaction 后，MySQLDump 的備份流程大概就是，在 MySQL 中會執行如下操作。
1、刷新表 flush tables 用來防止 DDL 操作。
2、執行 FTWRL 鎖，這個時候整個數據庫整體被鎖住，讓數據庫處于一個一致性的狀態。
3、設置當前 session（回話）事務的隔離級別為 RR。
4、記錄當前的 MySQLbinlog 的位置，或者 GTID 信息。
5、解鎖。# 從加鎖到解鎖執行速度會很快，前提是沒有鎖沖突，如果有鎖沖突，就會到鎖等待的一個狀態。
物理備份 xtrabackup，物理備份執行 FTWRL 鎖的時間相對較長，下面來看一下 xtrabackup 對 FTWRL 鎖的流程。
執行 FTWRL 鎖。
拷貝 frm、MYD、MYI、etc 拷貝。
等待 redo 的拷貝完成。
記錄當前的 MySQLbinlog 的位置，或者 GTID 信息。
解鎖。
xtrabackup 加鎖是為了保證在數據庫中如果有 MyiSAM 表，盡量保證 MyiSAM 表的備份一致性。
# 之前有個同學說。物理備份加 FTWRL 鎖會比邏輯備份加鎖時間短，這個結論其實是錯誤的。物理備份加鎖的時間完全取決一下當前數據庫里有沒有 MyiSAM 表，MyiSAM 表的大小。
TiDB 是用什么保證數據庫一致性的
先說 TiDB 官方推薦的邏輯備份 mydumper，一開始我以為 mydumper 也是用 FTWRL 鎖來保證備份的一致性。結果我今天在看文檔的時候發現，這個結論是錯誤的。
官方對 mydumper 進行了優化和修改。先看一下官方的描述。下面內容來自 TiDB 官方文檔。
1、對于 TiDB 可以設置 tidb_snapshot 的值指定備份數據的時間點，從而保證備份的一致性，而不是通過 FLUSH TABLES WITH READ LOCK 來保證備份一致性。
2、使用 TiDB 的隱藏列 _tidb_rowid 優化了單表內數據的并發導出性能。
大家先記住 TiDB 是通過 tidb_snapshot，來實現備份，而不是 FTWRL 鎖來保證。這么設計會有什么問題？能保證數據備份的一致性嗎？
要解答這個問題，要簡單說一下 TiDB 的架構設計。
TiDB 的存儲節點是 TiKV，下面主要針對 TiKV 來說。先把 TiKV，理解為很大的一個 Key-value 的存儲器。
（圖 1 選自 TiDB 官方文檔）
這塊跟備份其實沒有什么關系，先讓大家大概了解一下 TiKV 存什么。
下面的內容就跟備份有關系了，TiDB 的 MVCC(多版本控制器）實現是在 TiKV 中。TiKV 中加了 MVCC，key 和 value 這樣的。
我認為 version 就是 TSO（全局唯一遞增時間戳），我是通過 TiDB 二階段提交中發現的。
如果不是的話 version 的版本信息就會存在 PD 里面，這樣設計的話會增加 PD 的壓力，感覺不現實。
針對上面描述有一個小的結論 TiKV 里面會存儲歷史 key 的信息。
下面還是來一個問答來解答上面的疑問。
問：TiDB 是通過什么來保證數據的一致性的？
答：是基于 TiKV 里面的 MVCC 來保證的，根據當前的的時間戳信息，來下發命令
sql= SET SESSION tidb_snapshot = 415599012634951683。這個 session 就會讀到這個時間點的歷史版本的數據。
下一步的操作，只要把所有的表和里面的數據掃出來就可以了。
問：通過 MVCC 實現的備份，能達到一致性嗎？(因為沒有鎖)
答：是可以的，大家可以看一下我之前寫的《淺析 TiDB 二階段提交》那篇文章中里面有寫到，只有事務成功提交才能會寫入到 TiKV 中，才會有 TSO(全局唯一遞增時間戳)。也就是 TiKV 中里面的 key 都是成功提交的。
那么在備份的過程中提交的成功的事務是不會被掃到的。
因為備份過程中提交的事務的 tso(全局唯一遞增時間戳) 會大于當前的備份發起的 tso(全局唯一遞增時間戳)。
問: 使用了 MVCC 的備份方式，會有哪些問題?
答：我認為最大的問題就是 在備份的過程中老的 key 被 GC(垃圾清理) 掉，解決這個問題的最好的辦法，可以把 GC(垃圾清理) 時間設置的長一點。
UPDATE mysql.tidb SET VARIABLE_VALUE = 800h WHERE VARIABLE_NAME = tikv_gc_life_time可以設置為 800h（根據時間情況而定），備份結束后要修改回來，否則會浪費存儲空間。
通過上面的描述，大家應該會了解到 TiDB 對備份的一致性處理的相關細節。
在 TiDB4.0 的分布式備份恢復工具 br，在這塊處理是類似的。也是利用 MVCC 的方式來實現的。
最后在安利一下 TiDB4.0 的備份工具 br。備份的速度快，消耗資源相對較低。下面的案例僅供參考大家感興趣的話 我可以做一下詳細的測試，留言刷起來。
機器描述：三臺騰訊云 4C8G SSD50G，Sysbench 壓力 10 張表每張表 1 千萬條數據。
整體大概 5 分鐘左右，brlog 里面會記錄相關信息。
開始時間 16:44:27.009 結束時間 16:49:40.395
相同環境我用 mydumper 測，mydumper 運行在 tidb 的節點上。
mydumper 是 4 個線程數 (默認線程數)
他備份的過程中把 tidb 壓的 OOM 了。
# 可以用 - r 參數控制每個并發處理的數據量來避免。
大概是我的機器配置低，而且 mydumper 和 tidb-server 是同一臺機器。
關于 TiDB 用什么保證備份的一致性問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業資訊頻道了解更多相關知識。
