web-dev-qa-db-ja.com

MySqlデータ損失-事後分析-RackSpaceCloud Server

RSクラウドサーバーの最近の「緊急移行」の後、サーバースナップショットイメージ上のmysqlデータベースは、バックアップ日から数日古いことが判明しました。それでも、影響を受けるWebアプリを介してアップロードされたファイルは、ファイルシステムに書き込まれていました。データベースに書き込まれた関連メタデータは失われましたが、ファイル自体はバックアップされました。

Mysqlサーバーが起動する前に（サーバーが起動時にmysqlを起動するように構成されている）mysqlデータファイルに手動でアクセスできるようになると、ib_logfile1、ib_logfile0、およびibdata1の更新時刻が数日前であることがわかりました。

このポスターと同様に、 サーバークラッシュ後のmysqlデータの損失 、キャッシュコントローラーがOS/mysqlサーバーに、まだキャッシュにあるデータをコミットしたことを通知し、フラッシュされる代わりに失われたようです。 。

アップロードされたファイルがどのように書き込まれたかについて頭を悩ませることはできませんが、データベースデータはそうではありませんでした。私は、キャッシュがプロセスごとではなく、システム全体にフラッシュされると思っていたでしょう。

これがどのように起こったのかについての提案はありますか？

更新2：

何が起こったのかを説明する以下の私の答えを参照してください。

更新：

要求に応じて、構成の詳細。

 RackSpaceクラウドサーバーの詳細：
 OS：Ubuntu 10.04 LTS（Lucid）
 RAM：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 defaults 0 0 
/dev/xvda1/ext3 defaults、errors = remount-ro、noatime 0 1 
/dev/xvdc1 none swap sw 0 0
mysqlcloud-computinginnodbrackspaceserver-crashes
4
marfarma

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は、古いiノードにデータを簡単にフラッシュし続けますか？

後で簡単にテストすると、答えは「はい」です。 MySqlは、データファイルとログファイルが置き換えられたときに無効なファイルハンドルに書き込んでいることに気づきませんが、メモリ内のバッファプールはすべてのクエリを満たすことができます。データベースのサイズ（小さい）とクエリボリューム（小さい）を考えると、バッファプールはしばらくの間要求を処理し続けていた可能性があります。

2
marfarma

Innodbがデータをフラッシュする方法によっては、これが発生していることがわかります。

MySQLのインストールで使用される innodb_flush_method を調べてください。設定された値（O_DSYNCまたはO_DIRECT）に応じて、InnoDBは、OSとInnoDBバッファープールへのダブルバッファー、またはInnoDBバッファープールのみのいずれかを実行できます。変数がバッファプールのみにキャッシュするように設定されている場合、OSの復元によってプロセスでバッファプールが破壊された場合、データが消えるのがすぐにわかります。 これについてDBA StackExchangeに投稿しました 。

クラウドでのMySQLの使用とベアメタルの使用に関する別のリンクを次に示します（ ここをクリック ）。 MySQLをクラウド環境に移行することに伴う3つの潜在的な問題/課題を挙げています。

  • 仮想IP
  • メモリ構成
  • 遅いディスク

その記事以降、これらの制限が克服されたとしても、ミッションクリティカルなデータがどこにあるかを再考するのが賢明です。これは、データに何が起こったかを考えると特に当てはまります。

ところで StackOverflowにはクラウドでのMySQLの長所と短所についての素晴らしい投稿があります 。

この点を別の側面からさらに進めるために、クラウド環境は、東海岸から西海岸へのmysqlインスタンスの地理的レプリケーションを提供します。 XEROUNDデータベースサービスの30日間の評価を個人的に行ったとき（2つのパブリックIPが提供されました）、IP間の非常に悪い間欠性（約5〜6分）が見られました。どちらかの端でクラッシュしたために、このウィンドウ中にデータが失われることを想像できますか？データの損失は、緊急の手動介入によるものでした。

勧告

IMHO MySQLデータベースをベアメタルに切り替え、データの冗長性のためにDRBDまたはMySQLレプリケーションを使用します。 Webサーバーおよびアプリケーションサーバー用のすべてのクラウドサービスを維持できます。

4
RolandoMySQLDBA