我在 MySQL 5.0 中遇到了这个 InnoDB 错误。Mysqld 被彻底停止，但后来我设法丢失了 ib_logfile0 和 ib_logfile1。现在在干净启动之后，InnoDB 已经完成了它的“崩溃恢复”。我经历了innodb_force_recovery=4的业务，修复了一个挂起的MyISAM表，现在复制已经准备好了，除此之外。大数字commified：
111116 15:49:36 InnoDB: Error: page 393457 log sequence number 111 561,760,232
InnoDB: is in the future! Current system log sequence number 70 3,946,969,851.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
这是在从服务器上。上述错误数以百计。我找到了这个答案：“插入和删除 > 64 GB 的数据，以便日志序列号变得足够大”。
http://forums.mysql.com/read.php?22,50163,50163#msg-50163
64GB 的神奇数字来自 4GB*16，其中那个人的 innodb 日志“主要数字”需要从 0 增加到 15。我的从 70 增加到 111 = 164 GB。这将需要 5 天。我将继续努力加速我的脚本，并并行运行它以加快速度。同时，我希望其他人有更好的答案。这是愚蠢的。
Ica*_*sNM 10
这是一种非常罕见的情况。我希望永远不会再回到那里，因为 InnoDB“日志序列号在未来！” 错误。由于我的特殊细节，重建/恢复我的服务器数据是最后的手段。一些帮助的作弊是好主意，但最后，我决定继续改进我的 Perl 脚本来玩这个愚蠢的游戏，并尽可能多地完成每小时的演出。什么鬼，这是一个很好的系统压力测试。
请记住：目标是增加存储在ib_logfile0和ib_logfile1标头中某处的单个计数器（“日志序列号”）。这是为了伪造 InnoDB，因此它会忽略明显的时间扭曲并继续生活。但是没有人知道如何编辑那个数字。或者如果他们知道，没有人在说话。
这是我的最终产品。YMMV，但是使用mysql的REPEAT函数在内部生成数据效率很高。
#!/usr/bin/perl
use DBI;
$table = shift || die;
$dbh = DBI->connect("DBI:mysql:junk:host=localhost", "user", "pass"); #Edit "junk" (DB name), user, and pass to suit.
$dbh->do("DROP TABLE IF EXISTS $table");
$dbh->do("CREATE TABLE $table (str TEXT) ENGINE=INNODB");
$sth = $dbh->prepare("INSERT INTO $table (str) VALUES (REPEAT(?,1000000))");
foreach (1..50) {
$sth->execute('0123456789'); # 10 MB
}
$dbh->do("DELETE FROM $table");
我建议的食谱：
while true; do date; junk.pl dataX; done。观察你的 LSN 增长，也许在另一个循环中：
silly# echo "SHOW INNODB STATUS \G" | mysql -p'xxxxxx' | grep '^Log seq'
Log sequence number 124 3871092821
silly# echo "SHOW INNODB STATUS \G" | mysql -p'xxxxxx' | grep '^Log seq'
Log sequence number 124 4209892586
silly# echo "SHOW INNODB STATUS \G" | mysql -p'xxxxxx' | grep '^Log seq'
Log sequence number 125 85212387
大数是一个无符号的 32 位 INT，它将以 4GB 换行，每次增加较小的数。在上面的这种情况下，它只是从 124 滚动到 125。您的目标隐藏在mysqld.log 中，该日志首先发送给您谷歌搜索这个荒谬的解决方案。一旦你越过终点线，就是这样！吹喇叭！释放五彩纸屑！
边栏：这在 mysqld 5.0 w/REPEAT 中发现了一个有趣的错误：如果你达到 20 MB，它会翻转一些内部计数器并滚动到 ~ 96 KB。任何地方都没有警告或错误。我不打算浪费时间来追踪它。10 MB 效果很好。如果您确实达到了其他限制，它可能会抱怨。我有各种从默认增加的innodb缓冲区。调味。与往常一样，在一个窗口中查看 mysqld.log。
您有三 (3) 个选项：
reset master;在主服务器上运行（Zaps 二进制日志）service mysql stop在主站上service mysql stop在从站上service mysql start在主人上service mysql stop --skip-slave-start在从站上start slave;在从服务器上运行并让复制赶上reset master;在主服务器上运行（Zaps 二进制日志）service mysql stop在从站上service mysql stop在主人上service mysql start在主人上service mysql stop --skip-slave-start在从站上start slave;在从服务器上运行并让复制赶上这个软件工具不仅会制作一个正在运行的 master 的非侵入式副本，还会为您创建相应的 ib_logfiles。您必须设置复制
我之前已经在 StackExchange 上发布过关于这个主题的帖子
我为我雇主的网络托管公司做过很多次这些事情。一位客户有 3.7TB 的空间需要移动，大约需要 16 个小时。相比之下，64GB 非常小。
| 归档时间： |
|
| 查看次数： |
43824 次 |
| 最近记录： |