Percona server of Mysql 特異功能與多角度思考是怎樣的

這篇文章給大家介紹Percona server of Mysql 特異功能與多角度思考是怎樣的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。 

使用MYSQL 的DBER們都對大事務和關于BINLOG 的 expire_log_days 或者更新的Binlog_expire_logs_seconds(MYSQL8)

中的管控BINLOG 的保留問題及管控或多或少都有一絲的不確定

問題

1  到底BINLOG 保留的天數和實際存儲了多少BINLOG SIZE 有沒有直接的聯系

2  我設置了較短的expire_log_days 到底會不會還發生 binlog 暴漲造成的數據庫DOWN機的問題

3  我怎么能保證就算有大事務和業務暴漲引起的BINLOG暴漲及時的保證業務的不停機的情況下，自動的先解決超出存儲警戒線的BINLOG。

OK 如果你安裝了官方版本的MYSQL，你就略過此篇文章，因為可能下面的方法不能奏效。如果你碰巧和我一樣公司部署的MYSQL 都是 PERCONA 的版本，那你就來著了，下面的文字必然能幫到你點什么。

這個問題其實有有客戶反映的，PERCONA 在相關的mysql 5.7.23 上已經打上了一個PATCH，可以進行除限制日期后的，日志SIZE的清除活動，這看上去沒有什么但實際上是一個非常有用的功能。

我們來先看一下實際的情況

下面演示的機器是一臺測試機，而測試機的BINLOG 增長是沒有規律的，所以我可以在保存時間長度上盡量設置的短一些，但一般測試機的磁盤容量都不是很大，所以如果測試進行軟件性能方面的測試，那就很容易將磁盤爆掉。

下面截圖是目前的此時服務器的狀況，日志大致在15G 左右，但如果我們希望日志僅僅保留 5G 就可以了我們怎么辦

我們添加 binlog_space_limit = 5G

然后從啟動MYSQL的服務器，OK 

看下圖，在MYSQL SERVICE從啟動后，再次查看BINLOG保留的數據量，你可以看到數據日志已經被自動刪除了大半。

最近另外一個覺得自己提高的地方就是，原來大部分時間段的思路都是以一個DBER的想法去想軟件開發，或者軟件架構，而到新公司開發部門，并變換為數據庫架構這快一年的時間里面，學到的蠻多，如何融合數據庫和開發的思路去想問題。如以前認為軟件的CHECKER 用戶輸入的數據的校驗的功能一般應該放在前端，而發生用戶誤輸入數據導致后端，乃至數據庫產生字段類型與輸入數據的類型不一致的時候，第一個想法就是 前端在做什么，有沒有干活，在開發部門后扭轉了我這樣的思維，就算是前端將自己該做的工作都做了，但是找到前端的漏洞在瀏覽器里面做手腳，然后突破前端的檢測，直接讓錯誤的數據發送到后端的事情是很容易做到的，所以后端的數據CHECKER 是一定不能少了，這打破我原有的固有思維的模式，看來人在一個環境待久了，會有一些思維定式的問題，而長久活在自己的思維定式里面，會“缺氧的”。

關于Percona server of Mysql 特異功能與多角度思考是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。