MySql 數據失去 - 事後分析 - RackSpace Cloud Server
在最近對 RS 雲伺服器進行“緊急遷移”後，我們伺服器快照映像上的 mysql 數據庫被證明與備份日期相比已經過時了幾天。然而，通過受影響的 webapp 上傳的文件已被寫入文件系統。寫入數據庫的相關元數據已失去，但文件本身已備份。
一旦我能夠在 mysql 伺服器啟動之前手動訪問 mysql 數據文件（伺服器配置為在啟動時啟動 mysql），我就可以看到 ib_logfile1、ib_logfile0 和 ibdata1 的更新時間是幾天前的。
與這張海報一樣，伺服器崩潰後mysql數據失去，就好像某個記憶體控制器告訴作業系統/mysql伺服器它已經送出了仍在記憶體中的數據，並且失去而不是刷新。
我無法完全理解上傳文件是如何寫入的，但數據庫數據卻沒有。我原以為任何記憶體都會在系統範圍內刷新，而不是逐個程序。
關於這可能是如何發生的任何建議？
更新二：
請參閱下面的答案，該答案解釋了發生的事情。
更新：
根據要求配置詳細資訊。
RackSpace 雲伺服器詳細資訊： 作業系統：Ubuntu 10.04 LTS（清醒） 記憶體：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 預設值，errors=remount-ro，noatime 0 1 /dev/xvdc1 無交換 sw 0 0
雖然
innodb_flush_method與某些硬體結合的某些設置可能會導致硬體故障導致數據失去，但沒有任何組合可以解釋 ib_logfile1 和 ib_logfile2 是如何過時的innodb_flush_method。innodb_flush_log_at_trx_commit我在大約數據庫文件的時間戳遷移伺服器。我在兩台伺服器上都緩慢地關閉了 mysql，並將 /var/lib/mysql 從一台伺服器同步到另一台伺服器。網路應用程序出現並在新伺服器上簽出。
但是，如果我忘記
monit unmonitor mysql在目標伺服器上並且它重新啟動了 mysql 怎麼辦？也許我已經替換了正在執行的 mysql 伺服器下的數據和日誌文件？mysql 會繼續愉快地將數據刷新到陳舊的 inode 嗎？稍後進行快速測試，答案是肯定的。當 MySql 的數據和日誌文件已被替換但記憶體中的緩衝池能夠滿足所有查詢時，它不會注意到它正在寫入無效的文件句柄。考慮到我們數據庫的大小（小）和查詢量（低），緩衝池可能會繼續處理我們的請求一段時間。
我可以根據 Innodb 刷新數據的方法看到這種情況。
請查看MySQL 安裝使用的innodb_flush_method 。根據設置的值（O_DSYNC 或 O_DIRECT），InnoDB 可以雙緩衝到 OS 和 InnoDB 緩衝池，也可以只是 InnoDB 緩衝池。如果變數設置為僅記憶體到緩衝池，如果作業系統恢復在此過程中破壞了緩衝池，我可以很快看到數據消失。我在 DBA StackExchange 上寫了一篇關於此的文章。
這是另一個關於在雲中使用 MySQL 與裸機的連結（點擊此處）。它列出了將 MySQL 遷移到雲環境中的三個潛在問題/挑戰：
- 虛擬 IP
- 記憶體配置
- 慢盤
即使自那篇文章以來已經克服了這些限制，重新考慮關鍵任務數據的儲存位置也是謹慎的做法。考慮到您的數據剛剛發生的情況，這一點尤其正確。
BTW StackOverflow 有一篇關於雲中 MySQL 的優缺點的好文章。
為了進一步從另一個方面進一步說明這一點，雲環境提供了 mysql 實例從東海岸到西海岸的地理複製。當我親自對 XEROUND 數據庫服務進行為期 30 天的評估時（為我提供了兩個公共 IP），我發現 IP 之間的間歇性非常糟糕（大約 5-6 分鐘）。您能想像在此視窗期間由於任一端的崩潰而失去數據嗎？您的數據失去是由於緊急人工干預造成的。
推薦
恕我直言，我會將您的 MySQL 數據庫切換到裸機，並使用 DRBD 或 MySQL Replication 來實現數據冗餘。您可以維護 Web 和應用伺服器的所有云服務。