ファイルからのMySQLデータベースの回復履歴（InnoDB）

一般的な知恵によれば、「管理者は2つのカテゴリに分類されます。バックアップを作成するカテゴリと、すでに作成しているカテゴリです。」 私の場合、作成されていないバックアップの責任は開発者、つまり自分自身にありました。 この記事では、説明した状況と同様の状況から抜け出す方法を見つける方法について説明します。 そのような経験がなく、同様の状況に遭遇する可能性のある人々にとって役立つことを願っています。



一般的に、それはそのようなものでした...

エントリー

遠く離れた王国の、遠く離れた州で、州の行政機関の1つに、私たちの企業がサービスを提供している、サーバーがありました。 サーバーとして、私たちはそれほど強力ではないデュアルコアプロセッサ、320 GBのハードドライブを備えた通常のデスクトップコンピューターを使用しました。サーバータスク。これは、自分の立場によって特に意識していませんでした。 彼はこのようにほぼ数年間中断することなく働きました。



そして、ある晴れた日、部門長からパートナーに電話があり、MySQL Server 5.1をDBMSとして使用してこの機関のシステムを開発するタスクを任せました。 私たちはシステムを開発しました。誰もが非常に満足しており、それを実装する時が来ました。 我々は、管理者のいずれかが上記のMySQL 5.1のサーバーに設立され、金融機関の事務所に来て、彼女のベースを開始している何の問題もなく、自分のマシンにインストールされたクライアントアプリケーションは、実装プロセスを開始しました。 施設の従業員はシステムに非常に満足していましたが、作業負荷、会議、会議、市民の訴えなどにより、ゆっくりと習得しました。 ゆっくりと情報を入力したが、大いに「伸びる喜び」。 一つはすでに静かに、バックアップ/リカバリ戦略について考え始めていたが、私は管理者と開発者がおりませんので、それは、本当に何か私の仕事ではないと思われます。 しかし、管理者はまったく無関心でした。 私自身は、ここでもう少しで、誰もバックアップを作成するために開始しない場合は、私はすでに始めましょう、これまでほとんど情報という事実によってのみ慰め。 振り返ってみると、その後のイベントを予測するのがどれほど簡単かがわかりました。



しばらくすると、主要な従業員の一つが「悟り」をキャッチアップし、時間の非常に小さな期間に大量の情報は、ほとんどすべての時間で入力できる情報の、システムに入力されています。 私はすべてが唯一の彼らの論文で、以前のように、彼らはまた、ゆっくりとシステムを狙っ、まだ何が本当に自分自身を働いて、入力していないと考え、それについて考えと思いました。 従業員はすぐに情報を入力し、1か月間休暇を取りました。

主な戦い

そして、別の「美しい」日が来て、サーバーがクラッシュしました。 さらに、ソフトウェアではなく、ハードウェア-ハードドライブが「飛びました」。 さらに、ハードドライブは、データ復旧に従事している会社に入れ、情報の多くは、彼に復元されました。 ただし、管理者はサーバー自体を復元するときに、ディスクDからすべての情報のみを復元し、MySQLについて誰も思い出しませんでした（「幸運なことに」ディスクCに保存されました）。 すべてのこの時間、私はこれらのイベントについては、他のプロジェクトと平和に従事していたと知って知りませんでした。



もう少し時間が経ち、前述の機関の従業員は休暇を離れます。 私に電話して、彼はログインできないと言います。 私、いつものように、システムを提供し、同時に何のメッセージ尋ね、すべてのことは、すぐに何かがデータベースへの接続に問題があることを認識しています。 さらに、サーバークラッシュに関するこの話を彼女から既に知っているので、彼らは「何かを変えた」ので、私の理解はさらに深まります。今では、データベースがサーバー上にまったくないことに気付きました。 さらに、判明したように、データベースもDBMSもありません。 管理者に、何があったのか、何が復元されたのか、何が復元されなかったのかを尋ねます。私は、根拠がないという残念な結論に至りました。大きな問題は、復元できるかどうかです。 私は殺害復元したデータをハードドライブのコピーを取り、それを掘り下げるために始めます。



まず、MySQLがデフォルトでインストールされるProgram Filesフォルダーを探しています。 私はそれが私たちのベースのほとんどの名前のフォルダ、見つけることが、ファイルフォルダのMySQLデータベースを見つけることができません。 わずかな楽観論が私の絶望の雲をわずかに分散させましたが、...理論的にはテーブルエントリが必要な* .MYDファイルを見ると、入力された情報量に対してサイズが小さすぎることがわかります。 バイナリログも含まれておらず、このオプションは自動的に消えました。 私はこの問題について考え始め、私が行ったテストサーバーの開発ベースを見ることができることを覚えています。 そこで、ほとんどのテーブル（および最も重要なテーブル）がInnoDBエンジンで動作することを確認しました。つまり、それらのレコードはibdata *ファイル（私の場合はibdata1のみ）に個別に格納されます。 1つ上のレベルに移動すると、この大切なファイルが表示されます。 また、InnoDBエンジンの2つのログib_logfile0およびib_logfile1も近くにあります 。 「詐欺師」の間でテキストエディターで表示するためにログの1つを開いた後、情報自体の断片も確認し、少なくとも理論的にはデータベースを復元できることに気付きました。



車を選択する必要がありました。そこでは、基地自体を復元しようと試みました。 なぜなら 開発中に、テストサーバーを使用します。ファイルシステムレベルでは、誰も勝手に私に与えることはできません。WindowsXPを実行している開発マシンにMySQL Server 5.1とMySQL GUIツールを直接インストールすることにします。 したがって、すべてのコストがかかり、DBMSが実行されており、タスクへのアプローチ方法を考えたので、まずテストサーバーからデータベース作成スクリプトをエクスポートし、それを後で自分のコンピューターで実行することにします。 これで、完全に同一の構造とすべてのストアドプロシージャを持つ空のデータベースができました。 MySQLサービスを停止し、クラッシュしたサーバーのデータベース名のフォルダーからすべてのコンテンツを、新しくインストールされたMySQLローカルの同じフォルダーにコピーします（データベース名のフォルダーは、MySQLのインストール中に指定されたデータファイルを保存するパスに沿ったデータフォルダーにあります） 。 あなたはローカルのMySQLサーバをセットアップするとき、私は、データがさらにibdata1と復元されたファイルをオフに投げる別のフォルダをファイルのInnoDBに指定することを決めました。 その後、InnoDBログファイル（ ib_logfile0およびib_logfile1 ）をデータフォルダーに直接転送します。これらはデフォルトであるはずです。



MySQLを起動する別の試みは再び失敗しました。 DBMSの管理における実際の戦闘経験はありません（コースで得た経験を除き、他のDBMSでも同様です）。私は実験を行うことにしましたが、今ではまったく必要ないことを理解しています。 InnoDBログファイルを削除し、MySQLサービスを開始して、同じ名前でサイズが20 MBのInnoDBログファイルが作成されることを確認します。



私は、クラッシュしたサーバーのログから、「自分」ファイルのサイズを見て、それが大幅に異なり、81Mbであることがわかります。 さて...サーバーを停止し、MySQL管理者を介して[スタートアップ変数]設定の[InnoDB]タブに移動します。 私は81メガバイトのログ・ファイルのサイズを設定し、「」ログファイルをバックスローします。 MySQLは起動しましたが、興味のあるテーブルにデータが表示されませんでした（MyISAMエンジンで実行されているテーブルに既に復元されていますが）。 ネットワークを少し検索した後、MySQLをリカバリモードで起動する必要があることを読みました。そのため、開始変数InnoDB_force_recoveryを6に設定する必要があります。 .iniまたはmy.cnf [MySQLのバージョンと選択されたOSに応じて]を手動で）、および何かを完了しなかったか、何かを見落としましたが、望ましい結果が表示されませんでした。 MySQLは通常どおり起動しましたが、リカバリについては何も言いませんでした。 「その後、何、」 -私は考えた- 「コンソールを試してみてください、そして再び明確オプションinnodb_force_recoveryを処方します」。



Windowsコマンドラインを起動して、次のように入力します。



> mysqld --console --innodb_force_recovery=6







応答として受け取るもの：



110727 10:31:52 [Note] Plugin 'FEDERATED' is disabled.

110727 10:31:52 InnoDB: Initializing buffer pool, size = 40.0M

110727 10:31:52 InnoDB: Completed initialization of buffer pool

110727 10:31:52 InnoDB: Operating system error number 32 in a file operation.

InnoDB: The error means that another program is using InnoDB's files.

InnoDB: This might be a backup or antivirus software or another instance

InnoDB: of MySQL. Please close it to get rid of this error.







アンチウイルスの罪はあまり意味がなかったので、CTRL + breakを使用してコマンドを停止し、タスクマネージャーを有効にしてコマンドを再度繰り返すことにしました。 実行コマンドを実行する前に、プロセスのリストを見て、MySQLサービスのインスタンスが実行されていないことを確認しました。 そして再び彼は命令を繰り返した。 同じメッセージを見たとき、タスクマネージャーを調べて、何らかの理由で2つのプロセスがmysqldという名前で起動されていることを確認しました。1つはシステムとして、もう1つはユーザーとして起動されました。 システムプロセスを殺す、私は「悪循環を断ち切る」、および実行は続けました：



> mysqld --console --innodb_force_recovery=6



110727 10:31:52 [Note] Plugin 'FEDERATED' is disabled.

110727 10:31:52 InnoDB: Initializing buffer pool, size = 40.0M

110727 10:31:52 InnoDB: Completed initialization of buffer pool

110727 10:31:52 InnoDB: Operating system error number 32 in a file operation.

InnoDB: The error means that another program is using InnoDB's files.

InnoDB: This might be a backup or antivirus software or another instance

InnoDB: of MySQL. Please close it to get rid of this error.

110727 10:32:02 InnoDB: Operating system error number 32 in a file operation.

InnoDB: The error means that another program is using InnoDB's files.

InnoDB: This might be a backup or antivirus software or another instance

InnoDB: of MySQL. Please close it to get rid of this error.

110727 10:32:12 InnoDB: Operating system error number 32 in a file operation.

InnoDB: The error means that another program is using InnoDB's files.

InnoDB: This might be a backup or antivirus software or another instance

InnoDB: of MySQL. Please close it to get rid of this error.

InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on

InnoDB: Skipping log redo

110727 10:32:22 InnoDB: Started; log sequence number 0 0

InnoDB: !!! InnoDB_force_recovery is set to 6 !!!

110727 10:32:22 [Note] Event Scheduler: Loaded 0 events

110727 10:32:22 [Note] mysqld: ready for connections.

Version: '5.1.58-community' socket: '' port: 3306 MySQL Community Server (GPL)







これまでのところ私は一度に2つのプロセスを実行するために、なぜそれは、何だった考え出したていません。 喜びが私を包み込むので含め、およびMySQLのヒキガエルを介してデータベースに接続し、私はデータ復旧することを見ました！ この喜びは、すべての質問を背景に押し上げました。

勝利の意識とコントロールショット

「レジから逸脱することなく」、データベースをダンプして作業用サーバーに復元します。この「おとぎ話」の主人公は、ハードドライブを変更してシステムを再インストールしました。



> mysqldump --routines -u "user" -p db_name > [path\]db_name.sql







パスワードを入力すると、パラメーターで指定されたフォルダー内のdb_name.sqlファイル内のすべてのストアドプロシージャと同様に、すべてのデータベーステーブルを作成および設定するスクリプトが取得されます。 情報が保存されました！



次に、実稼働サーバーにMySQL自体をインストールし、構成し、空のデータベースを作成して、ダンプをダンプします。



> mysql -u "user" –p db_name < [path\]db_name.sql







クライアントアプリケーションの設定では、何も変更する必要はありませんでした。 IPアドレスおよびネットワーク名は同じまま、それは秋の前でした。 私たちはシステムに入り、チェックしました-ああ、奇跡です！ -すべての情報が整っています。 ここやおとぎ話が終了...しかしにこだわる「話の教訓。」

結論と結論

私自身にとって、いくつかの重要なこと、つまり次のことをもう一度理解しました。

1. バックアップ/リカバリ戦略は、開発段階ですでに決定されている必要があります。
2. バックアップの問題で/復元は、あなたがそれを自分で行うことができれば、管理者の希望する必要はありません。 そしてそれ以上に、あなたはあなたのために（通常の手段によって、プリミティブレベルで作ることは可能である）、このプロセスを自動化するために多くの努力をしていない場合。
3. ITを扱う場合、企業の組織と特定の各プロジェクトにおける各従業員の責任の明確な規制が非常に重要です。 そしてIT-企業内分業の現代の基準はどこからともなく、非常に、非常に関連してアップしています。
4. それでも、基地が飛んでバックアップがない場合-これはすぐに絶望してあきらめる理由ではありません。

最初は、この場合に何をどのように行うかについて簡単な指示を与えることを考えましたが、まず、原則として、そのような指示はネットワーク上で利用可能です。 そして、第二に、彼は「落とし穴」とエラーで、すべてを現状のまま詳細に説明することに決めました。 また、このような形式のプレゼンテーションの方がやや興味深いかもしれないと考えました。 実際、私は少数派がそのような落とし穴（より正確には小さな小石）に遭遇することを確信していますが、それでも、それらが記述されることは重要だと思います。



そして最後に、InnoDBデータとログファイルのみがInnoDBテーブルを持つ作業ベースから残されている場合の同様の状況で何をすべきかの簡単なレシピ：

1. テーブルのデータファイルと説明ファイルをデータフォルダーに置き換えます（ * .frm 、 * .MYIおよび* .MYDファイル、フォルダー内のすべてがデータベース名になります。つまり、フォルダー全体がコピーされます）。
2. InnoDBデータファイル（デフォルトでは、ほとんどの場合、これはデータベース名のバイナリログとフォルダーが保存されるデータフォルダーです。私の場合、InnoDBデータ用に別のフォルダーを作成しました）で、すべてのibdata *ファイルを削除します。 ここでは、おそらく、ファイルのサイズが指定した設定が一致しなければならないことに留意すべきです。 サイズが異なる場合は、これを行うことができます：サーバーによって手動で作成されたファイルを削除し、既存のサイズと同じサイズの新しい（または、それに応じて新しい）を作成し、サーバーを起動して停止し、それによって作成されたファイルの代わりに独自のファイルを置き換えます。 MySQL管理者は、この操作を容易にすることができます-設定を手動で操作する必要がないように。 または、すべてのファイル（またはファイル（ある場合））を変更し、設定ファイルmy.ini / my.cfgのサイズを変更するだけで、さらに簡単にできます-これは理論的には動作するはずです。
3. InnoDBログを既存の場所にドロップします（既に存在する場合は置き換えます）（デフォルトでは、これはデータと説明を含むファイルが保存されている同じデータフォルダーですが、これも設定で変更できます）。
4. （手動であれば - バイト単位で、MySQLの管理者ならば - MB単位）のInnoDBログのサイズは、私たちのログのサイズに設定します。
5. MySQLデーモンを起動する
   
   > mysqld --console
   
   ログを注意深く見て、サービスを開始し、回復を実行する必要があります。
6. リカバリが発生しない場合は、構成またはパラメーターでinnodb_force_recovery = 1を設定し、実行してみてください。 あなたは合格しないならば、我々はinnodb_force_recovery = 2を入れて実行してみてください。 等 6まで。
7. 最後に、我々は我々のデータかどうかを見て、その場でスポットがあれば - そして、本番サーバー上で行われ、データベースのダンプを、行います。

Linuxまたは別のUnixライクシステムでの同様の操作は、次のようになります。 さらに、私が理解しているように、MySQLのデータファイルとログ（およびバイナリログとInnoDBログ）はすべてのシステムで共通であり、Windowsに落ちたものはLinux、OS X、 MySQL自体が動作する他のシステム。

参照資料

InnoDBエンジンのドキュメント

さらに

PhantomTLTはコメントを求めます （彼のアドバイスに基づいて、上記のメモを少し調整しました）：



datadir全体を保存した場合、同一の構造を持つ空のデータベースを作成する必要はありません。 すべてのファイルを置き換えて、InnoDBログのサイズを調整するだけです。



次に、MySQLを起動して、ログを注意深く調べます。 リカバリを開始して実行する必要があります。



リカバリが失敗した場合、config set innodb_force_recovery = 1（http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html）で開始してみてください。 私たちは開始しない限り、我々はinnodb_force_recovery = 2を入れて起動してみてください。 等 6まで。



あなたはinnodb_force_recovery = 6ですぐに持ち上げる場合は、一貫性のない状態でのデータベースのリスクを実行します。 つまり データの整合性（一貫性）が損なわれる可能性があります。



innodb_force_recovery = 6に達し、これが役に立たなかった場合、それは非常に悲しいです-半手動モードで復元する必要があります。