## 問題背景 一個用戶自建MySQL，出現備庫復制中斷的問題，報錯為slave sql thread 錯誤，The total number of locks exceeds the lock table size。 ## 報錯代碼 這個報錯在代碼中的拋錯邏輯為： ~~~ if UT_LIST_GET_LEN(buf_pool->free) + UT_LIST_GET_LEN(buf_pool->LRU) < buf_pool->curr_size / 4 ~~~ 文字解釋是：如果buffer pool中的空閑頁面和LRU頁面總和少于buffer pool 大小的1/4，則認為內存不夠用，報錯。 ## 那么問題來了 1. buffer pool 哪里去了 buffer pool是InnoDB內部管理內存的統一結構。默認每個page 16k。初始化后，每個page都是空閑狀態，放在free中。 當讀取數據等需要用到頁面數據的操作時，將數據從磁盤讀取到內存中，用的就是buffer pool的page。為了支持淘汰機制，InnoDB內部維護了一個淘汰鏈表，就是LRU list。裝了數據的page被從free list移到LRU list。 但是，除了正常的讀取數據，還有其他的邏輯需要從buffer pool中“搶”資源。比如本例中是因為undo page。 事務越大，需要的undo page越多，在整個事務未提交前，undo page是必須強占內存的。這就可能導致一種情況：事務過大，導致buffer pool全部被用光，無法提供正常服務。 因此InnoDB有了上面的保護機制。觸發這個上限后報錯后，事務會回滾，釋放undo page。 2. 為什么主庫執行成功備庫失敗了 從上面的分析和代碼中可以看到，判斷內存是否占用過多，設置的上限是buffer_pool size的1/4.? 另外，5.6以后支持了設置多個 innodb_buffer_pool_instances，也就是分成多個pool， 在現在的邏輯中，認為只要“任意一個pool滿足上述超過1/4的條件”，都判定為內存消耗過限。 因此主要排查參數： * 備庫的 innodb_buffer_pool_size 是否小于主庫值 * 若主備的innodb_buffer_pool_size值相同，備庫的 innodb_buffer_pool_instances 值是否更大。 3. 作為驗證 DBA在發現備庫apply error的時候第一步往往是用 mysqlbinlog 工具去看導致錯誤的event是什么。這時候會發現其實是一個批量的load數據，或者update/delete大事務導致。 ## 小結 1. buffer pool不僅用于緩存page，會有其他數據結構爭搶； 2. 主備的參數盡量保持一致； 3. 盡量避免超大事務，即使不考慮備庫apply error。這種超大事務在主庫執行，由于undo page占用buffer pool，可能會導致buffer pool命中率突然下降，影響業務。