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

第5602行的错误1114（HY000）：表“样本”已满

该文件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

事实

您说您正在使用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章：“存储引擎” Page 203第3,4段说：

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

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

分析

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

可是等等...

您可能在说“我正在加载一个空Sample表”。如何涉及撤消日志？在Sample表中加载93GB数据之前，该表为空。代表不存在的每一行必须在“撤消日志”中占用一些房屋清洁空间。考虑到涌入的数据量，填满1023个撤消日志似乎微不足道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系统表（aka 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再次正常工作。

我遇到了同样的问题，我只做了一件事情就奏效了。

您innodb_data_file_path的my.cnf配置文件中的最大大小似乎太小。只需更改以下代码-

innodb_data_file_path = ibdata1:10M:autoextend:max:512M

重要说明512MB在所有InnoDB 组合的表中，您承载的数据不能超过总数。

您还可以使用切换到每表一个innodb方案innodb_file_per_table。