AWS RDS MySQL Bin更改日志

Question

昨天，我们在Amazon RDS上运行的MySQL实例挂起，我们被迫重启。 重新启动后，我们注意到其中一个表中的其他行在崩溃前不存在。

这些行本来是“应该”在另一个表上发生更新时通过触发器写入该表的。 这是一个“审核日志”表。 “审核日志”表上有一个datetime列，指示该行最初“应”要写入的时间。 这些日期可以追溯到3年前！ 重新启动后，添加了大约7,000行！ 当该行实际写入“审核日志”表中并且具有昨天的日期时，触发器会生成一个日期值！

在重新启动期间，RDS MySQL日志中包含此代码段。

InnoDB: Log scan progressed past the checkpoint lsn 181143261075
150922 17:07:44  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 181143275223
150922 17:07:51  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 40603, file name /rdsdbdata/log/binlog/mysql-bin-changelog.268331
150922 17:07:51  InnoDB: Waiting for the background threads to start
150922 17:07:52 InnoDB: 5.5.40 started; log sequence number 181143275223
150922 17:07:52 [Note] Recovering after a crash using /rdsdbdata/log/binlog/mysql-bin-changelog
150922 17:07:52 [Note] Starting crash recovery...
150922 17:07:52 [Note] Crash recovery finished.

显然，由于崩溃，MySQL重新应用了这些“更新”。 我的问题如下：

• 这个innoDB bin事务日志在世界范围内将有多少年前应该写的记录？
• 如果这些行的触发器失败，则更新SQL语句将失败，对吗？ 我们的代码配置为然后回滚事务。

我绝对不是DBA，这些问题可能是转储问题，但我非常困惑要出现这样的旧记录！

MySQL 5.5.40。 创新数据库

Answer 1

尽管在很早的时候由于先前的数据损坏而导致的崩溃恢复可能导致意外的数据重新出现，但是您所描述的似乎不太可能按照看起来发生的方式发生。

在这种情况下，日期值可能是当前值几乎是不可想象的。 没想到哪一种机制可以做到这一点，因为触发器和时钟运行在服务器的一层，而崩溃恢复则是完全不同的。

似乎更有可能有人对服务器做了一些他们不承认的事情……一个任性的查询或应用程序错误或备份文件的播放不正确……最后一种可能性甚至可以解释您为何认为服务器“挂起”。 当您使用默认配置加载由mysqldump生成的备份文件时，它将在加载新数据时锁定每个表。

如果您仍然可以访问二进制日志（不太可能，因为RDS会非常快地清除它们，除非您配置为不这样做），则有可能了解更多有关发生的情况的信息。

如果是我，我会尝试的另一种方法是在昨天中断之前立即恢复时间。 这将创建一个新实例（不会破坏现有实例）。 从该快照中，检查有问题的表的内容并验证它们是否包含您期望的内容可能会很有趣。