checkpoint機制,show engine innodb status

---

show engine innodb status \G

mysql> show engine innodb status \G
---
LOG
（Innodb 事務日誌相關信息，包括當前的日誌序列號（Log sequence number），已經刷新同步到那個序列號，最近的check point到那個序列號了。除此之外，還顯示了系統從啓動到現在已經做了多少次check point，多少次日誌刷新。）
---
（注：小括號爲官方解釋。）
Log sequence number 2560255（當前的日誌序列號）
Log flushed up to   2560255（刷新到日誌重做日誌文件的lsn）
Pages flushed up to 2560255（寫入磁盤的髒頁的lsn。記錄在checkpoint中）
Last checkpoint at 2560246（刷新到磁盤的lsn）
0 pending(掛起) log flushes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second

解析：

• Log sequence number：日誌序列號：現在已經產生到的日誌量（字節）
  
  • 不同時刻的lsn的值的差值/時間差==日誌的產生速度
• Log flushed up to：刷出去了多少日誌
  
  • Log sequence number - Log flushed up to== 當前logbuffer的值
  • 所以，此值應<<1M
  • 不同時刻的差值/時間間隔==日誌的寫入速度
• Pages flushed up to
  
  • Log sequence number - Pages flushed up to 值很小，說明髒頁寫入的很快
• Last checkpoint at：檢查點。系統啓動的時候，日誌恢復的起點，肯定比Pfut的值低。防止系統崩
  
  • Log flushed up to - Last checkpoint at == 系統要恢復的日誌數
  • Pages flushed up to - Last checkpoint at == checkpoint的跟進速度，如果大的話，說明checkpoint需要增大。

問：有5個2個G的日誌，Log flushed up to - Pages flushed up to 的值必須保證至少是多大？
答：6個G。因爲，當前用着一個，必須保證想覆蓋的下一個是寫進去的，所以，只能是3個日誌沒寫進去，即6個G。

---

四個參數能反應出來什麼

1.日誌的生成速度？

• 不同時刻的Log sequence number的值的差/時間差==每秒生成的日誌量

2.日誌的寫入速度？

• Log flushed up to

3.髒頁的寫入速度？

• Log flushed up to - Pages flushed up to ==髒頁的寫入速度

4.數據庫的啓動時間是多少？

• 啓動時要回滾的日誌數

---

Checkpoint詳解

引子

checkpoint是一個內部事件，這個事件激活以後會觸發數據庫寫進程(DBWR)將數據緩衝(DATABUFFER CACHE)中的髒數據塊寫出到數據文件中。

check point是做什麼的

在數據庫系統中，寫日誌和寫數據文件是數據庫中IO消耗最大的兩種操作，在這兩種操作中寫數據文件屬於分散寫，寫日誌文件是順序寫，因此爲了保證數據庫的性能，通常數據庫都是保證在提交(commit)完成之前要先保證日誌都被寫入到日誌文件中，而髒數據塊則保存在數據緩存(buffer cache)中再不定期的分批寫入到數據文件中。也就是說日誌寫入和提交操作是同步的，而數據寫入和提交操作是不同步的。這樣就存在一個問題，當一個數據庫崩潰的時候並不能保證緩存裏面的髒數據全部寫入到數據文件中，這樣在實例啓動的時候就要使用日誌文件進行恢復操作，將數據庫恢復到崩潰之前的狀態，保證數據的一致性。檢查點是這個過程中的重要機制，通過它來確定，恢復時哪些重做日誌應該被掃描並應用於恢復。

一般所說的checkpoint是一個數據庫事件(event)，checkpoint事件由checkpoint進程(LGWR/CKPT進程)發出，當checkpoint事件發生時DBWn會將髒塊寫入到磁盤中，同時數據文件和控制文件的文件頭也會被更新以記錄checkpoint信息。

作用

checkpoint主要2個作用：

• 保證數據庫的一致性，這是指將髒數據寫入到硬盤，保證內存和硬盤上的數據是一樣的;

• 縮短實例恢復的時間，實例恢復要把實例異常關閉前沒有寫出到硬盤的髒數據通過日誌進行恢復。如果髒塊過多，實例恢復的時間也會很長，檢查點的發生可以減少髒塊的數量，從而提高實例恢復的時間。

  通俗的說checkpoint就像word的自動保存一樣。

Checkpoint所做的事情

將緩衝池（buffer pool）中的髒頁刷回磁盤。每次刷新多少頁到磁盤，每次從哪裏取髒頁，以及什麼時間觸發Checkpoint。在InnoDB存儲引擎內部，Checkpoint負責這些事。

checkpoint分類

有2種Checkpoint：

• Sharp Checkpoint（完全檢查點）
• Fuzzy Checkpoint（模糊檢查點）

checkpoint的具體解釋

1.Sharp Checkpoint（完全檢查點）

數據庫關閉時，會將所有的髒頁都刷新回磁盤，這是默認的工作方式。參數 innodb_fast_shutdown=1

2.Fuzzy Checkpoint（模糊檢查點）

但是若在數據庫運行時也使用完全檢查點，那數據庫的可用性就會受到很大影響。
所以，在InnoDB存儲引擎內部使用Fuzzy Checkpoint進行頁的刷新，即只刷新一部分髒頁，而不是將所有的髒頁刷回磁盤。

Fuzzy checkpoint工作過程

• 先讀LRU list，把一部分髒頁（相對冷的）寫到磁盤上；
• 再找Frush list，把最早髒的寫到磁盤上。（更新檢查點）

Fuzzy Checkpoint又分爲4種

• ①Master Thread Checkpoint
• ②FLUSH_LRU_LIST Checkpoint
• ③Async/Sync Flush Checkpoint（異步/同步 flush檢查點）
• ④Dirty Page too much Checkpoint

1）Master Thread Checkpoint

對於Master Thread 中發生的Checkpoint，差不多以每秒或每十秒的速度從緩衝池的髒頁列表中刷新一定比例的頁回去磁盤。這個過程是異步的，即此時InnoDB存儲引擎可以進行其他的操作，用戶查詢線程不會阻塞。
–》即：常規性的fuzzy checkpoint，寫入操作不阻塞用戶線程

2）FLUSH_LRU_LIST Checkpoint

FLUSH_LRU_LIST Checkpoint是因爲InnoDB存儲引擎需要保證LRU列表中需要有差不多100個空閒頁可供使用。在innodb1.1X版本以前，需要檢查LRU列表中是否有足夠的可用空間操作發生在用戶查詢線程中，顯然會阻塞用戶的查詢操作。若沒有100個可用空閒頁，那麼innodb會將LRU列表末端的頁移除。如果這些頁中有髒頁，那就要進行Checkpoint，而這些頁是來自LRU列表的，因此成爲FLUSH_LRU_LIST Checkpoint。
–》即：Flush lru list checkpoint：flush list上的髒頁數量超過閾值；會阻塞用戶線程。

3）Async/Sync Flush list Checkpoint

（在數據庫的報錯日誌裏能夠看到！）
Async/Sync Flush list Checkpoint指的是重做日誌文件不可用的情況，這時需要強制將一些頁刷新回磁盤，而此時髒頁是從髒頁列表中選取的。若將已經寫入到redo log的LSN（Log sequence number）記作redo_lsn，將已經刷新回磁盤最新頁的LSN記爲checkpoint_lsn，則可定義：
redo_lsn - checkpoint_lsn == checkpoint_age
又定義：
async_water_mark==75% * total_redo_log_file_size
sync_water_mark==90% * total_redo_log_file_size
假設每個redo log的大小是1G，並且定義兩個redo log，則redo log總共2G。
則，async_water_mark=1.5G，sync_water_mark=1.8G。則：

• ① checkpoint_age< async_water_mark 時，不需要刷新任何髒頁到磁盤；
• ② **async_water_mark < checkpoint_age<
  sync_water_mark**（即：有25%的日誌能被覆蓋時） 時，觸發Async Flush，從Async Flush
  列表中刷新足夠的髒頁回磁盤。最終滿足①；
• ③ checkpoint_age > sync_water_mark
  時（即有90%的日誌能被覆蓋時），極少發生，除非設置的redo log太小，並且在進行類似LOAD DATA的BULK
  INSERT操作。此時觸發Sync Flush操作，從Flush列表中刷新足夠的髒頁回磁盤，使得刷新後滿足①。

注意：在較早版本的innodb中，Async Flush list Checkpoint會阻塞發現問題的用戶查詢線程，而Sync Flush list Checkpoint會阻塞所有的用戶查詢線程，並且等待髒頁刷新完成。
但在5.6版本（即innodb1.2x版本）開始，這部分的刷新操作同樣放入到了單獨的Page Cleaner Thread中，所以不會再阻塞用戶查詢線程了。

4）Dirty Page too much Checkpoint

即髒頁的數量太多，導致innodb存儲引擎強制進行 檢查點。
目的：還是爲了保證buffer pool緩衝池中有足夠的可用的頁。
可由參數 innodb_max_dirty_pages_pct 控制。

innodb_max_dirty_pages_pct參數官方文檔解釋：

innodb_max_dirty_pages_pct_lwm參數解釋：

發現，該參數值默認爲75，即：當buffer pool中髒頁的數量佔據75%時，強制進行Checkpoint，刷新一部分的髒頁到磁盤。
（在innodb1.0x以前，該參數默認是90，之後的版本都爲75。）

---

能夠觸發寫操作的一些因素

1. 常規性寫入操作：（影響不大）

• 1.master thread
• 2.io write 寫入線程
• 3.每次寫入的量 –》怎麼控制？ 增加寫入線程的數量。

2. flush 列表太大

會觸發對用戶線程的阻塞

增加後：頻繁的寫。（影響不大）

3. 可以覆蓋的日誌太少了：（影響大）

• 增加日誌的大小和組的數量
• 避免同步和異步
• 髒頁的總量【一般調成90%】（影響大）

防止因爲寫入操作而導致系統hang住！

---

控制寫入操作

1.控制每次寫入的量

• 1.innodb_io_capacity（可以調節每次寫入的數據量）
  
  • 假設我們使用閃盤，io可以達到50萬iops
  • 【IOPS：Input/Output Operations Per Second，即每秒進行讀寫（I/O）操作的次數，多用於數據庫等場合，衡量隨機訪問的性能。】
    200,300,400,500
    看一下髒頁的數量是否還是過多（指標）
• 2.innodb_lru_scan_depth
  
  • 每次查找髒頁的深度
• 3.調整log file的大小和組數
• 4.髒頁的比例：75%（默認）、90%（推薦）（但系統崩潰的時候恢復時會比較慢）…

---

如何來確認系統的寫入操作是大還是小

1、如何來調整寫入這個操作？

• innodb_io_capacity（容量）–》調大可加大髒頁寫入速度
• innodb_lru_scan_depth –》調大可加大髒頁寫入速度
• 增加log file組數和大小
• 加大或者縮小innodb_max_dirty_pages_pct

2、爲什麼增大或者減小寫入操作？

• 1.我們要確認系統是寫入還是讀取爲主的系統（調不調）
  如果是以寫入爲主的系統，就需要加大上面的相關參數。
• 2.觀察我們的系統的io狀況【iostat -x 1】【%util達到70%左右、w/s也很好，說明參數調的很好】
  來確認調整的合理程度。（調多少）
• 3.通過double write 寫入來監控我們的系統的寫入壓力夠不夠（讓寫入壓力大一些好）

（如果w/s太大，就是寫的太快，此時就應降低寫功能）

wrqm/s 反映的是double write的功能
InnoDB_dblwr_writes：寫的次數
InnoDB_dblwr_pages_written：寫的頁數
pages：writes的值能夠看一次寫多少頁】

• 4.通過日誌產生速度和髒頁刷新速度的差值
• 5.髒頁和pool的比值（看此時髒頁的數量大小）

參數innodb_fast_shutdown髒頁刷新控制參數

在關閉時，參數innodb_fast_shutdown影響着表的存儲引擎爲innodb的行爲。該參數可取值爲0、1、2，默認值爲1。

• 0：表示在MySQL數據庫關閉時，innodb需要完成所有的full purge（）和merge（合併） insert buffer
  ，並且將所有的髒頁刷新回磁盤。這需要一段時間，有時甚至需要幾個小時來完成。如果在進行innodb升級時，必須將這個參數調爲0，然後再關閉數據庫。
• 1：是參數innodb_fast_shutdown的默認值，表示不需要完成上述的full purge和merge
  insert操作，但是在緩衝池中的一些數據髒頁還是會刷新回磁盤。
• 2：表示不完成full purge和merge insert
  buffer操作，也不將緩衝池中的數據髒頁寫回磁盤，而是將日誌都寫入日誌文件。這樣不會有任何事務的丟失，但是下次MySQL數據庫啓動時，會進行恢復操作。

當正常關閉MySQL數據庫時，下次的啓動應該會非常“正常”。但是如果沒有正常地關閉數據庫，比如用kill 命令關閉數據庫，在MySQL數據庫運行中重啓了服務器，或者在關閉數據庫時，將參數innodb_fast_shutdown設爲了2時，下次MySQL數據庫啓動時都會對InnoDB存儲引擎的表進行恢復操作。

恢復參數 innodb_force_recovery

參數 innodb_force_recovery 影響了整個innodb存儲引擎恢復的狀況。該參數值默認爲0，代表當發生需要恢復時，進行所有的恢復操作，當不能進行有效恢復時，如數據頁發生了corruption（損壞），mysql數據庫可能發生宕機（crash），並把錯誤寫到錯誤日誌去。

但是，在某些情況下，可能並不需要進行完整的恢復操作，因爲用戶自己知道怎麼恢復。比如在對一個表進行alter table操作時發生意外了，數據庫重啓時會對innodb表進行回滾操作，對於一個大表來說這需要很長時間，可能是幾個小時。這時用戶可以自行進行恢復，如可以把表刪除，從備份中重新導入數據到表，可能這些操作的速度要遠遠快於回滾操作。

參數innodb_force_recovery 還可以設置爲6個非零值：1~6。大的數字包含了前面所有小數字表示的影響：

• 1：SRV_FORCE_IGNORE_CORRUPT：忽略檢查到的corrupt頁。
• 2：SRV_FORCE_NO_TRX_UNDO：阻止Master Thread 線程的運行，如Master Thread線程需要進行full purge操作，而這會導致crash。
• 3：SRV_FORCE_NO_TRX_UNDO：不進行事務的回滾操作。
• 4：SRV_FORCE_NO_IBUF_MERGE：不進行插入緩衝的合併操作。
• 5：SRV_FORCE_NO_UNDO_LOG_SCAN：不查看撤銷日誌（undo log），InnoDB存儲引擎會將未提交的事務視爲已提交。
• 6：SRV_FORCE_NO_LOG_REDO：不進行前滾的操作。

需要注意：在設置了參數innodb_force_recovery大於0後，用戶可以對錶進行select、create和drop操作，但insert、update和delete這類DML操作是不允許的。

---

前滾和回滾

如果系統因爲執行了一個非常大的DML或者DDL操作，導致系統hang住，我們想斷掉這個操作，怎麼辦？
①kill thread –》要前滾

②kill process –》要回滾

數據庫性能監控

1.性能指標

怎麼來監控？
（1）通過show engine innodb status \G 來看log的部分：

Log sequence number 2560255    （當前的日誌序列號）
Log flushed up to   2560255    （刷新到日誌重做日誌文件的lsn）
Pages flushed up to 2560255    （寫入磁盤的髒頁的lsn。記錄在checkpoint中）
Last checkpoint at 2560246    （刷新到磁盤的lsn）
0 pending(掛起) log flushes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second

（2）通過一些參數來看：

• innodb_dblwr_pages_written：看寫的快慢
• Com_select
• Com_delete
• Com_update -》增刪改查的統計量
• Com_commit -》提交的事務數
• InnoDB_dblwr_writes：寫的次數
• InnoDB_dblwr_pages_written：寫的頁數
  【pages：writes的值能夠看一次寫多少頁】

（3）iostat
觀察系統的io狀況的命令

壓力測試的工具

• 測IO的：測出IOPS–》fifo、orion等
• 測網絡的：測出吞吐量–》傳包

• 測數據庫

  • tpcc-mysql ：它自己建立業務系統，模擬業務操作，進行壓力測試。
  • loadrunner：可以模擬我們的真實的生產系統，進行壓力測試。（業務部門做的，需要開發編程等…）
  • tcpcopy：引流進行壓力測試。

TPCCMySQL 小工具的使用

README手冊：

1.Build binaries
     cd scr ; make ( you should have mysql_config available in $PATH)
2.Load data
  ①  create database mysqladmin create tpcc1000
  ② create tables mysql tpcc1000 < create_table.sql
  ③create indexes and FK ( this step can be done after loading data) mysql tpcc1000 < add_fkey_idx.sql
  ④ populate data
        1）simple step tpcc_load -h127.0.0.1 -d tpcc1000 -u root -p "" -w 1000 |hostname:port| |dbname| |user| |password| |WAREHOUSES| ref. tpcc_load --help for all options
        2）load data in parallel check load.sh script
3.start benchmark
    ①./tpcc_start -h127.0.0.1 -P3306 -dtpcc1000 -uroot -w10 -c32 -r10 -l10800
    ②|hostname| |port| |dbname| |user| |WAREHOUSES| |CONNECTIONS| |WARMUP TIME| |BENCHMARK TIME|
    ③ref. tpcc_start --help for all options

常用參數：

• -w 10 –》加載10個數據倉庫就不少了！（實驗用三四個就行！）
• -h 往哪個地址
• -d 哪個數據庫

---

數據庫性能相關指標小結

show glabal status like ‘%wait%’;
show glabal status like ‘%thread%’;
show glabal status like ‘%abor%’;
show glabal status like ‘%question%’;
show glabal status like ‘%que%’;
show glabal status like ‘%full%’;
show glabal status like ‘%scan%’;
show glabal status like ‘%slow%’;
show glabal status like ‘%read%’;
show glabal status like ‘%write%’;
show glabal status like ‘%log%’;
show glabal status like ‘%commit%’;
show glabal status like ‘%Com%’;
QPS
TPS
buffer hit
show glabal status like ‘%disk%’;
show glabal status like ‘%max%’;
show glabal status like ‘%page%’;
show glabal status like ‘%fsync%’;

show status 看的是運行狀態，是不能調的！
show variables 看的是變量，可以調！

上面這些參數的詳解：

1.show glabal status like ‘%wait%’;

Innodb_buffer_pool_wait_free：buffer pool沒有空閒內存了。【如果每秒增長的值比較高 –》能覆蓋的磁盤太少了！即 髒頁太多！！】
【髒頁太多的一個最經典的指標！！！】
Innodb_log_waits：因log buffer不足導致等待的次數。

2.show glabal status like ‘%thread%’;

• Threads_cache：在緩存池子裏緩存了幾個。例如先建立20個線程放在池子裏，當短連接上來之後，就分配給它，用完就釋放
• Threads_connected：當前的連接數
• Threads_created：系統一共累計建立了多少線程，若此值很大，則系統頻繁的建立和斷開線程！則 thread_cache_size小了，容易幹（溢出）！
• Threads_running：當前活躍的線程的數量。一共有多少個想幹活的。

當created的值很大時：
show variables like ‘%thread%’;

看到thread_cache_size的值爲9。假設有100個線程上來了，緩存池子緩存了9個，忽然斷開。則需要新建立91個線程。
所以，當thread_cache_size增大，可理解爲池子增多了。則Threads_created的數量就會降下來了。
thread_concurrency：真正在幹活的數量。（截的圖上沒有…）
48core*2個線程==96個線程 –》cpu能夠服務的線程數

Threads_running和 thread_concurrency的關係

• ①running的數<64，就把concurrency設置爲0
• ②running值>>128，就把concurrency設置爲128（最大值）
• ③running值∈（10,200）–》嘗試調整：concurrency
  先調成60：然後算tps和qps；然後80，若發現tps和qps上升了，則好；再100，若發現tps或qps下降了，則降低，調成80就好。

我們有個限制：concurrency<=cpu的core *2/4 –》（4是能併發的處理4個線程）

max_connection：允許的最大連接數

默認151。最好調成三四百。
所以，當Threads_created 等於151時，就該調max_connection了。

3.show glabal status like ‘%abor%’;

被異常終止的連接的數量。

Aborted_connection的值很大時，說明被異常終止的連接的數量很多。

4.show glabal status like ‘%question%’;

描述數據庫的處理能力。

5.show glabal status like ‘%que%’;

Queries：sql查詢（增刪改）的數量。

Com_stmt_execute：累積的SQL語句的執行數量。

【發現Queryes的值與它差不多】

6.show glabal status like ‘%full%’;

select_full_join：應用到其他表，沒有使用索引的連接的數量；
select_full_range_join：應用到其他表，在引用的表中使用範圍搜索的連接的數量。

7.show glabal status like ‘%scan%’;

Select_scan：系統全表掃描的累計值。

8.show glabal status like ‘%slow%’;

Slow_queries：慢查詢（後面會講）的數量。

slow_launch_time：2秒。
一個SQL語句的執行時間超過2秒–》認爲是一個慢sql，就記錄在/mysql/data/slowmysql.log，同時slow_queries的值+1

9.show glabal status like ‘%read%’;

read往往意味着物理讀。

• Innodb_buffer_pool_reads：在buffer pool裏找值沒找到發生物理讀的累積次數。【不同時刻的差值/間隔==buffer pool每秒發生的物理讀】
• Innodb_buffer_pool_read_ahead：預讀 數是169。此值如果高的時候，就是全表掃描。
• Innodb_buffer_pool_read_requests：innodb_buffer 中總的請求數。
  
  • （buffer hit）命中率==(requests-reads)/requests
• Innodb_data_pending_reads：掛起數。數據庫系統裏面曾經出現的IO請求，但由於IO已經滿了，就會出現pending，被掛起了。

10.show glabal status like ‘%write%’;

寫請求。

• Innodb_buffer_pool_write_requests：寫請求的總數。
• Innodb_dblwr_writes：double write 寫的次數。（寫髒頁）
• innodb_log_writes：日誌寫的次數。【寫負載一般關注兩點：寫髒頁、日誌寫】
• innodb_os_log_pending_writes：日誌掛起的次數，【大了就說明：寫功能可能壞了–》cache的電池】

11.show glabal status like ‘%log%’;

Innodb_log_waits：先往log buffer裏寫，logfile裏寫redo log時，如果滿了，就會有等待。

12.show glabal status like ‘%commit%’;

Com_commit的提交數量。與rollback一起，可以算 命中率。

13.show glabal status like ‘%Com%’;

關於累計值。

經常關注的幾個：

• Com_commit：執行的commit的數量；
• Com_delete：執行的刪除數量；
• Com_insert：執行的插入數量；
• Com_select：執行的查詢數量；
• Com_stmt_execute：總的sql執行的數量。
• QPS：不同時刻的Questions的差值/時間差
  
  • QPS：Query Per Second，每秒查詢率
• TPS：（Com_rollbacl+Com_commit）/時間差
  
  • TPS：Transaction Per Second，每秒事務處理量。

14.show glabal status like ‘%disk%’;

15.show glabal status like ‘%max%’;

• ①Connection_errors_max_connections的值>0：因爲超過了最大連接數而導致的錯誤，應該保持是0才正常。
• ②Max_used_connections：一定<<事務的Max_connections

16.show glabal status like ‘%page%’;

• Innodb_buffer_pool_pages_tocal：innodb buffer pool的總大小；
• Innodb_buffer_pool_pages_dirty：髒頁的數量
• Innodb_dblwr_pages_written：double write 的字節數

17.show glabal status like ‘%fsync%’;

文件系統。

• Innodb_data_fsyncs：是物理寫。跳過文件系統的緩存，直接往磁盤寫。一般指日誌。

一般是：數據先寫到文件系統的緩存，然後再寫到磁盤！

• Innodb_data_pending_fsyncs：寫日誌的時候的物理寫。
• Innodb_os_log_pending_fsyncs：redo log的pending fsyncs() 次數

18.show global status like ‘%dbl%’;

判斷數據庫系統繁忙度。

（現在的比值是21:1，意思就是每次寫，寫21個頁。）
注意比值：當written/writes比值爲128:1時，就是寫操作比較繁忙，壓力比較大。
小於128時，就是不繁忙。

爲什麼是128:1就是繁忙的？（圖解：）