本文簡述下之前我們線上頻繁碰到的“UNABLE TO PURGE A RECORD”的原因

###################################################

線上實例錯誤日志中偶爾出現 “UNABLE TO PURGE A RECORD”，從官方bug系統來看，很多用戶都遇到了類似的問題。

當change buffer模塊以如下序列來緩存索引操作時：

1. 記錄被標記刪除（IBUF_OP_DELETE_MARK）
2. 隨后插入相同記錄–IBUF_OP_INSERT
3. Purge線程需要物理刪除二級索引記錄，操作被buffer–IBUF_OP_DELETE

當讀入物理頁時，需要進行ibuf merge，當執行到IBUF_OP_DELETE時，發現記錄并沒有被標記刪除，導致錯誤日志報錯。

顯然上述的操作序列是不合理的，正確的序列應該是IBUF_OP_DELETE_MARK，IBUF_OP_DELETE，IBUF_OP_INSERT。

為了理清邏輯，我們簡單的理一下相關代碼

注意IBUF_OP_DELETE是由第一步的標記刪除操作觸發，Purge線程發起；在每個buffer pool的控制結構體中，有一個成員buf_pool->watch[BUF_POOL_WATCH_SIZE]，BUF_POOL_WATCH_SIZE的值為purge線程個數，用于輔助Purge操作。

假定內存中沒有對應的Page，Purge線程會做如下幾件事兒：

• 首先查詢buffer pool，看看page是否已經讀入內存；

如果不在內存中，則將page no等信息存儲到watch數組中，并插入page hash（buf_pool_watch_set）。如果隨后page被讀入內存，就會刪除watch標記。

• 判斷該二級索引記錄是否可以被Purge（row_purge_poss_sec，當該二級索引記錄對應的聚集索引記錄沒有delete mark并且其trx id比當前的purge view還舊時，不可以做Purge操作）

• 隨后，再插入IBUF_OP_DELETE類型的ibuf記錄時，還會double check下該page是否被設為sentinel （ibuf_insert_low，buf_pool_watch_occurred），如果未被設置，表明已經page已經讀入內存，就可以直接去做purge，而無需緩存了。

• 對于普通的操作類型，例如IBUF_OP_INSERT和IBUF_OP_DELETE_MARK，同樣也會double check page 是否讀入了內存。在函數ibuf_insert中會調用buf_page_hash_get進行檢查， 如果page被讀入內存，則不緩存操作，如果請求的Page被設為sentinel，則從buf_page_hash_get返回NULL，因此隨后判定需要緩存操作。這也正是問題的所在：

1. 標記刪除記錄，寫入IBUF_OP_DELETE_MARK
2. Purge線程設置page對應的sentinel，完成合法性檢查，準備調用ibuf_insert
3. 插入相同記錄，寫入IBUF_OP_INSERT
4. Purge線程寫入IBUF_OP_DELETE

解決

如果記錄所在的page被設置了一個sentinel，那么對該page的并發插入操作就不應該緩存到change buffer中，而是直接去嘗試讀取物理頁。

https://github.com/mysql/mysql-server/commit/ec369cb4f363161dfbbbd662b20763b54808b7d1