我的存储有问题。我收到了这个错误
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_dir
innodb_log_group_home_dirinnodb_temp_data_file_path
innodb_undo_directoryinnodb_buffer_pool_filename
####如果服务器没有响应。。。您还可以检查服务器的启动配置。
如指定程序选项下所述,服务器的启动配置是“通过检查环境变量,然后处理选项文件,然后检查命令行”来确定的,后面的选项优先于前面的选项。
如果需要,文档还列出了在unix和类unix系统上读取的选项文件的位置。请注意,服务器读取的这些文件的部分由服务器启动的方式决定,如服务器命令选项的第二和第三段所述。