監控DB由於使用的TokuDB引擎，因此選擇使用Percona MySQL 5.7版本，在使用過程中遇到了比較多的坑，在這里做一下簡單的記錄，希望對廣大DBA有幫助。
load文件飆升導致的DB雪崩
在上層機器（mqproxy）出問題的時候，會導致load文件飆升，導致監控DB大量的load線程堆積，造成監控DB雪崩，比如2月15號的一次異常：
DB雪崩的時候有大量的load線程堆積，並且機器的寫入性能之前下降，直到超過最大連接數，業務無法訪問。
這種場景的解決辦法有兩個：
1、業務上層進行控制，對DB進行保護，控制load的線程數或者文件數
2、DB啟用線程池，控制DB並發load的線程數
目前DB已經完成2的改造，1的改造也正在進行中。
使用線程池內存問題
出於對DB做保護，我們准備在監控DB啟用線程池功能。為了安全起見，先在從機啟用，並進行持續觀察，在觀察的過程中發現在啟用了線程池以后，內存飆升了8G左右，如下圖：
不但啟用線程池后內存飆升了8G左右，而且內存還在持續增長，很明顯啟用線程池后存在內存泄漏了。
這個問題在網上也有不少的人遇到，確認是percona的bug導致（https://jira.percona.com/browse/PS-3734），只有開啟Performance_Schema和ThreadPool的時候才會出現，解決辦法是關閉Performance_Schema即可，具體操作方法是在配置文件添
加performance_schema=off
然后重啟MySQL就OK。下面是關閉PS后的內存使用情況對比：
線程池啟用后的高可用探測問題
在描述問題之前，先來描述一下線程池是如何分配連接和控制的：
線程池會根據參數thread_pool_size的大小分成若干的group，每個group各自維護客戶端發起的連接，當客戶端發起連接到MySQL的時候，MySQL會跟進連接的線程id（thread_id）對thread_pool_size進行去模，從而落到對應的group。thread_pool_oversubscribe參數控制每個group的最大並發線程數，每個group的最大並發線程數為thread_pool_oversubscribe+1個，若對應的group達到了最大的並發線程數，則對應的連接就需要等待。
在線上配置了幾組機器使用線程池后，發現有1組機器發生自動切換，排查了機器的負載、MySQL錯誤日志、操作系統日志、高可用日志以后，確定是由於啟用線程池問題導致，具體的原因描述如下：
啟用線程池以后，相當於限制了MySQL的並發線程數，當達到最大線程數的時候，其他的線程需要等待，新連接也會卡在連接驗證那一步，這時候會造成撥測程序連接MySQL超時，撥測程序連接實例超時后，就會認為master已經出現問題，從而啟動自動切換的操作，將業務切換到從機。
這種情況有兩種解決辦法：
1、啟用MySQL的旁路管理端口，監控和高可用相關直接使用MySQL的旁路管理端口
具體做法為是在my.cnf中添加如下配置后重啟，就可以通過旁路端口登錄MySQL了，不受線程池最大線程數的影響：
extra_max_connections = 8
extra_port = 33333
備注：建議啟用線程池后，這個也添加上，方便緊急情況下進行故障處理。
2、修改高可用探測腳本，將達到線程池最大活動線程數返回的錯誤做異常處理，類似於當作超過最大連接數的場景（備注：超過最大連接數只告警，不進行自動切換）
監控這邊選擇了解決方法2，因為這種方式改動量最小。
簡單總結
以上就是最近使用Percona MySQL時候遇到的幾個問題，通過這幾個問題概括出幾個需要廣大DBA們注意的事情：
1、上層應該對DB進行保護，防止DB出現雪崩
2、在上新功能的時候，一定記得灰度、灰度、灰度
3、灰度的時候，注意密切觀察線上DB的性能指標（內存、性能、IO以及其他和變更相關的指標）
4、綜合考慮各種解決方案，選擇最適合的方案
作者：飛鴻無痕
鏈接：https://www.jianshu.com/p/33a0997ced0e
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。