修復郵箱日誌中的 Zimbra“資料庫錯誤：資料庫故障/損壞”：安全診斷和恢復

Zimbra 信箱日誌中的「資料庫錯誤：資料庫故障」只是一個症狀，而非診斷結果。它可能指向資料庫已停止運作、連接失敗、磁碟空間已耗盡、連接數過多，或實際的表或 InnoDB 資料庫損壞。安全的修復方法取決於周圍的日誌行以及受影響的伺服器。首先進行唯讀檢查，保護數據，切勿僅因為出現“損壞”字樣就運行通用的修復命令。

本指南使用 Zimbra 技術中心文件中記錄的常用 Zimbra 路徑和命令。部分相關 Wiki 頁面已存檔或未完成，因此請務必使用 Zimbra官方文件索引，根據您的 Zimbra 版本和發行版確認每個命令和復原步驟。以下範例不針對特定版本。

mailbox.log 中的資料庫故障究竟代表什麼？

Zimbra 的郵件資料庫儲存郵箱元數據，例如資料夾、標籤、郵件狀態以及指向郵件檔案的指標。搜尋索引單獨存儲，郵件內容則儲存在郵件儲存區。因此，資料庫錯誤並不一定意味著所有郵件檔案都已損壞。索引錯誤本身也無法證明資料庫已損壞。 Zimbra 在其伺服器架構參考文件中描述了這些獨立的儲存區。

關鍵線索通常是出現在郵箱異常附近的底層資料庫錯誤，尤其是在[此處應填寫具體位置/opt/zimbra/log/mysql_error.log]。 Zimbra 的故障排除說明指出[此處應填寫具體位置]mailbox.log和[此處應填寫具體位置]mysql_error.log是有用的起點，其中[此處應填寫具體位置]zmmailboxd.out提供了郵箱服務啟動詳細資訊。請參閱Zimbra 的日誌故障排除參考。

在嘗試修復之前應該做什麼？

記錄首次發生異常的時間、時區、伺服器主機名稱、受影響的帳戶以及完整的異常資訊和附近行。共享日誌前，請對密碼、訊息內容和個人資料進行編輯。
確定問題範圍：單一郵箱、同一儲存空間中的多個郵箱，或是跨多個儲存的使用者。單一帳戶出現問題並不足以構成叢集範圍的資料庫重啟理由。
檢查是否有近期可用的備份，並確定特定版本的復原步驟。如果錯誤重複出現或使用者受到影響，請避免重複重新啟動和寫入操作，直到您了解資料庫狀態為止。
使用維護視窗進行資料庫表掃描檢查。即使是完整性檢查也會增加 I/O 並降低郵件信箱服務速度。

如何安全地進行診斷？

1. 檢查服務狀態

在郵件伺服器上，切換到 Zimbra 帳戶並檢查服務狀態。使用每個提示符中顯示的帳戶運行命令；不要將提示符（例如 `--`）貼到$命令中。

終端顯示已切換到 Zimbra 帳戶，隨後執行了 zmcontrol 狀態命令。 — 終端機顯示帳戶切換和`zmcontrol status`用於檢查 Zimbra 服務狀態的命令；但沒有顯示任何伺服器結果。

su - zimbra
zmcontrol status

請注意郵箱是否正在運行，以及所報告的問題是否僅限於單一郵箱伺服器。郵箱進程停止並不足以斷定資料庫已損壞。 Zimbra 的郵箱故障排除頁面也將服務狀態和資料庫登入/配置列為單獨的檢查項目；該頁面已標記為存檔，因此請將其作為參考，並遵循您所用版本的文件。

2. 同時比較郵箱日誌和資料庫日誌

讀取兩份日誌中相同的時間段。序列中的第一個錯誤通常比最後的“系統故障”行更有用。

使用終端命令檢查 mailbox.log 和 mysql_error.log 檔案。 — 終端機顯示從`mailbox.log`和讀取最新行的命令`mysql_error.log`，其中可以按時間戳來比較相關事件。

tail -n 100 /opt/zimbra/log/mailbox.log
tail -n 100 /opt/zimbra/log/mysql_error.log
tail -n 100 /opt/zimbra/log/zmmailboxd.out

尋找底層資料庫訊息、資料庫或郵件群組名稱、重複的時間戳記、啟動失敗或符合的作業系統錯誤。請將這些資訊視為線索，而不是自動修復方法：

日誌線索	這可能表明什麼	下一步安全行動
`Too many connections`或 MySQL 錯誤 1040	連接容量已耗盡；但這並不能證明有腐敗。	在變更限制之前，請檢查並發負載和 Zimbra 版本特定的連線設定。 Zimbra 的錯誤 1040 說明中將此情況列為一個獨立條件。
`Access denied`套接字不可用，或無法連接	憑證、服務狀態、套接字路徑或配置可能有錯誤。	請使用本版本支援的工具驗證資料庫服務和配置；請勿透過編輯不相關版本指南中的檔案來重設密碼。
`No space left`只讀檔案系統或 I/O 錯誤	儲存或檔案系統故障可能會阻止資料庫寫入和啟動。	在重新啟動或修復之前，請檢查可用空間、inode、掛載狀態和系統日誌。
重複出現 InnoDB 斷言、頁面、表空間或校驗和錯誤	可能存在底層資料庫損壞或儲存損壞。	保留目前資料和備份狀態，然後使用受支援的復原或供應商協助的復原計畫。
缺少表或架構/版本不匹配	可能是升級失敗、資料庫目標錯誤或架構問題導致的。	比較伺服器版本和升級歷史記錄；不要手動建立、刪除或重新命名表。

3. 檢查磁碟容量和作業系統錯誤

資料或日誌卷已滿、inode 耗盡或儲存故障都可能看起來像是資料庫故障。請在儲存主機上執行非破壞性檢查：

終端機顯示 opt zimbra 路徑的磁碟空間和 inode 檢查結果 — 終端機顯示`df`對 Zimbra 路徑上的可用檔案系統空間和 inode 的檢查結果；未顯示容量結果。

df -h /opt/zimbra
df -i /opt/zimbra

檢查作業系統日誌或系統日誌，查看同一時間範圍內是否有磁碟 I/O、檔案系統或記憶體不足錯誤。如果磁碟區已滿，請使用常規儲存流程釋放或新增空間。切勿刪除資料庫檔案、InnoDB 日誌或活動 Zimbra 日誌來騰出空間；這樣做可能會增加復原難度或破壞證據。

4. 僅在審查影響後才執行完整性檢查

如果 Zimbra 的資料庫服務可訪問，且日誌中尚未顯示明顯的連接或儲存問題，管理員可以在低流量維護視窗期間考慮產生標準完整性報告：

Zimbra 使用者終端機顯示標準的 zmdbintegrityreport 指令，不包含修復選項。 — 終端機顯示標準完整性報告命令，但沒有自動修復選項；也沒有顯示報告結果。

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

Zimbra 的完整性報告參考文件將其描述為資料庫檢查，並警告這可能會增加 I/O 操作並提高郵箱延遲。文件還記錄了一個-r嘗試自動修復表的選項。請勿將其-r作為常規的後續步驟：該頁面標記為正在開發中，正確的操作取決於資料庫引擎、表格類型、產品版本和備份狀態。如果報告僅提及已知的無害日誌表鎖定訊息，則應根據該頁面上的說明進行解讀；不要將所有「發現資料庫錯誤」標題都視為相同。

哪個解決方案符合證據？

資料庫服務已停止，但未發現任何損壞跡象：請先解決特定的啟動、設定、憑證或資源錯誤。修正錯誤後，請使用適用於您的版本和部署拓撲的服務復原流程。避免反覆盲目重啟。
連線數過多：請調查負載、客戶端阻塞和服務容量。不要將其誤判為資料庫損壞，也不要未經核實當前配置和發布指南就照搬舊的提高限制的建議。
磁碟或檔案系統問題：穩定儲存並確認檔案系統運作狀況良好。如果資料庫記錄了寫入失敗或 InnoDB 錯誤，即使空間已恢復，也應將其視為潛在的完整性事件。
完整性報告會標記表：請儲存完整的輸出結果、表格/資料庫名稱、時間戳記和相關日誌。在進行任何寫入作業之前，請使用受支援的方法備份資料庫磁碟區或建立快照。請管理員依照供應商提供的已安裝 Zimbra 版本的修復或還原步驟進行操作。
即使資料庫引擎運作正常，仍有一個帳戶受到影響：請分別檢查其郵箱元資料、郵件儲存或索引。避免手動編輯 SQL 行或刪除檔案來「重建」帳戶。

對於疑似 InnoDB 損壞的情況，最安全的修復方法通常是從經過驗證的備份中進行特定版本的恢復，或者在技術支援的指導下進行恢復，而不是使用通用的REPAIR TABLE資料庫重新初始化或複製命令序列。一些舊的 Zimbra Wiki 復原文章包含破壞性步驟，並且已明確存檔；未經 Zimbra 支援部門的直接確認和經過測試的備份，請勿將這些步驟應用於當前系統。

如何確認問題已解決？

批准糾正措施後，請確認資料庫和郵箱服務保持正常運行，新條目不再顯示相同的底層資料庫錯誤，並且受影響的帳戶可以執行正常的郵件操作。只有當您的載入視窗和版本適用時，才重新執行標準完整性報表。確認備份作業已完成，並保留日誌和修復記錄。如果問題再次出現，請將準確的 Zimbra 版本/內部版本號、單一伺服器或多伺服器佈局、郵件範圍、首次故障時間、相關日誌摘錄、磁碟狀態、完整性報告輸出以及備份時間戳記報告給您的管理員或 Zimbra 支援頻道。

關鍵點：在更改資料之前，請先診斷郵箱異常背後的資料庫錯誤。「資料庫故障」本身無法判斷修復方法是憑證更正、容量變更、儲存修復還是資料庫復原。

主要參考資料：Zimbra 文件索引；Zimbra 伺服器架構；Zimbra 日誌故障排除；Zimbra 資料庫完整性報告參考；Zimbra MySQL 錯誤 1040 參考；以及Zimbra 郵箱故障排除參考。如文章所述，部分技術中心頁面已存檔或標記為正在開發中。