我遇到存储问题。我收到了这个错误
Got error 28 from storage engine
我已经检查了存储容量，它仍然可用且未满。这可能是什么原因？我检查了一切没有成功
我可能正在运行主mysql数据目录，或者在mysql tmp中。有人能告诉我如何找到自己的位置以便检查它吗？
答案 0 :(得分：1)
我可能正在运行主mysql数据目录，或者在mysql tmp中。有人能告诉我如何找到他们的位置以便检查它吗？
发出以下命令分别检查服务器数据和临时目录的位置：
SHOW GLOBAL VARIABLES LIKE 'datadir'
SHOW GLOBAL VARIABLES LIKE 'tmpdir'
这些变量的值通常是绝对路径（相对于运行服务器的任何chroot jail），但如果它们碰巧是相对路径，那么它们将相对于进程的工作目录启动了服务器。
正如The MySQL Data Directory所述（强调补充）：
以下列表简要介绍了数据目录中常见的项目......
通过重新配置服务器，可以将上述列表中的某些项重新定位到其他位置。此外，
--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 您还可以检查服务器的启动配置。
如Specifying Program Options所述，通过检查环境变量，然后处理选项文件，然后检查命令行来确定服务器的启动配置＆＃34; >＆＃34;后面的选项优先于先前的选项。
如果您需要，文档还会列出Option Files Read on Unix and Unix-Like Systems的位置。请注意，服务器读取的那些文件的部分由服务器启动的方式决定，如Server Command Options的第二和第三段所述。
答案 1 :(得分：0)
找到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
我不会删除这些文件。我对InnuDB并不熟悉TokuDB，但我认为这些文件是重要的数据文件。如果删除它们，您将丢失部分数据，并可能损坏其余数据。
我发现了这篇文章，详细解释了文件的用途：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数据文件（请参阅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
如果我在我的例子中给出了你还不熟悉的任何命令，我建议你在尝试之前先学习它们。或者找一个与更熟悉这些命令的人配对。