经过RS云服务器最近的“紧急迁移”之后，我们的服务器快照映像上的mysql数据库被certificate是从备份date过期的日子。 然而，通过受影响的webapp上传的文件已被写入文件系统。 写入数据库的相关元数据丢失，但文件本身已备份。
一旦我能够在mysql服务器启动之前手动访问mysql数据文件（服务器被configuration为在启动时启动mysql），我可以看到ib_logfile1，ib_logfile0和ibdata1的更新时间已经过去了几天。
就像这张海报一样， 服务器崩溃后mysql数据丢失 ，就好像一些caching控制器已经告诉OS / mysql服务器它已经提交了仍在caching中的数据，并且丢失了而不是刷新了。
我不能很好地包装上传的文件如何写入，但数据库数据没有。 我原以为任何caching都会刷新整个系统，而不是逐个进程。
有关这可能发生的任何build议？
更新二：
看到我的答案下面解释发生了什么事。
更新：
根据要求configuration详细信息。
RackSpace云服务器详细信息： 操作系统：Ubuntu 10.04 LTS（Lucid） 内存：1024 MB 磁盘空间：40 GB 数据中心：ORD1 服务级别：不受pipe理
root @ restore-testing：〜＃dpkg -s mysql-server ... build筑：所有 资料来源：mysql-dfsg-5.1 版本：5.1.61-0ubuntu0.10.04.1 ...
root @ restore-testing：〜＃cat / etc / fstab proc / proc proc defaults 0 0 / dev / xvda1 / ext3默认值，错误= remount-ro，noatime 0 1 / dev / xvdc1 none swap sw 0 0
我可以看到这种情况发生，取决于Innodb刷新数据的方法。
请查看你的MySQL安装使用的innodb_flush_method 。 根据设置的值（O_DSYNC或O_DIRECT），InnoDB可以将缓冲区加倍到操作系统和InnoDB缓冲池，或者InnoDB缓冲池。 如果将variables设置为仅caching到缓冲池，则在操作系统恢复过程中冲突缓冲池时，可以快速看到数据消失。 我在DBA StackExchange中写了一篇关于这个的文章 。
这是另一个有关在云中使用MySQL与裸机的链接（ 点击这里 ）。 它列举了将MySQL迁移到云环境中的三个潜在问题/挑战：
即使这些限制自该文章以来已经被克服，重新考虑关键任务数据将驻留在哪里，这是谨慎的。 考虑到你的数据刚刚发生了什么，情况尤其如此。
顺便说一句， StackOverflow在云中有一个关于MySQL优点和缺点的好post 。
为了进一步从另一方面进一步说明，云环境提供了从东海岸到西海岸的mysql实例的地理复制。 当我亲自对XEROUND数据库服务（我提供了两个公有IP）进行了30天的评估时，发现IP之间的间歇性非常差（约5-6分钟）。 你能想象在这个窗口中会因为两端崩溃而丢失数据吗？ 您的数据丢失是由于应急手动干预造成的。
恕我直言，我会切换你的MySQL数据库裸机，并使用DRBD或MySQL复制数据冗余。 您可以维护Web和App服务器的所有云服务。
虽然innodb_flush_method某些设置与某些硬件相结合可能会导致硬件故障导致数据丢失，但innodb_flush_method和innodb_flush_log_at_trx_commit组合不能解释ib_logfile1＆ib_logfile2如何过时。
我在数据库文件的时间戳上迁移了服务器。 我把两个服务器上的mysql和rsync'd / var / lib / mysql从一个caching到另一个。 Web应用程序出现并在新的服务器上检出。
但是，如果我忘记monit unmonitor mysql目标服务器上的monit unmonitor mysql并重新启动mysql呢？ 也许我已经取代了运行的MySQL服务器下的数据和日志文件？ MySQL会继续blithely刷新数据到陈旧的inode？
稍后快速testing，答案是肯定的。 当数据和日志文件被replace时，MySql没有注意到它正在写入无效文件句柄，但是内存缓冲池能够满足所有查询。 鉴于我们的数据库（小）和查询量（低）的大小，缓冲池可能会继续处理我们的请求一段时间。