將 mysql 5.6 數據庫遷移到 mariadb 10.2 後出現 NTFS 文件系統碎片問題

我目前遇到一個以前執行良好的數據庫伺服器的新問題。在 8 週內第二次，目前執行的 MariaDB 10.2.7 由於作業系統錯誤 665而損壞，根本原因是NTFS 文件系統。Sysinternals 實用程序 contig 應該是一個嚴重碎片化的 .ibd 文件（> 100 萬個碎片），這會導致我相信以上是問題的原因。

3 個月前，由於更好的備份功能，我從 MySQL Server 5.6 切換到 MariaDB 10.2.6。該數據庫在虛擬 Windows 2012 R2 機器上執行。以前，此設置能夠毫不費力地處理更大的數據庫，並且可以 24/7 全天候執行。底層硬體沒有發布任何錯誤，物理硬碟驅動器也沒有顯示任何錯誤。

由於這在過去 8 週內發生了兩次，我想知道 MariaDB 是否出了問題？有沒有其他人經歷過如此嚴重的數據庫文件碎片？它與 SQL Server 開關有關嗎？MariaDB my.cnf 中是否有任何我忽略的設置使其與 NTFS 配合得很好？

非常感謝您的回答！

編輯：

確切的年表如下

7 月 31 日 將現有的 500GB 數據庫寫入空的 MariaDB。這是通過解析舊數據庫並通過 INSERT 語句寫入新數據庫來完成的。這樣做是因為添加了舊版“標記”的新列。次要表（一個.ibd文件）寫入過程中，第一次出現錯誤。這導致新數據庫損壞。不幸的是，當時我認為作業系統錯誤 665 是由於 MariaDB 安裝錯誤造成的。

為了驗證這個假設，8 月 4 日重新安裝了 MariaDB，重新創建了一個空數據庫寫入 TestData 並查看錯誤是否再次發生。該數據庫從那時起一直執行到 9 月 22 日。然後再次記錄作業系統錯誤 665 並且數據庫已損壞。

這促使我更認真地查看錯誤 665 並查看數據庫文件是否存在碎片問題。1M+ 片段就是這種情況，現在只有 200GB。不幸的是，我之前從未檢查過碎片問題，因為它不是問題。寫入操作涉及來自多個來源的傳入包的 uuid 以驗證來源。此外，數據主要是 Blob 和時間戳資訊。

現在我坐在兩個損壞的 MariaDB 上。在恢復模式下，SHOW TABLE Status 會顯示錯誤，而 SHOW CREATE TABLE 在執行時會出錯。

my.cnf 如下

$$ mysqld $$ datadir=D:\Database\Data\ port=3306 max_allowed_pa​​cket=64M max_connections=251 innodb_buffer_pool_size=6G $$ client $$ 埠=3306 外掛目錄=C:/Program Files/MAriaDB 10.2/lib/plugin 該機器有 8 個 Vcor​​e，執行在 16GB RAM 上。我希望這可以為您提供所需的資訊。

主要問題是我可以在 mariadb 或 NTFS 文件分區中設置什麼來阻止此錯誤的發生嗎？

謝謝你的時間！

這是一個錯誤，我根據這個問題送出並修復了它。順便說一句，我們也有一個錯誤系統，不要猶豫直接使用它。

這是錯誤報告。https://jira.mariadb.org/browse/MDEV-13941

基本上，片段是因為稀疏文件被擴展而創建的。解決方法是不創建稀疏文件，除非使用者想要一個帶有頁面壓縮的表（這是一個很少有人會使用的奇異功能）。修復將出現在下一個 10.2（即 10.2.10），即 10 月中旬。

但是，僅升級到 10.2.10 不會自動解決現有表的問題。在安裝 10.2.10 之前，您還需要做一些其他事情

• 停止伺服器
• 在 .idb 文件上取消設置“稀疏標誌”。在提升的命令提示符下，鍵入

fsutil sparse setflag C:\path\to\table.ibd 0

• 使用 contig（或其他工具）對文件進行碎片整理

調試問題的一些問題…您從 SQL Server 進行了轉儲，然後重新載入到 MariaDB？請提供涉及的命令。只有一個 .ibd 有問題嗎？也就是說，只有一張桌子？另外，解釋轉儲記錄的順序——特別是它們是否按PRIMARY KEY順序排列。請在 MariaDB 上提供SHOW CREATE TABLE和SHOW TABLE STATUS，以及 SQL Server 上的等價物。

一個可能的解決方法…一旦您將數據載入到 MariaDB 中，請執行OPTIMIZE TABLE. 這將為該表重建 .ibd，希望消除大部分碎片。它很可能消除數據的碎片，因為（我認為）它以 PK 順序複製數據。非記錄儲存（對於大的TEXT和BLOB），加上二級索引——這些是另一回事。（這SHOWs將提供一些關於論文是否存在問題的線索。）

“8 週內兩次”——您是否暗示碎片越來越嚴重，直到作業系統發出嘶嘶聲？請解釋一下您對錶的主要寫入類型操作。（我懷疑 UUID 密鑰涉及很多。）

請提供my.cnf，儘管我不希望在那裡看到任何引人注目的東西。更能說明問題的是SHOW GLOBAL STATUS和SHOW VARIABLESRAM 大小。（太大，無法粘貼在這裡；使用 post.it 或其他東西。）最好在伺服器執行幾天之後。不知道這些輸出中會顯示什麼。

真正的解決方案可能是從 Windows 切換到 *nix。

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