我的存储有问题。我收到了这个错误
Got error 28 from storage engine
我已经检查了存储容量，它仍然可用，但没有满。为什么会这样？我检查了一切都没有成功可能是mysql数据主目录或mysql tmp中的数据用完了。有人能告诉我如何找到他们的位置来检查一下吗？
voase2hg1#
找到mysql存储文件的位置后，在shell中运行命令：
df -Ph <pathname>
哪里 <pathname> 是要测试的每个位置。有些可能在同一个磁盘卷上，因此在报告时显示为相同 df .
<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 找出哪些目录已经满了。
/
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 占用了顶级目录中最多的空间。深入查看下面的空间：
/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磁盘卷中，到目前为止最大的单个文件是：
/var/log
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-磁盘我不会删除那些文件。我对tokudb不像对innodb那么熟悉，但我认为那些文件是重要的数据文件。如果删除它们，则会丢失部分数据，并可能损坏其余数据。我找到了这篇文章，详细解释了这些文件的用途：https://www.percona.com/blog/2014/07/30/examining-the-tokudb-mysql-storage-engine-file-structure/手册还说：从现有表中删除大量行，然后关闭该表可能会释放一些空间，但可能不会。删除行可能只是在tokudb数据文件中留下未使用的空间（可用于新插入），而不是收缩文件（内部碎片）。因此，您可以从表中删除行，但磁盘上的物理文件可能不会收缩。最终，您可以释放足够的空间来构建一个新的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 从最大的表中转储数据。不一定是整张table，而是你想要保留的东西（阅读关于 mysqldump --where 选项）。那么 DROP TABLE 把那张大table完全搬走。我假设这会释放磁盘空间，而使用delete则不会。db1卷上没有足够的空间来保存转储文件，因此必须将其保存到另一个卷。看起来您在/vol/cbgb1上有一个更大的卷，但我不知道它是否已满。为了存档，我会把所有的东西都扔了。然后用子集再次转储。
ALTER TABLE <tablename> ENGINE=TokuDB ROW_FORMAT=TOKUDB_SMALL;
mysqldump
mysqldump --where
DROP TABLE
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 . 您必须决定如何选择部分转储。删除大表后，重新加载转储的部分数据：
--where
gunzip -c /vol/cbgb1/backup/Gerg-dump-partial.sql.gz | mysql fool
如果我在例子中给出的命令你还不太了解，我建议你在尝试之前先学习它们。或者找一个更熟悉这些命令的人来配对。
thigvfpy2#
可能是mysql数据主目录或mysql tmp中的数据用完了。有人能告诉我如何找到他们的位置来检查一下吗？
发出以下命令，分别检查服务器的数据目录和临时目录的位置：
SHOW GLOBAL VARIABLES LIKE 'datadir' SHOW GLOBAL VARIABLES LIKE 'tmpdir'
这些变量的值通常是绝对路径（相对于任何 chroot 但如果它们恰好是相对路径，则它们将相对于启动服务器的进程的工作目录。
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系统上读取的选项文件的位置。请注意，服务器读取的这些文件的部分由服务器启动的方式决定，如服务器命令选项的第二和第三段所述。
--datadir
ssl_%
innodb_data_home_dir
innodb_temp_data_file_path
innodb_buffer_pool_filename
2条答案
按热度按时间voase2hg1#
找到mysql存储文件的位置后，在shell中运行命令：
哪里
<pathname>是要测试的每个位置。有些可能在同一个磁盘卷上，因此在报告时显示为相同df.这告诉我datadir的磁盘卷是根卷，包括顶级目录“
/“还有那下面的一切。容量已满10%，未使用34g。如果datadir所在的卷达到100%，那么当您插入新数据并且需要扩展mysql表空间或写入日志文件时，您将开始看到errno 28问题。
在这种情况下，你需要找出是什么占据了这么多的空间。它可能在mysql目录下，或者在我的例子中，您的datadir可能是一个更大的磁盘卷的一部分，您的所有其他文件都存在于这个磁盘卷中。在这种情况下，系统上任何文件的累积都可能导致磁盘填满。例如，日志文件或临时文件，即使它们与mysql无关。
我从磁盘卷的顶部开始使用
du找出哪些目录已经满了。注意：如果您的
df命令告诉您datadir位于一个单独的磁盘卷上，您可以从该卷的装入点开始。一个磁盘卷使用的空间不计入另一个磁盘卷。现在我明白了
/usr占用了顶级目录中最多的空间。深入查看下面的空间：一层一层往下钻。
通常罪魁祸首都很清楚。就像你有一个500g的大日志文件
/var/log已经生长了几个月的地方。一个典型的罪魁祸首是http服务器日志。
请回复您的意见：
听起来您有一个单独的存储卷用于数据库存储。那很好。
你刚刚添加了
du以上问题的输出。我看到在您的1.4t磁盘卷中，到目前为止最大的单个文件是：这似乎是一个tokudb表空间。这里有关于tokudb如何处理完整磁盘的信息：https://www.percona.com/doc/percona-server/latest/tokudb/tokudb_faq.html#full-磁盘
我不会删除那些文件。我对tokudb不像对innodb那么熟悉，但我认为那些文件是重要的数据文件。如果删除它们，则会丢失部分数据，并可能损坏其余数据。
我找到了这篇文章，详细解释了这些文件的用途：https://www.percona.com/blog/2014/07/30/examining-the-tokudb-mysql-storage-engine-file-structure/
手册还说：
从现有表中删除大量行，然后关闭该表可能会释放一些空间，但可能不会。删除行可能只是在tokudb数据文件中留下未使用的空间（可用于新插入），而不是收缩文件（内部碎片）。
因此，您可以从表中删除行，但磁盘上的物理文件可能不会收缩。最终，您可以释放足够的空间来构建一个新的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从最大的表中转储数据。不一定是整张table，而是你想要保留的东西（阅读关于mysqldump --where选项）。那么DROP TABLE把那张大table完全搬走。我假设这会释放磁盘空间，而使用delete则不会。db1卷上没有足够的空间来保存转储文件，因此必须将其保存到另一个卷。看起来您在/vol/cbgb1上有一个更大的卷，但我不知道它是否已满。
为了存档，我会把所有的东西都扔了。然后用子集再次转储。
我完全在猜测
--where. 您必须决定如何选择部分转储。删除大表后，重新加载转储的部分数据：
如果我在例子中给出的命令你还不太了解，我建议你在尝试之前先学习它们。或者找一个更熟悉这些命令的人来配对。
thigvfpy2#
可能是mysql数据主目录或mysql tmp中的数据用完了。有人能告诉我如何找到他们的位置来检查一下吗？
热释光；博士
发出以下命令，分别检查服务器的数据目录和临时目录的位置：
这些变量的值通常是绝对路径（相对于任何
chroot但如果它们恰好是相对路径，则它们将相对于启动服务器的进程的工作目录。然而。。。
如mysql数据目录下所述（强调部分已添加）：
下面的列表简要描述了通常在数据目录中找到的项。。。
通过重新配置服务器，可以将前面列表中的某些项重新定位到其他位置。此外
--datadir选项允许更改数据目录本身的位置。对于给定的mysql安装，请检查服务器配置以确定项目是否已被移动。因此，您可能还希望检查许多其他变量的值，包括：
pid_file
ssl_%%_log_fileinnodb_data_home_dirinnodb_log_group_home_dirinnodb_temp_data_file_pathinnodb_undo_directoryinnodb_buffer_pool_filename####如果服务器没有响应。。。您还可以检查服务器的启动配置。
如指定程序选项下所述，服务器的启动配置是“通过检查环境变量，然后处理选项文件，然后检查命令行”来确定的，后面的选项优先于前面的选项。
如果需要，文档还列出了在unix和类unix系统上读取的选项文件的位置。请注意，服务器读取的这些文件的部分由服务器启动的方式决定，如服务器命令选项的第二和第三段所述。