14.16 InnoDB のバックアップとリカバリ

[+/-]

14.16.1 InnoDB のリカバリプロセス

安全なデータベース管理の鍵は、定期的なバックアップを作成することです。データボリューム、MySQL サーバーの数、およびデータベースワークロードに応じて、次の手法を単独で、または組み合わせて使用できます。すなわち、MySQL Enterprise Backup を使用したホットバックアップ、MySQL サーバーのシャットダウン中にファイルをコピーすることによるコールドバックアップ、迅速な操作 (特にリストア) のための物理バックアップ、小さなデータボリュームのため、またはスキーマオブジェクトの構造を記録するための mysqldump を使用した論理バックアップです。

ホットバックアップ

MySQL Enterprise Backup コンポーネントの一部である mysqlbackup コマンドを使用すると、実行中の MySQL インスタンス (InnoDB および MyISAM テーブルを含む) を、データベースの整合性のあるスナップショットを生成しながら、操作の中断を最小限に抑えてバックアップできます。mysqlbackup が InnoDB テーブルをコピーしている間、InnoDB テーブルと MyISAM テーブルの両方に対する読み取りと書き込みは続行できます。MyISAM テーブルのコピー中は、これらのテーブルに対する (書き込みではなく) 読み取りが許可されます。MySQL Enterprise Backup はまた、圧縮バックアップファイルを作成したり、テーブルやデータベースのサブセットをバックアップしたりすることもできます。MySQL のバイナリログと組み合わせると、ユーザーはポイントインタイムリカバリを実行できます。MySQL Enterprise Backup は、MySQL Enterprise サブスクリプションの一部です。詳細は、セクション25.2「MySQL Enterprise Backup」を参照してください。

コールドバックアップ

MySQL サーバーをシャットダウンできる場合は、InnoDB がそのテーブルを管理するために使用するすべてのファイルで構成されるバイナリバックアップを作成できます。次の手順を使用します。

1. MySQL サーバーの低速シャットダウンを実行し、そのサーバーがエラーなく停止したことを確認します。

2. すべての InnoDB データファイル (ibdata ファイルおよび .ibd ファイル) を安全な場所にコピーします。

3. InnoDB テーブルのすべての .frm ファイルを安全な場所にコピーします。

4. すべての InnoDB ログファイル (ib_logfile ファイル) を安全な場所にコピーします。

5. 1 つまたは複数の my.cnf 構成ファイルを安全な場所にコピーします。

代替バックアップの種類

今説明したバイナリバックアップの作成に加えて、mysqldump を使用してテーブルのダンプを定期的に作成します。バイナリファイルは、気付かないうちに破損することがあります。ダンプされたテーブルは人間が読むことのできるテキストファイルに格納されるため、テーブルの破損を見つけることが容易になります。また、形式が単純であるため、重大なデータ破損につながる可能性も少なくなります。mysqldump には、ほかのクライアントをロックすることなく、整合性のあるスナップショットを作成するための --single-transaction オプションも用意されています。セクション7.3.1「バックアップポリシーの確立」を参照してください。

レプリケーションは InnoDB テーブルと連携して動作するため、MySQL のレプリケーション機能を使用して、データベースのコピーを高可用性が必要なデータベースサイトに保持できます。

リカバリの実行

InnoDB データベースをバイナリバックアップが作成された時点から現時点にリカバリするには、バックアップを作成する前であっても、バイナリロギングをオンにして MySQL サーバーを実行する必要があります。バックアップをリストアしたあとにポイントインタイムリカバリを実現するには、バックアップが作成されたあとに発生した変更をバイナリログから適用できます。セクション7.5「バイナリログを使用したポイントインタイム (増分) リカバリ」を参照してください。

MySQL サーバーのクラッシュからリカバリするための唯一の要件は、そのサーバーの再起動です。InnoDB はログを自動的にチェックし、データベースの現時点へのロールフォワードを実行します。InnoDB は、クラッシュの時点で存在していたコミットされていないトランザクションを自動的にロールバックします。リカバリ中に、mysqld は次のような出力を表示します。

InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 13674004
InnoDB: Doing recovery: scanned up to log sequence number 0 13739520
InnoDB: Doing recovery: scanned up to log sequence number 0 13805056
InnoDB: Doing recovery: scanned up to log sequence number 0 13870592
InnoDB: Doing recovery: scanned up to log sequence number 0 13936128
...
InnoDB: Doing recovery: scanned up to log sequence number 0 20555264
InnoDB: Doing recovery: scanned up to log sequence number 0 20620800
InnoDB: Doing recovery: scanned up to log sequence number 0 20664692
InnoDB: 1 uncommitted transaction(s) which must be rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx no 16745
InnoDB: Rolling back of trx no 16745 completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections

データベースが破損するか、またはディスク障害が発生した場合は、バックアップを使用してリカバリを実行する必要があります。破損の場合は、まず、破損していないバックアップを見つけます。ベースバックアップをリストアしたあと、mysqlbinlog および mysql を使用してバイナリログファイルからポイントインタイムリカバリを実行することにより、バックアップが作成されたあとに発生した変更をリストアします。

データベースの破損の程度によっては、1 つまたは複数の破損したテーブルをダンプして削除し、再作成するだけで十分である場合があります。テーブルが破損しているかどうかは、CHECK TABLE SQL ステートメントを使用してチェックできます。ただし、当然ながら、CHECK TABLE が可能性のあるすべての種類の破損を検出することはできません。テーブルスペースモニターを使用すると、テーブルスペースファイル内部のファイル領域管理の整合性をチェックできます。

場合によっては、見た目はデータベースページの破損だが、実際にはオペレーティングシステムによる独自のファイルキャッシュの破損であり、ディスク上のデータは正常であることがあります。まず、コンピュータを再起動してみることが最善です。それにより、データベースページの破損に見えたエラーが解消される可能性があります。InnoDB の一貫性の問題のために MySQL を引き続き起動できない場合は、セクション14.19.2「InnoDB のリカバリの強制的な実行」を参照して、データをダンプできる診断モードでインスタンスを起動する手順を調べてください。