MySQLデータベースのバックアップとリカバリ

MySQLのバックアップとリカバリのために考慮する5つの事柄

著：Dmitri Joukovski ・ Chander Kant
  
MySQLデータベースはウェブベースのコラボレーションツールやCRMなどのアプリケーションにますます利用されています。しっかりしたバックアップの計画はリカバリを確実なものにして、システムやユーザのミスによるデータの消失があった場合にも業務に影響を与えることなくリカバリができます。

ここではMySQLデータベースのバックアップを計画する時に考慮する5つの事柄をとりあげます。

 1） どのくらいの時間でどの時点まで戻ってMySQLのリカバリをするのか？

バックアップの計画と同じようにリカバリの計画はとても重要です。以下は主要な２つのリカバリ目標です：

1. どの時点まで戻ってデータベースをリカバリする必要があるのか
   リカバリポイント目標 (RPO)はどの時点まで戻ってデータをリカバリするかを示すものです。間違ってテーブルを削除してしまったならその直前までリカバリします。状況によってはリカバリをする必要のないものを選択して除外します。
   　
2. データベースのリカバリにどのくらいの時間をかけるか
   リカバリタイム目標(RTO)はどのくらいの時間でデータベースのリカバリをするかを示すものです。リカバリ中にMySQLのアプリケーションが使用できない時間がどのくらいあっても良いかを考慮します。

MySQLデータベースを使った状況に合わせたRPO と RTOにそってバックアップの設定をしていきます。

状況によってリカバリ量は変わってきます。必要に合わせてリカバリするものを選択します：

• サーバ上のすべてのデータベース（障害復旧のため）
• 選択したデータベース
• 選択したテーブル
• 選択した処理

リカバリを確実にするために定期的にリカバリ手順をテストしておいてください。本番でのリカバリは切迫した状況になります。バックアップの計画はすべてリカバリをする時のためにあることを覚えておいてください。

2) バックアップ処理がアプリケーションにどんな影響を与えるのか？

バックアップ処理中はアプリケーションがオフラインもしくは機能や動作が低下しています。

　
• オフラインでバックアップ中のデータベースは停止される
• mysqldumpでバックアップ中はデータベースの更新ができない
• レプリケーションやスナップショットでのバックアップはデータベースに与える影響が少ない

バックアップにかかる時間はデータベースのサイズと処理速度で変わります。バックアップにかかる時間とMySQL のアプリケーションを使用しない時間帯を考慮してバックアップをする時間帯を決めます。データベースが大量に更新されるとバックアップにかかる時間が長くなる可能性もあります。バックアップソフトがデータベースの処理状況を把握しているならデータベースがロードされている時には自動でバックアップの実行を遅らせることができます。

MySQLデータベースの外にアプリケーションのファイルが格納されているかもしれません（アプリケーションの構成ファイルなど）。MySQLを使ったアプリケーションを確実にリカバリするためにこれらのファイルをバックアップとリカバリの処理に加えてください。

3) バックアップの構成はどうなっているのか？
  （何を・どこに・いつ・どのようにバックアップするか）

バックアップの設定はサーバとデータベースの構成によって変わってきます。以下を考慮して設定します：

• MySQLサーバの数
• MySQLデータベースのサイズ
• 使用するストレージエンジン(InnoDB、MyISAM、 NDB-MySQLクラスタ)。MySQLストレージエンジンを追加導入する可能性があるのでバックアップの実装に柔軟性をもたせる
• データベースでの処理があまりない特定の時間帯はあるか
• MySQLのレプリケーション機能の使用
• MySQLのバージョン
• MySQLのストアドプロシージャの使用

同時にバックアップをする必要のあるデータベースやテーブルをすべてバックアップしてアプリケーションレベルでのデータの整合性を保ちます。

バックアップイメージはできるだけオリジナルのデータとは離れた場所に保管してください。オリジナルのデータと同じRAIDにバックアップを取るとRAIDが障害にあったときはリカバリができません。

データベースをリカバリする場所を決めます。ユーザの単純な間違いであれば元の場所にリカバリします。ハードウェアの故障や障害であれば異なるホストにリカバリします。リカバリ処理を定期的にテストするために別のサーバを持つのが理想的です。

データベースのサイズとリカバリする場所を考慮してバックアップの保存場所を決めます。保存場所の容量が足りなければバックアップイメージを圧縮します。（圧縮をするとバックアップとリカバリの処理に計算資源が使われます）

MySQLのレプリケーションを取っているならばバックアップに利用することができます。マスターサーバに影響をあたえずにスレーブサーバでバックアップを実行することができます。

4)どのようにバックアップを処理してバックアップデータを管理するのか？

バックアップはなるべく自動で規則正しく取り、手動でのバックアップは避けるべきです。バックアップカタログは更新されたすべてのバックアップイメージのコピーを自動で保存します。

バックアップ前後の処理を設定することも重要です。バックアップ前にはストレージに十分な容量があるかを確認し、バックアップ後には不要になったバイナリログを削除します。バックアップ前後の処理をバックアップの一連の処理に統合します。

MySQLデータベースのセキュリティもバックアップの設定をする時に考慮されるべき重要なことです。バックアップをするデータベースを暗号化する必要があるか考慮します。暗号化にも圧縮のようにバックアップとリカバリの処理に計算資源が使われます。遠隔にデータをバックアップするときは確実に保護された経路を使います。

MySQLのデータベースをリカバリする担当者を決めます。担当者には技術上もしくは業務上の適任者を選択します。リカバリの前には担当者への適切な指導が必要です。

5) MySQLのバックアップにはどのような通知、レポート、コンプライアンスの要求があるのか？

MySQLのバックアップの成功や失敗などの結果をEメールやRSSフィードで通知します。

バックアップの進行状況がレポートで通知されます。MySQLのデータベースを様々な目的で使用する複雑なバックアップ環境では特に役立ちます。

保持期限を設定して期限の切れたMySQLの データを自動で削除します。コンプライアンスや業務上の必要性から保持期限の異なるデータがあることも考慮して設定をします。