Sample中。现在，我正在创建数据库的从属副本，我想在此过程中利用innodb_file_per_table的优势。因此，我在从属配置中设置了innodb_file_per_table并导入了数据库的转储。令我惊讶的是，它失败，并在第5602行出现了错误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
#1 楼
事实您说您正在使用
ext4。文件大小限制为16TB。因此，Sample.ibd应该不满。您说您的
innodb_data_file_path是ibdata1:10M:autoextend。因此，ibdata1文件本身没有大小限制，除了操作系统之外。为什么此消息完全出现？请注意消息是“表...已满”，而不是“磁盘...已满”。从逻辑角度来看，此表已满。考虑一下InnoDB。发生了什么交互？
我的猜测是InnoDB试图通过单个事务加载93GB的数据。
Table is Full消息将从何处发出？我会看ibdata1，而不是看它的物理大小（您已经排除了它），而是看要达到什么事务限制。启用innodb_file_per_table时，ibdata1的内容将新数据加载到MySQL中？
数据字典
双写缓冲区
安全网防止数据损坏
帮助用于缓存的绕过操作系统
插入缓冲区（简化对二级索引的更改）
回滚段
撤消日志
单击此处查看
ibdata1的图形表示我的怀疑告诉我，应该归咎于撤消日志和/或重做日志。
这些日志是什么？根据该书
第10章：“存储引擎” Page 203第3,4段说以下内容：
InnoDB引擎保留两种类型的日志：撤消日志和重做日志。撤消日志的目的是回滚事务，并显示在需要它的事务隔离级别中运行的查询的较旧版本的数据。可在storage / innobase / buf / log / log0log.c中找到处理撤消日志的代码。
重做日志的目的是存储要在崩溃恢复中使用的信息。它允许恢复过程重新执行崩溃前可能已完成或未完成的事务。重新执行这些事务后，数据库进入一致状态。可以在storage / innobase / log / log0recv.c中找到处理重做日志的代码。
ANALYSIS
ibdata1中有1023个撤消日志（请参见回滚段和撤消空间）。由于撤消日志保留了重新加载前显示的数据副本，因此所有1023撤消日志都已达到其限制。从另一个角度看，所有1023个撤消日志都可能专用于加载
Sample表的一个事务。但请等待...
您可能会说“我正在加载一个空的
Sample表”。如何涉及撤消日志？在向Sample表加载93GB数据之前，该表为空。代表不存在的每一行必须在“撤消日志”中占用一些清理房间的空间。鉴于涌入ibdata1的数据量，填写1023撤消日志似乎微不足道。我不是第一个怀疑此问题的人：从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
建议
创建mysqldump时
Sample表，请使用--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）。
我两天前才遇到这种情况。我用以前的工作更新了我的旧文章：请参阅数据库设计-创建多个数据库，以免造成表大小限制的麻烦。让我解释一下如何：
SCENARIO
在磁盘（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。我不得不将
ibdata2的文件大小嵌入innodb_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再次正常工作。#2 楼
我遇到了同样的问题，我只做了一件事情就成功了。innodb_data_file_path配置文件中的my.cnf的最大大小似乎太小。只需更改以下代码-innodb_data_file_path = ibdata1:10M:autoextend:max:512M
重要说明注意，在所有
512MB组合表中，您不能承载的数据超过InnoDB。还可以使用
innodb_file_per_table切换到每表一个innodb方案。
评论
我猜您的客户使用的所有者的名称正在使用一个即将推出的监视工具...谢谢，这似乎也为我解决了一个问题。
–史蒂夫
15年3月6日在7:12
我不知道这是否仍然是一个问题（希望不是）
–埃文·卡洛尔（Evan Carroll）
18年7月13日在15:08