## 問題描述 某TokuDB實例備庫發生復制中斷,報錯信息甚是詭異： ~~~ Error executing row event: "Can't lock file (errno: 22 - Invalid argument)" ~~~ 經過gdb core后，大體知道了發生錯誤的原因： TokuDB在創建子事務的時候，由于嵌套事務過多，FT-index直接返回了錯誤（TokuDB的嵌套事務最多允許256個，嵌套事務數目的類型為uint8_t）導致。 比較詭異的是主庫一切正常，無任何錯誤。 經過溝通，發現用戶使用了大量的savepoint，這是一個突破點。 ## Savepoint機制 在TokuDB里savepoint的機制是個啥樣子呢？ 這里我們分兩種情況來處理，先來看第一種，SQL1： ~~~ set autocommit=0; savepoint s0; insert into tb1 values(0); release savepoint s0; savepoint s1; insert into tb1 values(1); release savepoint s1; ... commit; ~~~ TokuDB將會這樣處理： ~~~ a) savepoint s0： 創建s0子事務 b) release savepoint s0的時候： commit當前s0事務 c) savepoint s1： 創建s1子事務(此時s0子事務已不存在，已提交) d) release savepoint s1的時候： commit當前s1事務 ~~~ savepoint 間的事務并非嵌套，而是用完就釋放，然后再重新創建，這樣不會導致事務棧溢出。 再來看另外一種情況，SQL2： ~~~ set autocommit=0; savepoint s0; insert into tb1 values(0); savepoint s1; insert into tb1 values(1); savepoint s2; insert into tb1 values(2); ... commit; ~~~ 這種SQL TokuDB的處理方式是： ~~~ a) savepoint的時候： s1是s0的子事務，s2是s1的子事務，就這樣嵌套下去直到事務棧溢出... b) commit的時候： 會先提交s2，然后提交s1，然后提交s0，最后整個事務提交 ~~~ ## 問題解決 針對開始時的問題，TokuDB內核君進行了大膽猜測： ~~~ 在主庫執行的是SQL1，一切正常； 在備庫執行的是SQL2，事務棧溢出了； ~~~ 通過翻看 binlog 代碼印證了我們的猜測，在 sql/binlog.cc 里只實現了?`binlog_savepoint_set`?方法，只記錄savepoint event到binlog，而未記錄release savepoint event！ 由于savepoint實現機制不同，對InnoDB引擎來說是沒有問題的，但對 TokuDB 來說就是災難了。解決辦法就是實現`binlog_savepoint_release`方法，記錄release savepoint event到binlog。 ApsaraDB MySQL 5.6 最新版已修復這個問題，對savepoint有需求的TokuDB用戶(InnoDB不受影響)做下升級即可。 本篇小文從一個用戶引發的問題出發，討論了TokuDB的savepoint機制，當然TokuDB內核組的同學每天都會處理很多類似的問題，從發現問題到解決問題，以及持續的優化，為的就是給大家提供一種“飛”的感覺。有大數據量存儲的同學不妨試試我們的 TokuDB 引擎，存儲成本大大降低，順便體驗一把下一代存儲引擎帶來的“優越感”（注意，這不是廣告）。 最后廣告還是來了： 我們的PB級云數據庫?[PetaData已開始公測](https://www.aliyun.com/product/petadata)，底層采用TokuDB引擎，存儲介質是普通的SATA盤，有興趣的同學可以去圍觀下。