從存儲引擎與MySQL的存儲28錯誤

Question

我的存儲設備有問題。 我收到此錯誤

 Got error 28 from storage engine 

我已經檢查了存儲容量，它仍然可用，並且沒有滿。 這可能是什么原因？ 我檢查了一切都沒有成功

可能我的主mysql數據目錄或mysql tmp用盡了。 有人可以告訴我如何找到自己的位置以進行檢查嗎？

Answer 1

可能我的主mysql數據目錄或mysql tmp用盡了。 有人可以告訴我如何找到自己的位置以進行檢查嗎？

TL; DR

發出以下命令分別檢查服務器數據和臨時目錄的位置：

SHOW GLOBAL VARIABLES LIKE 'datadir'
SHOW GLOBAL VARIABLES LIKE 'tmpdir'

這些變量的值通常是絕對路徑（相對於運行服務器的任何chroot監獄），但是如果它們恰好是相對路徑，則它們將相對於啟動服務器的進程的工作目錄。

然而...

如“ MySQL數據目錄” （已添加重點）所述：

以下列表簡要描述了通常在數據目錄中找到的項目...

通過重新配置服務器，可以將上述列表中的某些項目重新放置在其他位置。 另外，使用--datadir選項可以更改數據目錄本身的位置。 對於給定的MySQL安裝，請檢查服務器配置以確定是否已移動項目。

因此，您可能還希望檢查許多其他變量的值，包括：

• pid_file
• ssl_%
• %_log_file
• innodb_data_home_dir
• innodb_log_group_home_dir
• innodb_temp_data_file_path
• innodb_undo_directory
• innodb_buffer_pool_filename

如果您的服務器沒有響應...

您還可以檢查服務器的啟動配置。

如在“ 指定程序選項”下記錄的，“ 通過檢查環境變量，然后通過處理選項文件，然后通過檢查命令行 ”來確定服務器的啟動配置，其中優先於較早選項的較新選項。

該文檔還列出了在Unix和類似Unix的系統上讀取的選項文件的位置（如果需要）。 請注意，服務器讀取的那些文件的部分由服務器啟動的方式決定，如服務器命令選項的第二和第三段所述。

Answer 2

找到MySQL存儲文件的位置后，在shell中運行命令：

df -Ph <pathname>

其中<pathname>是要測試的每個位置。 一些磁盤可能位於同一磁盤卷上，因此當df報告它們時，它們將顯示為相同的磁盤卷。

[vagrant@localhost ~]$ mysql -e 'select @@datadir'
+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+

[vagrant@localhost ~]$ df -Ph /var/lib/mysql
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00   38G  3.7G   34G  10% /

這告訴我datadir的磁盤卷是根卷，包括頂級目錄“ / ”及其下的所有內容。 該卷已滿10％，未使用34G。

如果datadir達到100％的卷，那么當您插入新數據並且需要擴展MySQL表空間或寫入日志文件時，您將開始看到errno 28問題。

在這種情況下，您需要弄清楚正在占用多少空間。 它可能在MySQL目錄下，或者像我這樣，您的datadir可能是更大的磁盤卷的一部分，而其他所有文件都位於該磁盤卷中。 在這種情況下，系統上文件的任何積累都可能導致磁盤已滿。 例如，日志文件或臨時文件，即使它們與MySQL無關。

我將從磁盤卷的頂部開始，然后使用du找出哪些目錄已滿。

[vagrant@localhost ~]$ sudo du -shx /*
33M     /boot
34M     /etc
40K     /home
28M     /opt
4.0K    /tmp
2.0G    /usr
941M    /vagrant
666M    /var

注意：如果df命令告訴您datadir在單獨的磁盤卷上，則應從該卷的安裝點開始。 一個磁盤卷使用的空間不計入另一磁盤卷。

現在，我看到/usr占用了頂層目錄的最大空間。 向下鑽取，看看在此之下占用了什么空間：

[vagrant@localhost ~]$ sudo du -shx /usr/*
166M    /usr/bin
126M    /usr/include
345M    /usr/lib
268M    /usr/lib64
55M     /usr/libexec
546M    /usr/local
106M    /usr/sbin
335M    /usr/share
56M     /usr/src

繼續逐級向下鑽取。

通常，罪魁禍首最終變得非常清晰。 就像您有一些巨大的500G日志文件/var/log ，這個文件已經增長了幾個月。

HTTP服務器日志就是典型的罪魁禍首。

---

對您的評論：

聽起來您有一個單獨的數據庫存儲卷。 那很好。

您剛剛將du輸出添加到上面的問題中。 我看到在您的1.4T磁盤卷中，迄今為止最大的單個文件是：

1020G   /vol/db1/mysql/_fool_Gerg_sql_200e_4979_main_16419_2_18.tokudb$

這似乎是一個TokuDB表空間。 此處提供有關TokuDB如何處理完整磁盤的信息： https ://www.percona.com/doc/percona-server/LATEST/tokudb/tokudb_faq.html#full-disks

我不會刪除這些文件。 我對TokuDB的了解不如對InnoDB的了解，但我認為這些文件是重要的數據文件。 如果刪除它們，則將丟失部分數據，並且可能會破壞其余數據。

我發現了這篇文章，其中詳細說明了文件的用途： https : //www.percona.com/blog/2014/07/30/examining-the-tokudb-mysql-storage-engine-file-structure/

該手冊還說：

從現有表中刪除大量行，然后關閉表可能會釋放一些空間，但可能不會。 刪除行可能只是在TokuDB數據文件中留下未使用的空間（可用於新插入），而不是縮小文件（內部碎片）。

因此，您可以從表中刪除行，但是磁盤上的物理文件可能不會縮小。 最終，您可以釋放足夠的空間來使用ALTER TABLE <tablename> ENGINE=TokuDB ROW_FORMAT=TOKUDB_SMALL;來構建新的TokuDB數據文件ALTER TABLE <tablename> ENGINE=TokuDB ROW_FORMAT=TOKUDB_SMALL; （請參閱https://dba.stackexchange.com/questions/48190/tokudb-optimize-table-does-not-reclaim-disk-space ）

但這將需要足夠的可用磁盤空間來構建新表。

所以，恐怕您已經把自己畫在了一個角落。 您不再有足夠的磁盤空間來重建大型表。 您絕不能讓可用磁盤空間小於重建最大表所需的空間。

此時，您可能必須使用mysqldump從最大表中轉儲數據。 不一定是整個表，而是您想要保留的表（了解mysqldump --where選項）。 然后DROP TABLE以完全刪除該大表。 我認為這將釋放磁盤空間，而使用DELETE則不會。

db1卷上沒有足夠的空間來保存轉儲文件，因此您必須將其保存到另一個卷。 看來您在/ vol / cbgb1上有更大的音量，但我不知道它是否已滿。

我會把整個東西丟掉，以備存檔之用。 然后再次轉儲一個子集。

mkdir /vol/cbgdb1/backup
mysqldump fool Gerg | gzip -c > /vol/cbgdb1/backup/Gerg-dump-full.sql.gz
mysqldump fool Gerg --where "id > 8675309" | gzip -c > /vol/cbgb1/backup/Gerg-dump-partial.sql.gz

我完全在猜測--where的參數。 您必須決定如何選擇部分轉儲。

刪除大表后，重新加載轉儲的部分數據：

gunzip -c /vol/cbgb1/backup/Gerg-dump-partial.sql.gz | mysql fool

如果我在示例中給出了您不太了解的命令，建議您在嘗試之前先學習它們。 或找到與這些命令更熟悉的人配對。