1、崩潰恢復相關引數決議：
innodb_fast_shutdown: innodb_fast_shutdown = 0：這個表示在MySQL關閉的時候，執行slow shutdown，不但包括日志的刷盤，資料頁的刷盤，還包括資料的清理(purge)，ibuf的合并，buffer pool dump以及lazy table drop操作(如果表上有未完成的操作，即使執行了drop table且回傳成功了，表也不一定立刻被洗掉)， innodb_fast_shutdown = 1：這個是默認值，表示在MySQL關閉的時候，僅僅把日志和資料刷盤， innodb_fast_shutdown = 2：這個表示關閉的時候，僅僅日志刷盤，其他什么都不做，就好像MySQL crash了一樣， 這個引數值越大，MySQL關閉的速度越快，但是啟動速度越慢，相當于把關閉時候需要做的作業挪到了崩潰恢復上，另外，如果MySQL要升級，建議使用第一種方式進行一次干凈的shutdown，
innodb_force_recovery: 這個引數主要用來控制InnoDB啟動時候做哪些作業，數值越大，做的作業越少，啟動也更加容易，但是資料不一致的風險也越大，當MySQL因為某些不可控的原因不能啟動時，可以設定這個引數，從1開始逐步遞增，知道MySQL啟動，然后使用SELECT INTO OUTFILE把資料匯出，盡最大的努力減少資料丟失， innodb_force_recovery = 0：這個是默認的引數，啟動的時候會做所有的事情，包括redo日志應用，undo日志回滾，啟動后臺master和purge執行緒，ibuf合并，檢測到了資料頁損壞了，如果是系統表空間的，則會crash，用戶表空間的，則打錯誤日志， innodb_force_recovery = 1：如果檢測到資料頁損壞了，不會crash也不會報錯(buf_page_io_complete)，啟動的時候也不會校驗表空間第一個資料頁的正確性(fil_check_first_page)，表空間無法訪問也繼續做崩潰恢復(fil_open_single_table_tablespace、fil_load_single_table_tablespace)，ddl操作不能進行(check_if_supported_inplace_alter)，同時資料庫也被不能進行寫入操作(row_insert_for_mysql、row_update_for_mysql等)，所有的prepare事務也會被回滾(trx_resurrect_insert、trx_resurrect_update_in_prepared_state)，這個選項還是很常用的，資料頁可能是因為磁盤壞了而損壞了，設定為1，能保證資料庫正常啟動， innodb_force_recovery = 2：除了設定1之后的操作不會運行，后臺的master和purge執行緒就不會啟動了(srv_master_thread、srv_purge_coordinator_thread等)，當你發現資料庫因為這兩個執行緒的原因而無法啟動時，可以設定， innodb_force_recovery = 3：除了設定2之后的操作不會運行，undo回滾資料庫也不會進行，但是回滾段依然會被掃描，undo鏈表也依然會被創建(trx_sys_init_at_db_start)，srv_read_only_mode會被打開， innodb_force_recovery = 4：除了設定3之后的操作不會運行，ibuf的操作也不會運行(ibuf_merge_or_delete_for_page)，表資訊統計的執行緒也不會運行(因為一個壞的索引頁會導致資料庫崩潰)(info_low、dict_stats_update等)，從這個選項開始，之后的所有選項，都會損壞資料，慎重使用， innodb_force_recovery = 5：除了設定4之后的操作不會運行，回滾段也不會被掃描(recv_recovery_rollback_active)，undo鏈表也不會被創建，這個主要用在undo日志被寫壞的情況下， innodb_force_recovery = 6：除了設定5之后的操作不會運行，資料庫前滾操作也不會進行，包括決議和應用(recv_recovery_from_checkpoint_start_func)，
2、事務提交相關引數決議：
innodb_flush_log_at_trx_commit：這個引數控制InnoDB 存盤引擎事務提交時的redo重繪機制，innodb_flush_log_at_trx_commit = 0：Innodb 中的Log Thread 沒隔1 秒鐘會將logbuffer中的資料寫入到檔案，同時還會通知檔案系統進行檔案同步的flush操作，保證資料確實已經寫入到磁盤上面的物理檔案，但是，每次事務的結束（commit 或者是rollback）并不會觸發LogThread 將log buffer 中的資料寫入檔案，所以，當設定為0 的時候，當MySQL Crash 和OS Crash或者主機斷電之后，最極端的情況是丟失1 秒時間的資料變更，innodb_flush_log_at_trx_commit = 1：這也是Innodb的默認設定，我們每次事務的結束都會觸發Log Thread 將log buffer中的資料寫入檔案并通知檔案系統同步檔案，這個設定是最安全的設定，能夠保證不論是MySQL Crash 還是OS Crash或者是主機斷電都不會丟失任何已經提交的資料，innodb_flush_log_at_trx_commit = 2：當我們設定為2 的時候，Log Thread會在我們每次事務結束的時候將資料寫入事務日志，但是這里的寫入僅僅是呼叫了檔案系統的檔案寫入操作，而我們的檔案系統都是有快取機制的，所以LogThread的這個寫入并不能保證內容真的已經寫入到物理磁盤上面完成持久化的動作，檔案系統什么時候會將快取中的這個資料同步到物理磁盤檔案LogThread 就完全不知道了，所以，當設定為2 的時候，MySQL Crash 并不會造成資料的丟失，但是OS Crash或者是主機斷電后可能丟失的資料量就完全控制在檔案系統上了，
binlog_sync:這個引數控制mysql server 事務提交時二進制日志的同步機制，binlog_sync=0:事務提交時，mysql server 不主動同步binlog 到磁盤，由OS 檔案系統決定何時同步，當mysql server 或者OS crash時存在binlog 丟失風險，binlog_sync=1:事務每次提交時，mysql server 都將binlog 同步至磁盤，安全性最高，IO 壓力最大，mysql 可以通過group commit 機制來改善IO壓力，binlog_sync=n(n>1)：每進行n次事務提交時，mysql server 將binlog 同步至磁盤，當mysql server 或者OS crash 時存在binlog 丟失風險，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/374447.html
標籤：SQL Server
下一篇：SQL 視窗函式簡介