記一次Flink CDC引起的MySQL元數據鎖事故，總結經驗教訓。后續在編寫Flink CDC任務時，要處理好異常，避免產生長時間的元數據鎖。同時出現生產問題時要及時排查，不能抱有僥幸心理。

一、事件經過

某天上午，收到系統的告警信息，告警提示：同步MySQL的某張表數據到Elasticsearch異常，提示連不上Mysql，當時沒有太上心，以為可能是偶爾網絡異常。

然后立馬大量用戶開始投訴系統使用有問題，同時聽到有同事反饋內部系統數據導不出來。此時我慌了。

立馬看了微服務網關、用戶中心服務、部分流量比較大的BFF層服務，CPU、內存、磁盤等都是正常的。但是Pod出現了健康檢查失敗的情況。

于是又趕緊看了日志，出現了大量拿不到MySQL Connection異常。

又趕緊看了MySQL情況，CPU、內存、磁盤都是正常的，但是出現了許多奇怪的慢SQL。

此時我大概猜測到了可能是什么操作鎖表了，導致大量Connection無法釋放，又趕緊看了Mysql鎖的情況，果然發現了大量的元數據鎖，高達400多個Connection沒釋放。

二、處理步驟

既然出現了元數據鎖，導致這么多Connection沒有釋放，那就找出占用時間最長的那個會話kill掉。陸續kill了幾個會話后，系統恢復了。

系統恢復后，又去看了慢SQL，發現主要有兩塊高頻慢SQL，一塊是Flink相關的，另一塊是Nacos相關的。后來經過分析：元數據鎖是因為Flink CDC執行FLUSH TABLES WITH READ LOCK導致的，跟Nacos無關，Nacos只是個煙霧彈。

# Flink相關的：
SHOW CREATE TABLE `xxx_db`.`xxx_table`;
FLUSH TABLES WITH READ LOCK;

# Nacos相關的：
DELETE FROM config_info WHERE data_id='com.alibaba.nacos.testMasterDB';

防止事故再次發生，又把Flink CDC任務里的SQL方式換成了API方式。Flink CDC使用SQL方式時，會產生大量任務，占用更多的資源，也容易出現任務異常。

三、原因分析

1.元數據鎖

(1) 以上關于鎖的截圖，可以看到是元數據鎖引發的Connection被耗盡，那什么是元數據鎖：

• 元數據鎖（Meta Data Lock，MDL），用于鎖定數據庫對象的元數據，例如：表、索引、視圖等的結構信息。通常用于保證并發的數據定義語言（DDL）操作的一致性，防止在修改表結構的過程中出現并發問題。
• 其作用是用于解決DDL操作與DML操作的一致性；通常，DDL操作需要獲取MDL寫鎖，并且MDL鎖一旦發生，就可能會對數據庫的性能影響，因為后續對該表的任何Select、DML、DDL操作都會被阻塞，造成Connection積壓。

(2) 為什么要有元數據鎖：

主要為了保證元數據的一致性，用于處理不同線程操作同一數據對象的同步與互斥問題。比如需要事務隔離場景、主從同步場景。

(3) 元數據鎖和Innodb鎖的區別：

• 元數據鎖主要關注數據庫對象的元信息，而InnoDB鎖主要關注數據的一致性和隔離性。
• MDL鎖還能實現其他粒度級別的鎖，比如：全局鎖、庫級別的鎖、表空間級別的鎖。這是InnoDB存儲引擎不能直接實現的。

(4) 鎖表的原理是數據庫使用獨占式鎖機制。鎖表發生在 insert、update、delete中。比如：A程序執行了對table_1的insert、update、delete，并還未commit時，B程序也對table_1進行insert、update、delete時會發生資鎖表。

2.Flink CDC為什么引起元數據鎖事故

筆者使用Flink場景是，利用Flink CDC同步數據，然后做匯總統計。

(1) MySQL CDC如何工作

• 在 CDC 過程中，Flink 需要定期讀取數據源的變化并進行處理。需要元數據鎖 確保在讀取元數據（例如數據庫表的結構信息）時，沒有其他并發的操作修改了這些元數據，從而保證 Flink 的元數據和實際數據的一致性。
• 啟動MySQL CDC源時，它將執行FLUSH TABLES WITH READ LOCK，獲取一個全局讀取鎖，防止其他會話對這些表進行寫操作，從而保證捕獲的數據的一致性和準確性。該鎖將阻止其他寫入操作。
• 然后，它讀取當前binlog位置以及數據庫和表的schema。
• 之后，將釋放全局讀取鎖。然后，它掃描數據庫表并從先前記錄的位置讀取binlog。
• 如果發生故障，任務將重新啟動。

(2) 元數據鎖原因

因為Flink CDC啟動時執行FLUSH TABLES WITH READ LOCK直接上讀取鎖，由于時間較長，此時有大量的insert、update、delete操作一直處于等待，導致Mysql Connection無法釋放。

正好此時，Flink CDC執行同步任務時，又出現了異常，然后任務重啟，重啟后是上鎖，結果出現了惡性循環。導致更多的的insert、update、delete操作處于等待，導致更多的Myql Connection無法釋放，直接Connection全部耗盡。

然后所有應用都拿不到Mysql Connection，所以系統徹底不可用了。

至于Nacos為什么會執行DELETE FROM config_info WHERE data_id='com.alibaba.nacos.testMasterDB'呢？查閱資料后發現，Nacos也是從Mysql獲取Connection的，當Mysql出現問題時，比如死鎖、Connection耗盡、CPU打滿時，都會執行這個SQL。