私たちのサイトで断続的なデータベースエラーが発生していたため、ウェブホストに状況を確認するよう依頼しました。調査の結果、データベースには問題がほとんどないことがわかり、修復を試みました。最後に私は彼らから次のメッセージを得ました-
私はInnoDBデータベースのすべての修復を試みましたが、まだInnoDBログシーケンス番号が将来的に取得されています。この時点で、ibdataとiblogfileをもう一度一致させるために、サーバーにあるバックアップからMySQLデータベース(データベースを含む)を復元する必要があります。プロセスは長くはかからないはずですが、このような復元に関連するいくつかのダウンタイムがあります。これがMySQLディレクトリを復元するのに最適な時間でない場合、これを別の時間にスケジュールできます。これをどのように進めたいかを教えてください。
誰かがこの問題に対処するための最良の方法を教えてくれますか?データを失いたくなくて、dBを修復したいのです。
PS:さらに情報が必要な場合はお知らせください。ウェブホストから取得します。
本当にあなたの助けに感謝します。
これまでに提案されたことは、データベースを一貫した状態にするために何ができるかです。
InnoDBについて知っておくべきことは次のとおりです。
まず最初に、ここにInnoDBアーキテクチャの絵の形式があります。
写真を見てください。 InnoDBの自己修復に本質的にどのコンポーネントがありますか(クラッシュリカバリよりも優れています)。
リカバリには3つのファイルが必要です
datadir
フォルダー全体(/var/lib/mysql
)バックアップされたのと同じ瞬間から復元する必要があります。同じ時間のdatadir
の物理コピーがない場合、将来のトランザクションのログシーケンス番号を正しく参照することはできません。
この問題でホストを信頼しない場合は、おそらく innodb_force_recovery を適切な値に設定してMySQLを開始できます。
これが MySQLドキュメントの値 です。
1 (SRV_FORCE_IGNORE_CORRUPT)
破損したページを検出した場合でも、サーバーを実行します。 SELECT * FROM tbl_nameに、破損したインデックスレコードおよびページを飛び越えさせようとします。これは、テーブルのダンプに役立ちます。
2 (SRV_FORCE_NO_BACKGROUND)
マスタースレッドとパージスレッドが実行されないようにします。パージ操作中にクラッシュが発生した場合、この回復値によりクラッシュが防止されます。
3 (SRV_FORCE_NO_TRX_UNDO)
クラッシュリカバリの後にトランザクションロールバックを実行しません。
4 (SRV_FORCE_NO_IBUF_MERGE)
挿入バッファーのマージ操作を防止します。クラッシュの原因となる場合は、実行しません。テーブル統計を計算しません。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
データベースの起動時に元に戻すログを見ない:InnoDBは不完全なトランザクションでさえコミットされたものとして扱います。
6 (SRV_FORCE_NO_LOG_REDO)
リカバリに関連してREDOログのロールフォワードを行いません。
必要な値を選択したら、その値でMySQLを起動します。次に、すべてのデータのmysqldumpを実行します。 mysqldumpをどこかに保管します。
これで、回復可能な量に基づいて、データのスナップショットが6つあります。次に、各MySQLDumpをMySQLの個別のインスタンスにロードする必要があります。次に、データを熟読し、十分なデータが回復されたかどうかを判断する必要があります。 Perconaには、Data Recovery Toolkit があります。
私の答えは単にこれに対する貧しい人のアプローチです。
これが役に立てば幸いです!!!