這種通過 bat 文件關閉 MySQL 的方式是否足以最大限度地減少損壞?
我在使用 32 位 Xampp 時遇到了記憶體問題,所以我自己安裝了 64 位組件作為新伺服器。
雖然,我想確保正確停止 MySQL 數據庫伺服器。
這是否足以關閉它,以便在繁忙的開發階段頻繁停止 MySQL 不會破壞數據庫?
以下內容包含在我編寫的 bat 文件中。
@echo off "C:\host\MariaDB\bin\mysqladmin.exe" -u root -prootpass flush-tables echo Flushing DB, Hopefully. TIMEOUT 30 echo Flushed DB, I think! "C:\host\MariaDB\bin\mysqladmin.exe" -u root -prootpass shutdown echo Stopped MySQL service. pause
同樣,它可以工作,但我想確保將停止數據庫伺服器造成損壞的可能性降到最低。
提前致謝。
如果你想有效地關閉 MySQL,你需要執行幾件事
@echo off rem rem Flush Everything and its Grandmother rem echo "Stopping MySQL Service" "C:\host\MariaDB\bin\mysql.exe" -u root -prootpass -ANe"SET GLOBAL innodb_fast_shutdown=0; STOP SLAVE; FLUSH BINARY LOGS; FLUSH TABLES" "C:\host\MariaDB\bin\mysqladmin.exe" -u root -prootpass shutdown echo "Stopped MySQL Service" pause
第一行執行以下操作
STOP SLAVE
: 如果這個 MySQL Service 是 Slave,它將關閉 IO 和 SQL 執行緒並關閉針對中繼日誌打開的文件句柄。如果未啟用複制,這將只是一個警告。FLUSH BINARY LOGS
:如果啟用了二進制日誌,它將關閉目前的二進制日誌(刷新它),並打開一個新的(新的二進制日誌的文件大小將小於 200 字節)。如果二進制日誌被禁用,它只是一個警告。FLUSH TABLES
:這會針對所有打開的表關閉任何打開的文件句柄,提醒作業系統對記憶體中的所有表更改執行磁碟刷新。SET GLOBAL innodb_fast_shutdown=0
: innodb_fast_shutdown的預設值為1。這允許 InnoDB 暫停其在重做日誌和雙寫緩衝區中的更改。因此,下次啟動 MySQL 服務時將應用更改。這也稱為啟動時的崩潰恢復。通過將innodb_fast_shutdown設置為 0,這會導致 InnoDB 在關閉期間應用更改。這將導致 MySQL 服務啟動更快,因為它不需要進行崩潰恢復。我曾多次寫過關於使用innodb_fast_shutdown的文章
Apr 15, 2012
: Mysql Innodb: InnoDB: ERROR: 最後一個檢查點的年齡是 InnoDB: 超出了日誌組容量Mar 06, 2013
:如何正確殺死MySQL?Apr 23, 2013
:啟動/停止 MySQLMay 05, 2013
:移動 ib_logfile1 和 ib_logfile0 文件後的問題Dec 09, 2013
:從 mysql ibdata1 文件中清除舊記錄Jan 07, 2015
:刷新/清理 MySql ib_logfile0 ib_logfile1試一試 !!!
注意:所有其他命令的原因是在實際關閉過程之前關閉盡可能多的不同文件句柄。如果有任何磁碟更改,每個關閉的文件句柄都會導致表刷新。這減少了關閉過程的工作量,將注意力主要集中在前滾 InnoDB Plumbing 中的所有更改上。
這是 InnoDB 的圖形表示
這張照片由 Percona 首席技術官 Vadim Tkachenko 製作
這張圖片應該讓您看到停機期間哪些運動元件在運動。
更新 2016-10-13 07:45 EDT
您是說“定期”關閉實際上並沒有完全關閉數據庫引擎嗎?(尤其是它不會將所有內容刷新到磁碟?)
說到 InnoDB,關閉 MySQL 是有解釋的。這就是innodb_fast_shutdown存在的原因。文件說:
InnoDB 關閉模式。如果值為 0,InnoDB 會在關閉前進行緩慢關閉、完全清除和更改緩衝區合併。如果值為 1(預設值),InnoDB 在關閉時跳過這些操作,這個過程稱為快速關閉。如果值為 2,則 InnoDB 刷新其日誌並冷關機,就好像 MySQL 已經崩潰一樣;沒有送出的事務失去,但是崩潰恢復操作使下次啟動需要更長的時間。
在仍然緩衝大量數據的極端情況下,緩慢關閉可能需要幾分鐘甚至幾小時。在 MySQL 主要版本之間升級或降級之前使用慢速關閉技術,以便在升級過程更新文件格式時做好所有數據文件的準備。
在緊急情況或故障排除情況下使用 innodb_fast_shutdown=2,以便在數據存在損壞風險時獲得絕對最快的關閉速度。
關閉的結果將使 InnoDB 處於這三種狀態之一,其中兩種需要在啟動時的崩潰恢復期間進行一些工作。
我發布答案的原因是作業系統。在我看來,Linux 作業系統和正確的硬體為磁碟寫入和刷新提供了更好的環境。我對 Windows 沒有同樣的信心。我的建議只是在 Windows 中為 mysqld 提供額外的優勢。
InnoDB 可以整體關閉。我個人的偏好是使用innodb_fast_shutdown=0所以我不用擔心維護期間的重做日誌或擔心作業系統。