在最近对 RS 云服务器进行“紧急迁移”后，我们服务器快照映像上的 mysql 数据库被证明比备份日期晚了几天。然而，通过受影响的 Web 应用上传的文件已写入文件系统。写入数据库的相关元数据丢失，但文件本身已备份。
一旦我能够在 mysql 服务器启动之前手动访问 mysql 数据文件（服务器配置为在启动时启动 mysql），我就能看到 ib_logfile1、ib_logfile0 和 ibdata1 的更新时间已经有几天了。
正如这张海报一样，服务器崩溃后mysql数据丢失，就好像一些缓存控制器告诉 OS / mysql 服务器它已经提交了仍然在缓存中的数据，并且丢失了而不是被刷新了。
我不太明白为什么上传的文件会被写入，而数据库数据却不会。我原以为任何缓存都会在整个系统范围内刷新，而不是逐个进程刷新。
对于此事可能如何发生，您有什么建议吗？
更新二：
请参阅下面的回答，其中解释了发生了什么。
更新：
根据要求配置详细信息。
RackSpace 云服务器详细信息： 操作系统：Ubuntu 10.04 LTS（Lucid） 内存：1024 MB 磁盘空间：40 GB 数据中心：ORD1 服务级别：非托管
root@restore-testing:~# dpkg -s mysql-server ... 建筑：全部 来源：mysql-dfsg-5.1 版本：5.1.61-0ubuntu0.10.04.1 ...
root@restore-testing:~# cat /etc/fstab proc /proc proc 默认值 0 0 /dev/xvda1 / ext3 默认值，错误=remount-ro，noatime 0 1 /dev/xvdc1 无 交换 sw 0 0
答案1
我可以看到这种情况的发生取决于 Innodb 刷新数据的方法。
请查看innodb_flush_methodMySQL 安装所使用的。根据设置的值（O_DSYNC 或 O_DIRECT），InnoDB 可以双倍缓冲到 OS 和 InnoDB 缓冲池，或者只缓冲到 InnoDB 缓冲池。如果将变量设置为仅缓存到缓冲池，如果 OS 恢复在此过程中破坏了缓冲池，我很快就会看到数据消失。我在 DBA StackExchange 上写了一篇关于此问题的文章。
这是另一个关于在云中使用 MySQL 与在裸机上使用 MySQL 的链接（点击这里)。它列举了将 MySQL 迁移到云环境可能遇到的三个问题/挑战：
- 虚拟 IP
- 内存配置
- 慢速磁盘
即使自那篇文章发表以来这些限制已被克服，重新考虑将关键任务数据存放在何处仍是明智之举。考虑到您的数据刚刚发生的事情，这一点尤其正确。
顺便提一句StackOverflow 上有一篇关于云中 MySQL 的优缺点的精彩文章。
从另一个方面进一步说明这一点，云环境提供了从东海岸到西海岸的 mysql 实例的地理复制。当我亲自对 XEROUND 数据库服务进行 30 天评估时（我获得了两个公共 IP），我发现 IP 之间存在非常严重的间歇性（大约 5-6 分钟）。你能想象在这个窗口期内因为任何一端的崩溃而丢失数据吗？您的数据丢失是由于紧急手动干预造成的。
推荐
依我之见，我会将您的 MySQL 数据库切换到裸机并使用 DRBD 或 MySQL 复制来实现数据冗余。您可以维护 Web 和应用服务器的所有云服务。
答案2
尽管某些设置innodb_flush_method与某些硬件结合可能会因硬件故障而导致数据丢失，但没有哪种组合可以innodb_flush_method解释innodb_flush_log_at_trx_commitib_logfile1 和 ib_logfile2 如何会过时数天。
我在数据库文件的时间戳附近迁移了服务器。我在两台服务器上慢慢关闭了 mysql，并将 /var/lib/mysql 从一台服务器 rsync 到另一台服务器。webapps 在新服务器上启动并检查。
但是，如果我忘记monit unmonitor mysql在目标服务器上重新启动 mysql，该怎么办？也许我替换了正在运行的 mysql 服务器下的数据和日志文件？mysql 会继续将数据快速刷新到过时的 inode 中吗？
稍后进行快速测试，答案是肯定的。当其数据和日志文件已被替换时，MySql 不会注意到它正在写入无效的文件句柄，但内存缓冲池能够满足所有查询。考虑到我们的数据库大小（小）和查询量（低），缓冲池可能会继续处理我们的请求一段时间。