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