`ERROR 1114 (HY000) the table ... is full` innodb_file_per_table 设置为 autoextend

Question

我有一个 MySQL 数据库，其中包含大量数据（100-200GB - 一堆科学测量值）。绝大多数数据存储在一张表中Sample。现在我正在创建数据库的从属副本，我想innodb_file_per_table在此过程中利用它的优势。所以我设置innodb_file_per_table了我的从属配置并导入了数据库的转储。令我惊讶的是，它失败了

第 5602 行的 ERROR 1114 (HY000)：表 'Sample' 已满

该文件Sample.ibd目前约为 93GB，分区上有超过 600GB 的可用空间，因此这不是磁盘可用空间问题。它似乎没有达到任何类型的文件系统限制（我使用的是 ext4）。

对于可能是什么原因或要调查什么的任何想法，我将不胜感激。

---

更新：我正在使用mysql Ver 14.14 Distrib 5.1.66, for debian-linux-gnu (x86_64).

SELECT @@datadir; -- returns `/home/var/lib/mysql/`
SHOW VARIABLES LIKE '%innodb_data_file_path%'; -- ibdata1:10M:autoextend 

df -h /home/var/lib/mysql/
768G   31G  699G   5% /home

Answer 1

事实

你说你正在使用ext4. 文件大小限制为 16TB。因此，Sample.ibd不应充满。

你说你的innodb_data_file_path是ibdata1:10M:autoextend。因此，除了操作系统之外，ibdata1 文件本身没有大小上限。

为什么会出现这条消息？请注意消息是“表...已满”，而不是“磁盘...已满”。此表已满情况是从逻辑角度来看的。想想 InnoDB。正在发生什么交互？

我的猜测是 InnoDB 试图将 93GB 的数据作为单个事务加载。Table is Full消息会从哪里发出？我会查看 ibdata1，不是根据它的物理大小（您已经排除了），而是根据达到的交易限制。

当启用innodb_file_per_table并且您将新数据加载到 MySQL时，ibdata1 里面有什么？

• 数据字典
• 双写缓冲区
  • 防止数据损坏的安全网
  • 帮助绕过操作系统进行缓存
• 插入缓冲区（简化对二级索引的更改）
• 回滚段
• 撤消日志
• 单击此处查看图示 ibdata1

我的怀疑告诉我，撤消日志和/或重做日志是罪魁祸首。

这些日志是什么？根据书

第 10 章：“存储引擎” 第 203 页 第 3,4 段说明如下：

InnoDB 引擎保留两种类型的日志：撤消日志和重做日志。撤消日志的目的是回滚事务，以及为在需要它的事务隔离级别中运行的查询显示旧版本的数据。处理撤消日志的代码可以在storage/innobase/buf/log/log0log.c 中找到。

重做日志的目的是存储用于崩溃恢复的信息。它允许恢复过程重新执行在崩溃前可能已完成或未完成的事务。重新执行这些事务后，数据库将进入一致状态。处理重做日志的代码可以在storage/innobase/log/log0recv.c 中找到。

分析

ibdata1 中有 1023 条撤消日志（请参阅回滚段和撤消空间）。由于撤消日志保留了重新加载之前出现的数据副本，因此所有 1023 个撤消日志都已达到其限制。从另一个角度来看，所有 1023 条撤消日志可能专用于加载Sample表的一个事务。

可是等等...

您可能会说“我正在加载一张空Sample表”。撤消日志如何涉及？在该Sample表加载 93GB 数据之前，它是空的。表示不存在的每一行都必须占用撤消日志中的一些清理空间。考虑到涌入ibdata1. 我不是第一个怀疑这一点的人：

在 MySQL 4.1 文档中，请注意Posted by Chris Calender on September 4 2009 4:25pm：

请注意，在 5.0（5.0.85 之前）和 5.1（5.1.38 之前）中，如果 InnoDB 用完撤消槽，您可能会收到 InnoDB 表的“表已满”错误（错误 #18828）。

这是 MySQL 5.0 的错误报告：http : //bugs.mysql.com/bug.php?id=18828

建议

创建Sample表的mysqldump时，请使用--no-autocommit

mysqldump --no-autocommit ... mydb Sample > Sample.sql

这将COMMIT;在每个INSERT. 然后，重新加载表。

如果这不起作用（您不会喜欢这个），请执行此操作

mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql

这将使每个 INSERT 只有一行。mysqldump 会大得多（大 10 倍以上），重新加载可能需要 10 到 100 倍的时间。

在任何一种情况下，这都会避免撤消日志被淹没。

试一试 ！！！

更新 2013-06-03 13:05 EDT

附加建议

如果 InnoDB 系统表（又名 ibdata1）达到文件大小限制并且无法使用撤消日志，您可以添加另一个系统表空间（ibdata2）。

我前两天刚遇到这种情况。我用我所做的更新了我的旧帖子：请参阅数据库设计 - 创建多个数据库以避免表大小限制的头痛

本质上，您必须更改innodb_data_file_path以容纳新的系统表空间文件。让我解释一下如何：

设想

在磁盘 (ext3) 上，我客户端的服务器具有以下内容：

[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql     362807296 Jun  2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun  2 00:15 ibdata2

设置是

innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M

请注意，ibdata2增长到 2196875759616，即2145386484M.

我不得不将文件大小嵌入ibdata2innodb_data_file_path 并添加ibdata3

innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend

当我重新启动 mysqld 时，它起作用了：

[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql     362807296 Jun  3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun  3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql   32315015168 Jun  3 17:02 ibdata3

40小时后，ibdata3增长到31G。MySQL 又开始工作了。