《InnoDB緩沖池預(yù)加載在MySQL 5.7中的正確打開方式》要點:
本文介紹了InnoDB緩沖池預(yù)加載在MySQL 5.7中的正確打開方式,希望對您有用。如果有疑問,可以聯(lián)系我們。
DBAplus社群譯者:徐肖霞(新炬網(wǎng)絡(luò)DBA工程師)
譯文審核:葛云杰
在這篇文章里,我將討論在MySQL 5.7里如何使用InnoDB緩沖池預(yù)加載特性.
從MySQL 5.6開始,可以配置MySQL保存InnoDB緩存池的數(shù)據(jù),并在啟動時加載.在MySQL 5.7后,這是默認行為.在默認配置中,MySQL保存和恢復(fù)緩存池的一部分,不再需要任何特殊的配置.我們在Percona Server 5.6中提供了一個類似的功能,所以這個概念已經(jīng)存在了相當長的時間.
坦率來說,時間已經(jīng)減少了這個特性的需求.五年前,我們通常是在旋轉(zhuǎn)的硬盤上存儲數(shù)據(jù)庫,在數(shù)據(jù)庫正常工作負載下,這些磁盤經(jīng)常要相當長的時間來預(yù)熱,這導(dǎo)致在重啟之后,好幾個小時都是低性能的.
隨著固態(tài)硬盤的崛起,預(yù)熱變得很快并且減少了緩沖池中數(shù)據(jù)的加載.通常,一個系統(tǒng)在10分鐘或更少的時間,就能達到其充分預(yù)熱性能的90%.保存緩沖池內(nèi)容是一個默認啟用的特性,所以它的使用,不需要任何精力.
本篇文章將討論關(guān)于這個功能的一些問題,這些問題可能無法通過字面或文檔看出來.
MySQL默認在InnoDB緩沖池(而不是整個緩沖池)中僅保留最頻繁訪問頁的25%.
在多數(shù)使用場景下,合理的選擇是:保留最有用的數(shù)據(jù)頁,比加載所有的頁(很多頁可能在后續(xù)的工作中并沒有訪問到)在緩沖池中要更快.
你可以更改innodb_buffer_pool_dump_pct變量的值,如果使用InnoDB作為內(nèi)存數(shù)據(jù)庫時,想保證所有的數(shù)據(jù)都在內(nèi)存駐留,并且可以在不讀取磁盤的情況下訪問,就要將它設(shè)為100.
請注意,這個變量是基于內(nèi)存中的實際數(shù)據(jù)量,而不是緩沖池的大小.例如,如果有100GB的緩沖池,但只有10GB的數(shù)據(jù),默認只有10GB的25%(即2.5GB)數(shù)據(jù)保存在內(nèi)存中(如手冊中所述,因為磁盤上只存儲頁面標識符,而不是完整頁內(nèi)容,所以磁盤上的訪問量不會太大).
MySQL啟動并且在緩沖池加載完成前可以通過網(wǎng)絡(luò)訪問.同時在啟動之前,大量資源用于盡快從磁盤讀取到緩沖池,這個操作可能會影響性能.
如果你有多個MySQL節(jié)點(例如使用MySQL復(fù)制或Percona XtraDB 集群),則可以考慮在緩沖池加載操作完成后才將他們返回生產(chǎn)環(huán)境.您可以通過查看GLOBAL STATUS變量來監(jiān)視緩沖池加載進度.
緩沖池加載進度:
1 | Innodb_buffer_pool_load_status ?????????| Loaded 403457/419487 pages ????????|
緩存池加載完成:
1 | Innodb_buffer_pool_load_status ?????????| Buffer pool(s) load completed at 161123 ?9:18:
另一方面,如果MySQL能提供一個關(guān)于節(jié)點狀態(tài)的清晰概念將更好:這與準備以最佳的方式服務(wù)于交換往往是不一樣的.
InnoDB緩沖池預(yù)加載不是非常有效的,至少在快速存儲上是這樣的.在性能相當好的NVMe存儲的測試環(huán)境中,在只讀負荷下運行時,可以獲得超過400MB的/秒的預(yù)熱速率.InnoDB緩沖池預(yù)熱速度達到100MB/S,我猜想問題是因為沒有開許多并行IO請求的SSD存儲運行時需要優(yōu)化所導(dǎo)致的,但我沒有做進一步的研究.
InnoDB緩沖池保存/恢復(fù)僅在正常關(guān)機狀態(tài)下保留緩沖池內(nèi)容.如果服務(wù)器崩潰,MySQL仍然會做緩沖池預(yù)加載,但僅僅是最近正常關(guān)機下的內(nèi)容信息(存儲在ib_buffer_pool文件中),這可能會將時間浪費在與當前工作負荷無關(guān)的數(shù)據(jù)加載上.定期運行操作,可以保證新頁可以快速預(yù)熱,即使是遇到MySQL崩潰的情況.
1 SET GLOBAL innodb_buffer_pool_dump_now=ON;
保留當前緩沖池的列表.
值得注意的是,MySQL崩潰的情況并不是經(jīng)常碰到的.這個問題在備份時同樣存在.MySQL slave從Percona XtraBackup或是LVM快照克隆庫,這會導(dǎo)致這些操作性能降低.
希望本文的見解,能幫助你更好地利用這個功能.
文章來自微信公眾號:DBAplus社群
轉(zhuǎn)載請注明本頁網(wǎng)址:
http://www.snjht.com/jiaocheng/2726.html