安全なデータベース管理の鍵は定期的にバックアップを取ることです。

InnoDB Hot Backup を使えば、InnoDB や MyISAM のテーブルなど、稼働中の MySQL データベースのバックアップを行えますが、データベースの一貫性のあるスナップショットを作成している間、業務の中断を最小限に抑えることができます。InnoDB Hot Backup が InnoDB テーブルをコピーしている際には、InnoDB テーブルと MyISAM テーブルの両方で読み取りと書き込みを継続できます。MyISAM テーブルのコピー中は、それらのテーブルの読み取りが許可されます (書き込みは不可)。さらに InnoDB Hot Backup は、圧縮バックアップファイルの作成と InnoDB テーブルのサブセットのバックアップ実行をサポートしています。MySQL のバイナリログと組み合わせれば、ポイントインタイム復旧を実行できます。InnoDB Hot Backup は、Innobase Oy から商用ライセンスが提供されています。InnoDB Hot Backup のより詳しい説明については、http://www.innodb.com/hot-backup/features/ を参照するか、http://www.innodb.com/doc/hot_backup/manual.html からドキュメントをダウンロードしてください。Innobase (http://www.innodb.com/hot-backup/order/) からトライアル、期間、および永久ライセンスを注文できます。

もし MySQL サーバーをシャットダウンすることができるなら、テーブルを管理するために InnoDB によって利用されるすべてのファイルで構成されているバイナリバックアップを作成することができます。次の手順を使用します。

レプリケーションは InnoDB テーブルと共に機能するので、ハイアベイラビリティを必要とするデータベースサイトにデータベースのコピーを保管するために、MySQL レプリケーション性能を利用することができます。

今説明したようにバイナリバックアップを作成することに追加して、mysqldump を利用してテーブルのダンプを定期的に作成する必要があります。これは、バイナリファイルは気づかない内に破損することがあるからです。ダンプされたテーブルは人間が解読可能なテキストファイル内に格納されるので、テーブルの破損を見つけることは簡単になります。また、フォーマットが単純なため、深刻なデータ破損の可能性は小さいです。mysqldump は、別のクライアントをロックアウトせずに一貫性のあるスナップショットを作るために利用できる --single-transaction オプションも持ちますBackup Policy を参照してください。

InnoDB データベースを今説明したばかりのバイナリバックアップから現在まで復旧できるようにするためには、バイナリログがオンの状態で MySQL サーバーを起動させる必要があります。バックアップの復元後にポイントインタイム復旧を実現するには、バックアップの実施後に発生した変更をバイナリログから適用します。Point-in-Time (Incremental) Recovery Using the Binary Log を参照してください。

MySQL サーバーのクラッシュから復旧するためのたった 1 つの要求事項は、再起動させることです。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 がすべての破損を検出することはできませんが、テーブルが破損したかどうかを確認するために CHECK TABLE SQL ステートメントを利用することができます。テーブル領域ファイル内のファイル領域管理の整合性を確認するために、テーブル領域モニターを利用することができます。

場合によっては、明白なデータベースページの破損は、OS がそれ自体のファイルキャッシュを破損しているために起きていて、ディスク上のデータは無傷なことがあります。まず最初にコンピュータを再起動するのが一番良いでしょう。それを行うことで、データベース破損のように見えていたエラーを排除することができます。