昨天，我们在Amazon RDS上运行的MySQL实例挂起，我们被迫重启。重新启动后，我们注意到其中一个表中的其他行在崩溃之前不存在。
当在另一个表上发生更新时，这些行最初“假定”通过触发器写入此表。这是一个“审核日志”表。 “审核日志”表上有一个日期时间列，指示该行最初“应该”写入的时间。这些日期可延伸至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重新应用了这些“更新”。我的问题如下：
我不是DBA，这些可能是转储问题，但我对于出现这样的旧记录感到非常困惑！
MySQL 5.5.40。 InnoDB的
答案 0 :(得分：0)
虽然事先数据损坏的崩溃恢复可能会导致意外数据再次出现，但您所描述的内容似乎不太可能发生在它看来发生的状态。
在这种情况下，日期值可能是当前值几乎是不可想象的。没有机制可以想到，即使可以这样做，因为触发器和时钟在服务器的一层运行，并且崩溃恢复是非常不同的。
似乎更有可能有人对服务器做了一些他们不承认的事情......一个任性的查询或应用程序错误或备份文件的不正确播放......最后的可能性甚至可以解释为什么你认为服务器＆ ＃34;雄＆＃34。使用默认配置加载由mysqldump生成的备份文件时，它会在加载新数据时锁定每个表。
如果您仍然可以访问二进制日志（不太可能，因为RDS会非常快速地清除它们，除非您没有对其进行配置），那么可能会更多地了解发生的事情。
如果是我，我会尝试的另一种方法是在昨天中断之前做一个时间点恢复。这会创建一个新实例（它不会破坏现有实例）。从该快照中，检查相关表的内容并验证它们包含您当前所期望的内容可能会很有趣。