mysql 5.6 刷新 ib_logfile 輪換上的所有臟頁，創建檢查點停頓

伺服器版本：5.6.23-72.1-log Percona

我一直在試圖找出為什麼我們的 mysql 伺服器是尖銳的檢查點，它似乎與 ib_logfile 的輪換有關。

我繼承了這個 Percona 5.6 mysql 伺服器，它每天暫停一次尖銳檢查點/完全臟刷新，innodb_log_file_size 為 1GB。我認為可能是日誌文件大小不足，並將其增加到 25GB。現在我們只是減少了相同的行為。在我能夠驗證它發生在日誌文件切換時，這對我來說是一種謎。

Mysql 5.5 docs: https://dev.mysql.com/doc/refman/5.5/en/innodb-checkpoints.html : “…當 InnoDB 開始重用日誌文件時，它必須確保數據庫頁面“

Mysql 5.6 文件省略了這一點，並說它應該做的只是在正常情況下進行模糊檢查點。https://dev.mysql.com/doc/refman/5.6/en/innodb-checkpoints.html：“InnoDB 實現了一種稱為模糊檢查點的檢查點機制。InnoDB 小批量從緩衝池中刷新修改的數據庫頁面。有無需一次性刷新緩衝池，這會在檢查點過程中中斷使用者 SQL 語句的處理。”

如果這種行為是意外的，有什麼方法可以最小化或擺脫這種行為？

| innodb_adaptive_flushing | ON |
| innodb_adaptive_flushing_lwm | 10 |
| innodb_buffer_pool_size | 46170898432 |
| innodb_change_buffer_max_size | 25 |
| innodb_change_buffering | inserts |
| innodb_checksum_algorithm | innodb |
| innodb_checksums | ON |
| innodb_cleaner_lsn_age_factor | high_checkpoint |
| innodb_doublewrite | ON |
| innodb_empty_free_list_algorithm | backoff |
| innodb_file_format | Barracuda |
| innodb_file_per_table | ON |
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_flush_method | O_DIRECT |
| innodb_flush_neighbors | 0 |
| innodb_flushing_avg_loops | 30 |
| innodb_force_load_corrupted | OFF |
| innodb_force_recovery | 0 |
| innodb_foreground_preflush | exponential_backoff |
| innodb_io_capacity | 3000 |
| innodb_io_capacity_max | 6000 |
| innodb_log_arch_dir | ./ |
| innodb_log_arch_expire_sec | 0 |
| innodb_log_archive | OFF |
| innodb_log_block_size | 512 |
| innodb_log_buffer_size | 8388608 |
| innodb_log_checksum_algorithm | innodb |
| innodb_log_compressed_pages | ON |
| innodb_log_file_size | 26843545600 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_lru_scan_depth | 2048 |
| innodb_max_changed_pages | 1000000 |
| innodb_max_dirty_pages_pct | 50 |
| innodb_max_dirty_pages_pct_lwm | 0 |
| innodb_max_purge_lag | 200 |
| innodb_max_purge_lag_delay | 0 |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 1000 |
| innodb_online_alter_log_max_size | 134217728 |
| innodb_open_files | 384 |
| innodb_page_size | 16384 |
| innodb_purge_batch_size | 20 |
| innodb_purge_threads | 1 |
| innodb_random_read_ahead | OFF |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_read_only | OFF |
| innodb_rollback_on_timeout | OFF |
| innodb_rollback_segments | 128 |
| innodb_sched_priority_cleaner | 19 |
| innodb_sort_buffer_size | 1048576 |
| innodb_spin_wait_delay | 6 |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 0 |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_global_flush_log_at_trx_commit | ON |
| innodb_use_native_aio | ON |
| innodb_use_sys_malloc | ON |
| innodb_version | 5.6.23-72.1 |
| innodb_write_io_threads | 8 |

從 Percona MySQL 5.6.23 修補到 5.6.47 並啟用 innodb_numa_interleave 已解決此問題。

關於在日誌文件輪換/重用之前需要檢查點的語句可能已從文件中刪除，但邏輯在 5.6 版中沒有改變——你不能覆蓋屬於尚未持久化數據的日誌記錄，所以你有仍然到檢查站。它發生在您的環境中的事實表明，使用模糊檢查點刷新臟頁對於您的工作負載來說不夠積極。

我會嘗試提高innodb_adaptive_flushing_lwm門檻值並降低門檻值innodb_max_dirty_pages_pct以使頁面清理更加主動。

本文還有更多的提示和連結

引用自：https://dba.stackexchange.com/questions/257890