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

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

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

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

問題

1  到底BINLOG 保留的天數(shù)和實際存儲了多少BINLOG SIZE 有沒有直接的聯(lián)系

2  我設(shè)置了較短的expire_log_days 到底會不會還發(fā)生 binlog 暴漲造成的數(shù)據(jù)庫DOWN機的問題

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

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

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

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

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

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

我們添加 binlog_space_limit = 5G

然后從啟動MYSQL的服務(wù)器，OK 

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

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

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