很久很久以前，核心君發表了一篇ha方案·tokudb熱備的文章，方法很簡單：
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;
問題來了。
當某個例項的資料量達到tb級，你會發現備庫(基於備份)重搭後，啟動會灰常灰常慢，因為他們都在recover redo-log，為什麼呢？
1) set tokudb_checkpoint_lock=on;
2) 開始拷貝tokudb的資料檔案(不包含日誌檔案)
-- 由於拷貝tb級的資料非常耗時，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檔案(分割槽表檔案)，使用熱備的資料備庫重搭後，複製過程中偶爾會出現"duplicate entry ... for key 'primary'"錯誤。
引起這個錯誤的原因比較深，觸發自tokudb內部機制。
為了解決這個問題，我們在熱備的過程中引入乙個狀態：in_backup = true，防止檔案關閉做checkpoint操作，具體的patch見這裡:
這樣tokudb的熱備就比較完美了，整個熱備過程中，所有的資料檔案均處於乙個「一致性」狀態，所有的操作都在redo-log裡，不再汙染資料檔案。
TokuDB引擎筆記
client port 3306 socket tmp mysql.sock mysqld port 3306 socket tmp mysql.sock skip external locking max allowed packet 1m myisam sort buffer size 64m ...
TokuDB引擎啟動失敗解決
tokudb引擎修改資料儲存目錄引數特別複雜，稍不留神，tokudb引擎就無法啟動了。怎麼折騰都不能修改目錄引數，也不能啟動的情況下，可以解除安裝掉重灌。本文記錄今天填坑的經歷，解除安裝重灌後再修改目錄。啟動失敗的情況下，var log mysqld.log中有這個錯 error tokudb re...
TokuDB 引擎特性 zstd壓縮演算法
tokudb有著出色的壓縮特性，這不是 蓋 的 rds上有個innodb例項，1天的資料將近700gb空間，換成tokudb後 預設zlib壓縮 同樣的700gb可以儲存 天的資料，業務讀寫效能也無任何影響，空間成本直線下降。為什麼tokudb的壓縮這麼給力？因為tokudb乙個 頁 的大小為4mb...