![MySql 数据丢失 - 事后分析 - RackSpace 云服务器](https://linux22.com/image/585844/MySql%20%E6%95%B0%E6%8D%AE%E4%B8%A2%E5%A4%B1%20-%20%E4%BA%8B%E5%90%8E%E5%88%86%E6%9E%90%20-%20RackSpace%20%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8.png)
在最近对 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_commit
ib_logfile1 和 ib_logfile2 如何会过时数天。
我在数据库文件的时间戳附近迁移了服务器。我在两台服务器上慢慢关闭了 mysql,并将 /var/lib/mysql 从一台服务器 rsync 到另一台服务器。webapps 在新服务器上启动并检查。
但是,如果我忘记monit unmonitor mysql
在目标服务器上重新启动 mysql,该怎么办?也许我替换了正在运行的 mysql 服务器下的数据和日志文件?mysql 会继续将数据快速刷新到过时的 inode 中吗?
稍后进行快速测试,答案是肯定的。当其数据和日志文件已被替换时,MySql 不会注意到它正在写入无效的文件句柄,但内存缓冲池能够满足所有查询。考虑到我们的数据库大小(小)和查询量(低),缓冲池可能会继续处理我们的请求一段时间。