相关疑难解决方法(0)

所以我有一个在复制流上设置的测试数据库服务器。在名称上出现了一个优化，它迅速填满了 slaves 数据目录上的空间。Mysql 尽职尽责地等待更多空间。

这个 datadir 是一个文件系统，只用作 mysql 的 datadir，所以没有其他东西可以释放。

我有一个 4 g innodb 测试表，它不是复制流的一部分，所以我想我会尝试一些东西来看看它是否有效，作为一个测试环境，如果事情出现严重错误，我并不太担心。

这是我采取的步骤

1. 冲洗了我正要移动的桌子
2. 在它上面放置了一个读锁（即使没有写入它并且它不在复制流中）
3. 将 .frm 和 .ibd 复制到带有一些空闲空间的文件系统
4. 解锁了桌子
5. 截断该表 - 这为优化完成释放了足够的空间，复制开始再次开始。
6. 停止从属/关闭 mysql
7. 将文件从 tmp 复制回数据目录
8. 重启mysql

.err 日志中没有显示任何内容，看起来不错。我连接并使用 mydb；并查看我在展示表中弄乱的表。但是，如果我尝试

select * from testtable limit 10;

我收到错误

ERROR 1146 (42S02): Table 'mydb.testtable' doesn't exist

到目前为止，我可以从所有其他表中读取数据，并且复制开始备份，没有任何抱怨。

我能做些什么来从这一点上恢复过来吗？如果需要，我可以从头开始重建它，但很好奇其他人对这次冒险的总体看法。我采取的一系列步骤是否有任何结果会导致更​​完美的结果？

如果这不是一个测试服务器，我不能只是“实时运行”看看会发生什么？如果我不得不喜欢，有什么最好的方法可以暂时释放生产从站上的空间？

我正在运行带有主/从复制（1 个主，2 个从）的 MySQL5.5。

我有一个每周运行一次并截断特定表的进程。表不大，只有几千条记录。

出于某种原因，该TRUNCATE TABLE命令需要很长时间才能执行（在主机和从机上）。执行大约需要 400K 毫秒！！当它在从站上运行时，会导致它滞后于主站。在后TRUNCATE TABLE结束，一切恢复正常。

我知道其中一个从站在执行时没有收到任何读取，TRUNCATE TABLE因为它是一个专用的从站，并且从该从站读取的进程已关闭。此外，在此从属设备上，执行所需的时间相同。

这是表结构：http : //pastebin.com/qEQB4juR

关于如何加速 TRUNCATE TABLE 的任何想法？