MySQL checkpoint深刻分析

一、平常關注點的問題

二、日誌點分析

三、checkpoint：髒頁刷盤的檢查點

四、模糊檢查點發生條件

　　一、master thread checkpoint

　　二、flush_lru_list checkpoint

　　三、async/sync flush checkpoint

　　四、dirty page too much checkpoint

1、平常關注的問題

 

一、咱們的日誌生成速度？

　　一、天天生成多少日誌、產生多少redo log

mysql> show global status like 'Innodb_os_log_written'; +-----------------------+--------+
| Variable_name         | Value  |
+-----------------------+--------+
| Innodb_os_log_written | 107008 |
+-----------------------+--------+
1 row in set (0.01 sec)

　　二、若是redolog量大，須要修改以下參數，增長logfile的大小和組數

mysql> show variables like 'i%log_file%'; +---------------------------+----------+
| Variable_name             | Value    |
+---------------------------+----------+
| innodb_log_file_size      | 50331648 |
| innodb_log_files_in_group | 2        |
+---------------------------+----------+
2 rows in set (0.00 sec)

二、日誌寫入速度？

　　Log buffer有沒有滿、滿的話爲何滿

mysql> show variables like 'i%log_buffer%'; +------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| innodb_log_buffer_size | 16777216 |
+------------------------+----------+
1 row in set (0.01 sec) mysql> show global status like '%log_pending%'; +------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| Innodb_os_log_pending_fsyncs | 0     |
| Innodb_os_log_pending_writes | 0     |
+------------------------------+-------+
2 rows in set (0.01 sec)

三、髒頁的寫入速度？

　　一、Log buffer滿了會hang住

　　二、Logfile滿了不能被覆蓋也會hang住

　　三、若是髒頁寫入速度慢的話，logfile滿了也不能被覆蓋，系統容易hang住，log buffer若是滿了的話也容易hang住。

四、數據庫啓動時間是多少？

　　啓動時，默認是要先恢復髒頁。固然，能經過參數innodb_force_recovery啓動控制。

　　若是innodb_buffer_pool很大，32G，極端狀況可能有32G的髒頁，這個時候若是崩了，恢復的話須要恢復這32G的髒頁，時間很是長。

 

2、日誌點分析

　　經過show engine innodb status\G解釋一下LOG相關的四行參數的值：

Log sequence number 143942609---LSN：日誌序列號(1)　　

　　//字節，日誌生成的最新位置，最新位置出如今log buffer中

Log flushed up to   143942609---(2)　　

　　//字節，日誌已經寫入到log file的位置，1-2=log buffer日誌量，最好是<=1M

Pages flushed up to 143942609---(3)　　

　　//字節，髒頁的數量(日誌字節數來衡量)，2-3=髒頁的數量(日誌字節爲單位)

Last checkpoint at  143942600---(4)　　

　　//字節，共享表空間上的日誌記錄點，最後一次檢查點，及崩潰恢復時指定的起點，3-4就是崩潰恢復多跑的日誌，值越大說明須要提高checkpoint的跟進速度

 

3、checkpoint

　　檢查點，表示髒頁寫入到磁盤的時候，因此檢查點也就意味着髒數據的寫入。

一、checkpoint的目的

　　一、縮短數據庫的恢復時間

　　二、buffer pool空間不夠用時，將髒頁刷新到磁盤

　　三、redolog不可用時，刷新髒頁

二、檢查點分類

　　一、sharp checkpoint：徹底檢查點，數據庫正常關閉時，會觸發把全部的髒頁都寫入到磁盤上(這時候logfile的日誌就沒用了，髒頁已經寫到磁盤上了)。

　　　　一、徹底檢查點，發生在數據庫正常關閉的時候。

　　　　二、在數據庫在運行時不會使用sharp checkpoint，在引擎內部使用fuzzy checkpoint，即只刷新一部分髒頁，而不是刷新全部的髒頁回磁盤。

　　二、fuzzy checkpoint：模糊檢查點，部分頁寫入磁盤。

　　　　一、發生在數據庫正常運行期間。

　　　　二、模糊檢查點，不是sharp的就是模糊檢查點(4種)：master thread checkpoint、flush_lru_list checkpoint、async/sync flush checkpoint、dirty page too much checkpoint。

 

4、fuzzy checkpoint發生的4個條件

　　模糊檢查點的發生，也就是髒頁寫入磁盤的狀況。

一、master thread checkpoint

　　差很少以每秒或每十秒的速度從緩衝池的髒頁列表中刷新必定比例的頁回磁盤，這個過程是異步的，不會阻塞用戶查詢。

　　一、週期性，讀取flush list，找到髒頁，寫入磁盤

　　二、寫入的量比較小

　　三、異步，不影響業務

mysql> show variables like '%io_cap%'; +------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| innodb_io_capacity     | 200   |
| innodb_io_capacity_max | 2000  |
+------------------------+-------+
2 rows in set (0.01 sec)

　　四、經過capacity能力告知進行刷盤控制

　　　　經過innodb的io能力告知控制對flush list刷髒頁數量，io_capacity越高，每次刷盤寫入髒頁數越多；

　　　　若是髒頁數量過多，刷盤速度很慢，在io能力容許的狀況下，調高innodb_io_capacity值，讓多刷髒頁。

二、flush_lru_list checkpoint

　　MySQL會保證，保證裏面有多少可用的空閒頁，在innodb 1.1.x版本以前，須要檢查在用戶查詢線程中是否有足夠的可用空間(差很少100個空閒頁)，顯然這會阻塞用戶線程，若是沒有100個可用空閒頁，那麼innodbhi將lru列表尾端的頁移除，若是這些頁中有髒頁，那麼須要進行checkpoint。Innodb 1.2(5.6)以後把他單獨放到一個線程page cleaner中進行，用戶能夠經過參數innodb_lru_scan_depth控制lru列表中可用頁的數量，默認是1024。

　　讀取lru list，找到髒頁，寫入磁盤。

mysql> show variables like '%lru%depth'; +-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_lru_scan_depth | 1024  |
+-----------------------+-------+
1 row in set (0.01 sec)

　　此狀況下觸發，默認掃描1024個lru冷端數據頁，將髒頁寫入磁盤(有10個就刷10，有100個就刷100個……)   

三、async/sync flush checkpoint

　　log file快滿了，會批量的觸發數據頁回寫，這個事件觸發的時候又分爲異步和同步，不可被覆蓋的redolog佔log file的比值：75%--->異步、90%--->同步。

　　當這兩個事件中的任何一個發生的時候，都會記錄到errlog中，一旦errlog出現這種日誌提示，必定須要加大logfile。

　　Async/Sync Flush Checkpoint是爲了保證重作日誌的循環使用的可用性。在InnoDB 1.2.x版本以前，Async Flush Checkpoint會阻塞發現問題的用戶查詢線程，而Sync Flush Checkpoint會阻塞全部的用戶查詢線程，而且等待髒頁刷新完成。從InnoDB 1.2.x版本開始——也就是MySQL 5.6版本，這部分的刷新操做一樣放入到了單獨的Page Cleaner Thread中，故不會阻塞用戶查詢線程。

四、dirty page too much checkpoint

　　很明顯，髒頁太多檢查點，爲了保證buffer pool的空間可用性的一個檢查點。

　　一、髒頁監控，關注點

mysql> show global status like 'Innodb_buffer_pool_pages%t%'; +--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_data  | 2964  |
| Innodb_buffer_pool_pages_dirty | 0     |
| Innodb_buffer_pool_pages_total | 8191  |
+--------------------------------+-------+
3 rows in set (0.00 sec) mysql> show global status like '%wait_free'; +------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| Innodb_buffer_pool_wait_free | 0     |
+------------------------------+-------+
1 row in set (0.00 sec)

　　　　一、Innodb_buffer_pool_pages_dirty/Innodb_buffer_pool_pages_total：表示髒頁在buffer 的佔比

　　　　二、Innodb_buffer_pool_wait_free：若是>0，說明出現性能負載，buffer pool中沒有乾淨可用塊

　　二、髒頁控制參數

mysql> show variables like '%dirty%pct%'; +--------------------------------+-----------+
| Variable_name                  | Value     |
+--------------------------------+-----------+
| innodb_max_dirty_pages_pct     | 75.000000 |
| innodb_max_dirty_pages_pct_lwm | 0.000000  |
+--------------------------------+-----------+
2 rows in set (0.01 sec)

　　　　一、默認是髒頁佔比75%的時候，就會觸發刷盤，將髒頁寫入磁盤，騰出內存空間。建議不調，調過低的話，io壓力就會很大，可是崩潰恢復就很快；

　　　　二、lwm：low water mark低水位線，刷盤到該低水位線就不寫髒頁了，0也就是不限制。

注意：上面在調整的時候，要關注系統的寫性能iostat -x。