## 前言 很久很久以前，內核君發表了一篇[HA方案·TokuDB熱備](http://mysql.taobao.org/index.php?title=MySQL%E5%86%85%E6%A0%B8%E6%9C%88%E6%8A%A5_2014.09#TokuDB.C2.B7_HA.E6.96.B9.E6.A1.88.C2.B7TokuDB.E7.83.AD.E5.A4.87)的文章，方法很簡單： 1. SET TOKUDB_CHECKPOINT_LOCK=ON; 2. 開始拷貝TokuDB的數據文件(不包含日志文件)； 3. FLUSH TABLES WITH READ LOCK; 4. 記錄binlog位置，拷貝最新的binlog和TokuDB的日志文件(*.tokulog)； 5. UNLOCK TABLES; 6. SET TOKUDB_CHECKPOINT_LOCK=OFF; 這些步驟可以很方便的嵌入到Percona XtraBackup中，與InnoDB一起工作，目前看是一個比較簡單可行的方案。 ## 大實例備份恢復問題 問題來了。 當某個實例的數據量達到TB級，你會發現備庫(基于備份)重搭后，啟動會灰常灰常慢，因為他們都在recover redo-log，為什么呢？ 1. SET TOKUDB_CHECKPOINT_LOCK=ON; 2. 開始拷貝TokuDB的數據文件(不包含日志文件)，由于拷貝TB級的數據非常耗時，redo log持續增加甚至上萬個 當TokuDB啟動后，掃描和recover這幾萬個redo log將是災難性的。 解決這個問題比較簡單，我們稍微調整下熱備的順序即可： 1. SET TOKUDB_CHECKPOINT_LOCK=ON; 2. FLUSH TABLES WITH READ LOCK; 3. 記錄binlog位置，拷貝最新的binlog和TokuDB的日志文件(*.tokulog)； 4. UNLOCK TABLES; 5. 開始拷貝TokuDB的數據文件(不包含日志文件) –移動到這里 6. SET TOKUDB_CHECKPOINT_LOCK=OFF; 這樣在拷貝TokuDB數據文件的時候，就跟redo-log沒半毛錢關系了，而且拷貝的redo-log數也大大減少！ ## 優化改進 本以為這樣就可以早點下班回家，但問題還是來。 某實例有幾十萬個TokuDB文件(分區表文件)，使用熱備的數據備庫重搭后，復制過程中偶爾會出現”Duplicate entry … for key ‘PRIMARY’“錯誤。 引起這個錯誤的原因比較深，觸發自TokuDB內部機制。 TokuDB每個分區表有數個文件組成（想了解TokuDB數據庫文件的請[輕戳這里](http://mysql.taobao.org/monthly/2015/09/10/)），當分區表非常多的時候，打開的文件句柄數會非常多，受限于`open_files_limit`配置，TokuDB底層會觸發句柄關閉機制，對當前文件進行checkpoint操作(新數據被刷到磁盤且生效)再做close，這樣即使拿到checkpoint鎖后，還是有數據被寫入，就引發了以上問題。 為了解決這個問題，我們在熱備的過程中引入一個狀態：in_backup = true，防止文件關閉做checkpoint操作，具體的patch見[這里](https://github.com/percona/PerconaFT/pull/331/files)。 這樣TokuDB的熱備就比較完美了，整個熱備過程中，所有的數據文件均處于一個“一致性”狀態，所有的操作都在redo-log里，不再污染數據文件。