概要
|
本書はZmandaリカバリマネージャ(ZRM)の概要を説明するものです。ZRMは企業向けに設計された包括的でサポートのあるバックアップとリカバリのソリューションでMySQLのデータベースを保護します。 |
Zmandaリカバリマネージャ
MySQLのバックアップ＆リカバリのガイド
ホワイトペーパー
著： Dmitri Joukovski目次
始めに
障害復旧
コンプライアンスの遵守
ユーザの過失からの保護
アプリケーションのテストと管理
MySQLのバックアップソリューションへの要求
複数のストレージエンジンやOSに対応
サーバの拡張性に対応
アプリケーションのダウンタイムの短縮
データの整合性の維持
バックアップしたデータの保管場所
リカバリ目標の決定
簡単にできるリカバリ
スケジュール機能と自動化
バックアップのセキュリティ
Zmandaリカバリマネージャ
バックアップセット
ロジカルバックアップ
rawバックアップ
ホットバックアップ＆ウォームバックアップ
スナップショットでのバックアップ
リカバリポイント
バックアップレベル
Zmanda管理コンソール(ZMC)
簡単にできるインストール
包括的なバックアップとリカバリ
データベースエンジン
複数OSに対応
ZRMでのバックアップ方法
MySQLクラスタのバックアップ
簡単にできるバックアップの設定
圧縮と暗号化
レポート機能
データベースイベントビューア
簡単にできるリカバリ
簡単にできる管理
終わりに
詳細について
始めに
MySQLは高性能で使いやすく世界で最も利用されているオープンソースのデータベース管理システムです。MySQLの利用方法にかかわらず、アプリケーションにあまり影響を与えない安全で確実なバックアップを取る必要があります。MySQLのレプリケーション機能はMySQLのバックアップには不十分です。ハードウェアの障害で失われたデータをリストアすることは可能ですが、ユーザの過失により失われたデータをリストアすることはできません。堅牢性のあるバックアップとリカバリのソリューションはデータの可用性を高めます。MySQLアプリケーションのパフォーマンスを高めてもデータが保護されていなければ意味がありません。以下で堅牢性のあるバックアップとリカバリのソリューションを実装する必要性を説明します：障害復旧 |
MySQLサーバや記憶装置がどれだけ頑丈でも故障する可能性があり、その結果データは失われることになります。RAID装置も故障することがあり、RAIDコントローラが故障すれば複数ドライブがすべて障害にあう可能性もあります。 RAIDは地震や火事などの自然災害でのデータの消失は防げません。高品質のストレージアレイでもハッカーやウイルスによるデータの破壊には無力です。
コンプライアンスの遵守
業界によっては法律で包括的なバックアップのソリューションの実装によりデータを保持することが要求されます。アメリカとヨーロッパでは各種の規則があり(SEC-17A, Sarbanes-Oxley,HIPAAなど)企業にデータを一定期間は保持することを命じています。適切なバックアップとリカバリの方針でコンプライアンスを遵守することが求められます。
ユーザの過失からの保護
データに関連した間違いや削除はよくあることです。バックアップを取っておくことで間違いのある直前のデータをリストアすることができます。
アプリケーションのテストと管理
MySQLサーバをバックアップした後、データをテストサーバにリカバリすることで一度に2つの目的が達成できます。バックアップとリカバリの処理がテストでき、テストサーバにデータを格納することができます。
MySQLのバックアップソリューションへの要求
以下は多くのデータベース管理者がMySQLのバックアップソフトに必要だと思っていることです。
複数のストレージエンジンやOSに対応
MySQLのバックアップソリューションにはあらゆるMySQLのストレージエンジン（MyISAM、InnoDB、NDBなど）に対応し、Linux、Windows、Solaris、Mac OS X、UNIXで稼働するすべてのMySQLのバックアップをサポートできることが求められます。これはMySQLデータベース管理者がバックアップ時のことを心配せずに最適なストレージエンジンとプラットフォームを選ぶことを可能にさせます。
サーバの拡張性に対応
単体のMySQLサーバの管理からはじまり複数のサーバを管理するようになることがよくあります。各データベースのサイズが急激に増すこともあります。バックアップソリューションには拡張性が求められ、単一のデータベースに格納されたテラバイトのデータでもバックアップできるべきです。また、単一のMySQLサーバのバックアップだけでなく遠隔にある大容量の複数MySQLサーバのバックアップもできるべきです。
アプリケーションのダウンタイムの短縮
バックアップソリューションはデータベースのサイズが増加しても読み取りロック時間を増やさずにバックアップができるべきです。これはユーザやアプリケーションに与える影響を最少にします。
バックアップウィンドウとはバックアップにかかる時間だという定義がありますが正確にはバックアップ処理によりアプリケーションが使用できないか機能が低下している時間のことです。これは重要な違いです。なぜならバックアップの状況によってはアプリケーションがオフラインになる時間は数秒なのに、バックアップをメディアに移動させるのに何時間もかかることがあるからです。スナップショット機能を組み合 わせたバックアップがその一例です。
データの整合性の維持
バックアップソリューションはデータベースの整合性を保つべきです。関連するデータベースとテーブルを同時にバックアップすることで、リストアされるデータの一貫性を保ちます。
バックアップしたデータの保管場所
バックアップしたデータをオリジナルのデータと同じディスクやサーバに保管してはディスクやサーバが障害にあったときにリカバリができなくなります。バックアップしたデータはできるだけ遠隔に保管します。リカバリ目標の決定
多くのデータベース管理者がバックアップのパフォーマンス改善に力を入れますがどんな状況でも迅速にデータのリカバリをするという重要なことは忘れがちです。
リカバリタイム目標(RTO)は障害の発生から復旧するまでの時間を示します。RTOの設定にはどれだけの時間MySQLのアプリケーションが停止していてよいかを考慮します。アプリケーションが停止していられる時間があまりないのならMySQLのレプリケーション機能の利用を考慮します。
リカバリポイント目標(RPO)はどの時点まで戻ってデータをリカバリするのかを示します。適切なRPOにより誤りのあった直前のデータのリカバリができます。ZRM でのバックアップによりどの時点のデータのリカバリでも可能です。
簡単にできるリカバリ
本番でのリカバリは緊迫した状況におかれます。簡単にできる適切なリカバリの手順はストレスを和らげます。
スケジュール機能と自動化
バックアップソリューションのスケジュール機能には柔軟性があるべきです。ZRMは設定によってバックアップの延期や中止ができるので、MySQLデータベースの負荷が大きいときはバックアップを遅らせることができます。
バックアップを自動で取れることも重要なことです。手動のバックアップでは人的なケアレスミスの可能性があります。バックアップをできるだけ人手を介さず実行できるようにスケジュールします。
自動で取られたバックアップを通知によって監視できるべきです。探しているデータがすぐに見つからなければそのバックアップは実用的ではありません。バックアップは一覧表になっていることが望ましく、何が、いつ、何処へバックアップされたかが表示されているべきです。
バックアップのセキュリティ
セキュリティのためにバックアップへのアクセスを制限する必要があります。バックアップソリューションはツールへのアクセスを制限して、権限のある人だけにリカバリの実行をさせます。
Zmandaリカバリマネージャfor MySQL
ZmandaリカバリマネージャはMySQLデータベース管理者の協力により設計され、必要とされる機能がすべてそろっています。
- インストールや運用が簡単
- MySQLのための包括的なバックアップとリカバリ
- MySQLレプリケーションの活用
- ホットバックアップによりデータベースの停止時間がない
- 過去のどの時点へもリカバリ可能
- 複数のMySQLサーバで取ったバックアップを管理
- 柔軟で自動化されたバックアップのスケジュール機能
- リアルタイムでの監視とバックアップ状況の自動通知
- バックアップとリカバリのセキュリティ
バックアップセット
バックアップセットとはひとつのサーバから同時にバックアップされるデータの集合体です。ZRMで複数のバックアップセットが管理できるので各サーバとデータベースに見合った設定でバックアップすることができます。
バックアップセットを作成する時には関連するすべてのデータベースとテーブルを同じバックアップセットに登録してアプリケーションの整合性を保ちます。
ロジカルバックアップ
ロジカルバックアップはどの時点のデータベースでもリカバリできる一連のSQL文で構成されます。通常は、圧縮されたテキスト形式のファイルです。ロジカルバックアップはどのバックアップエンジン(MyISAM、 InnoDBなど)にも対応しています。また移植性もあるので異なるプラットフォームあるいは異なるデータベースエンジンのMySQLへもリストアが可能です。しかし柔軟性のあるロジカルバックアップには短所もあります。例えばリストアする時はすべてのMySQL文が再発行されるために時間がかかります。他にもロジカルバックアップのサイズが予想しにくいことがあげられます。データ形式やデータベースの単位によってはロジカルバックアップのサイズがデータベースよりも大きくなることがあります。ロジカルバックアップはテキスト形式なので圧縮をすることで対処できます。
rawバックアップ
rawバックアップはデータファイルのバイナリコピーを取ることでデータベースをバックアップします。ロジカルバックアップに対してのロウバックアップの利点は：
- バックアップとリカバリがより高速。ロウバックアップはロジカルバックアップよりも約5倍高速でリカバリは約20倍高速
- 拡張性があるのでMySQLのデータベースのサイズが大きい時（10～20GB以上）には重要
バックアップ手法の違いによるパフォーマンスの比較はZmanda Network http://network.zmanda.com
からホワイトペーパー「Backup and recovery benchmarks for MyISAM and InnoDB engines with Zmanda Recovery Manager for MySQL」をご覧ください。ZRMによるMyISAMとInnoDBエンジンのバックアップとリカバリのパフォーマンステストがご覧いただけます。ホットバックアップ＆ウォームバックアップ
rawバックアップでもロジカルバックアップでもMySQLサーバをシャットダウンしないウォームバックアップができます。しかしテーブルはバックアップの書き出しのためにロックされます。ZRMのスケジュール機能の追加をするプラグインを使用すれば前もって設定されたバックアップの時間を遅らせることができます。例えば50以上のユーザがデータベースに同時にアクセスしている時はバックアップの実行を1時間遅らせることができます。
ホットバックアップはデータベースをシャットダウンしません。ZRMはスナップショットによるホットバックアップをします。ZRMの増分バックアップでもデータベースは停止されません。
スナップショットでのバックアップ
スナップショットを使ったバックアップはデータベースをシャットダウンしません。スナップショットはある時点のファイルシステムの論理的コピーです。論理的コピーはバックアップのソースとして使われどの時点にでもデータベースをリカバリします。スナップショットにはいろんな種類がありますが基本的な機能はどれも同じです。最も一般的なコピー・オン・ライト方式のスナップショットを見てみましょう。（Linuxのロジカル・ボリューム・マネージャなどで利用可）
LVMスナップショットはボリュームを分割したブロックの変更前にそのブロックのコピーをスナップショット領域に取ります。コピー・オン・ライト「書き換え時にコピーする」よりも「書き換え前にコピーする」がより正確な表現でしょう。
LVMのスナップショットは読み取り時にオリジナルのデータと変更されたデータを読み取ることでデータを提供します。変更されたブロックをすべて格納できるほどのスナップショット領域を用意する必要があります。変更されたブロックの数によってはデータ量が多くても割合に少ない領域に収めることができます。もしもスナップショット領域が不足のため変更されたブロックを格納しきれなければスナップショットは失敗に終わります。
正しい設定によってスナップショットの読み取りロックがほとんど無くなります。ストレージエンジンのデータの一貫性を保つためにZRMは1秒か2秒の読み取りロックをしますがこれはアプリケーションにはほとんど影響を与えません。スナップショットの作成時にだけロックがかかりデータの転送時にはロックが解除されます。一瞬のロックの間でもテーブルなどの操作を続けることができます。
ZRMは以下のスナップショットをサポートします。
- Linux LVM snapshot
- Veritas VxFS storage checkpoints
- Sun Solaris ZFS snapshots
- Network Appliance snapshots
- Microsoft Windows VSS (Volume Snapshot Service aka Volume Shadow Copy Service) snapshots
- EMC Clariion SnapView snapshots
- データベースを停止する
- ディスクへのデータの論理的一貫性のためにメモリバッファをフラッシュする
- スナップショットを実行する（下表参照）
- 上記の「スナップショットの作成」の後にデータベースの停止が解除される
- スナップショットの運用:
〇スケジュール設定
〇異なる場所への移動
〇監視とレポート
リカバリポイント
データのリカバリをする時はまずリカバリポイントを決めます。例えばZRMを使って毎日完全バックアップを取っていたとします。金曜日にデータベースが破損していることを発見しました。どのバックアップをリカバリしたらよいでしょうか？通常は破損が起こる直前のバックアップです。この例では木曜日の完全バックアップになるでしょう。
バックアップを頻繁に取ればリカバリポイントの粒度が高くなります。しかし毎時間ごとにバックアップを実行するのは困難です。以下のバックアップレベルの項目にあるように差分バックアップの実行により粒度の高いリカバリポイントを実現します。
バックアップレベル
ZRMは完全バックアップ（レベル0）と差分バックアップ（レベル1）の両方に対応しています。
完全バックアップはデータベースやテーブルの完全なコピーです。コピーはロジカルバックアップ、ロウバックアップ、スナップショットがベースになっています。
差分バックアップはMySQLバイナリログを利用して前回のバックアップから変更のあったデータのみを保存します。ZRMが差分バックアップをするときのログはフラッシュと保存時に読み取りロックをしない「ホットバックアップ」なので使用中のデータベースに与える影響はありません。
バイナリログですべてのデータベースのイベントを保存するので、粒度の高いリカバリポイントが実現できます。ZRMで差分バックアップされたデータのリカバリは、複数の差分バックアップをリストアする必要のある場合にも簡単です。差分バックアップはMySQLバイナリログが有効である必要がありますがこれは 動作が1％未満ほど遅くなるだけです。
ZRMアーキテクチャ
ZRMの詳細を説明する前にZRMのアーキテクチャを説明します。
ZRMのスケジュール機能ですべてのバックアップ処理の設定ができます。MySQLサーバとストレージエンジンとストレージ技術（スナップショットが利用できるか等）を考慮してZRMは自動でバックアップの方法を選びます。ZRMはデータベースへの影響を第一に考え、以下を基にしてスケジュールを決めます。
- スナップショットはできるか
- ロウバックアップはできるか
- レプリケーションはできるか
- バックアップセットにはMySQLクラスタのデータベースが含まれているか
スナップショットの格納先の容量が不十分な時などにはZRMはロジカルバックアップを実行します。
ZRMが自動で選んだ選択を変更することもできます。例えばスナップショットを利用する代わりにロジカルバックアップを実行することができます。
ZRMはすべてのバックアップにインデックスをつけてリストア時に必要なデータを探し出します。毎日ZRMは期限切れの古いバックアップがないかチェックします。期限の切れたバックアップはZRMのバックアップインデックスから排除されディスクから削除されます。レポートエンジンはカスタマイズのできるレポートをテキスト形式もしくはHTML形式で作成し、メールやRSSフィードをとおして通知します。
Zmanda管理コンソール(ZMC)
Zmanda管理コンソール(ZMC)はブラウザベースのユーザインターフェースによりセットアップやバックアップとリカバリの管理が簡単にできます。
ZMCが統合されたZmanda Networkからは、ZRMのバイナリ、ホワイトペーパー、デモンストレーション、技術的サポート、ナレッジベースが提供されます。ZMCは状況依存のヘルプとZRMの最新情報を提供します。Zmanda Networkに登録後はRSSフィードを通してZRMの最新版を通知します。
簡単にできるインストール
ZMCの高速インストーラによりインストール先のサーバのMySQL構成に影響をあたえることなくZRMを簡単にインストールすることができます。ZMCはLAMPやSAMP(Linux 、Solaris、Apache、MySQL、Perl/PHP)スタックがベースになっています。もしもZRMをインストールするPCにこれらのコンポーネントがすでに組み込まれているとどうなるのか。これは高速インストーラがAMPコンポーネントをすべて特定の場所(/opt/zmanda/zrm)に格納するので問題ではありません。加えて、ネットワークポートを要するこれらのコンポーネントは、インストールにすでに使われているどのポートとも競合しないポートを使用します。
包括的なバックアップとリカバリ
ZRMは企業用に機能が強化されたソリューションで、使用するOSにかかわらずすべてのMySQLのバージョンとそれに関連したすべてのストレージエンジン、レプリケーション、クラスタサーバなどをサポートします。以下の項目から、この包括的なバックアップについてご説明します。
データベースエンジン
ZRMで、NDBクラスタを含むすべてのデータベースエンジンをロジカルバックアップ、ロウバックアップ、スナップショットなどの手法でバックアップすることができます。ストレージエンジンによっては、実行できないバックアップ手法があることに注意してください。
ひとつのバックアップセットにストレージエンジンを混在(例えば、InnoDBテーブルとMyISAMのテーブル)させることができます。その場合ZRMは最適なバックアップ方法を選択する前にバックアップセットに混在するすべてのストレージエンジンを明らかにします。
複数OSに対応
ZRMをSolaris 10やLinuxのサーバ機にインストールして、WindowsやUNIXで動作するMySQLデータベースのバックアップをすることができます。下図では、Linux もしくはSolarisに導入されたZRMサーバが、それぞれ異なるストレージエンジンを持つWindows、Linux、Solaris上で動作するMySQLサーバをバックアップしています。
ZRMでのバックアップ方法
下表は、ZRMのバックアップ手法をOS別に示したものです。
MySQLクラスタのバックアップ
MySQLはNDBデータベースエンジンを使用することで、クラスタをサポートしてデータベースアプリケーションの高可用性を実現します。ZRMは、MySQL-ndb-toolsを使用してクラスタのロウバックアップを実行し、MySQLクラスタのための統合されたバックアップソリューションを提供する唯一の製品です。
簡単にできるバックアップの設定
ZRMのバックアップ設定には、以下を特定するだけです：
- 何をバックアップするか（バックアップ対象となる、サーバ、データベース、テーブルの特定）
- どこにバックアップを保管するか（保管先の特定）
- いつバックアップを実行するか（完全バックアップと差分バックアップのスケジューリング）
- どのようにバックアップを実行するか（使用するバックアップ手法の特定）
ZRMのユーザインターフェースには上記の設定が体系化されており、以下で説明するように、各ページ(Backup What、Backup Where、Backup When、Backup How)から各設定が実行できます。
Backup Whatのページでは、指定したMySQLサーバ上の、すべてのデータベースやテーブルが自動で検出されるのでバックアップソースの選択が容易です。以下の画像は、6つのデータベースを持つサーバをバックアップする場合の、ZRMでの設定例です。
Backup Whereページでは、このバックアップセットのバックアップを保存するためのディスクディレクトリを指定できます。
サーバ機のOSで利用できるストレージなら何にでも、バックアップを保存することができます。（ローカルのHDD、ネットワーク接続ストレージ（NAS）、複数サーバとアプリケーション間を接続するストレージエリアネットワーク(SAN)上のRAIDアレイなど）
Backup Whenのページでは、単一のバックアップセットについて完全バックアップと差分バックアップの複数スケジュールの設定ができます。例えば、毎週月曜日の午前2時に完全バックアップを実行するように設定して、さらに毎週月、水、金曜日の午前4時に差分バックアップが実行するように設定ができます。（下画面参照）
「Backup
Now」をクリックして完全バックアップや差分バックアップの即時実行ができます。バックアップの即時実行は処理をテストするときにも使えます。MySQLサーバもしくはOSのバージョンをアップデートする前には完全バックアップを取るようにしてください。
Backup
Howのページでロジカルバックアップかロウバックアップかを選びます。他にもバックアップについての様々な選択ができます。（圧縮、暗号化、処理前後のスクリプト、どのようにロウバックアップや差分バックアップを遠隔でコピーするか、MySQLレプリケーションの使用など）。
圧縮と暗号化
ZRMはOSで利用できるどのユーティリティを使ってもバックアップイメージの圧縮と暗号化ができます。例えば圧縮にはデフォルトのgzipを使います。標準入力（stdin）を読み込んで、標準出力（stdout）で出力できるユーティリティならばどれでも利用することができます。
レポート機能
Zmanda管理コンソールのレポート機能によりバックアップの監視ができます。カレンダーベースの色分けされた一覧により一日のバックアップの成功と失敗が分かります。赤の四角は失敗を表し、緑の四角は成功を表します。それぞれのバックアップの詳細を表示することもできます。
- バックアップのレポート
- バックアップのアプリケーション動作のレポート
- バックアップ状態のレポート
- バックアップ手段のレポート
- バックアップ保持期限のレポート
- バックアップ動作のレポート
- 差分バックアップのレポート
- バックアップのレプリケーションのレポート
- クラスタのバックアップのレポート
「バックアップアプリケーションの動作」レポートはMySQLが依存しているアプリケーションにバックアップが与える影響を表します。このレポートはアプリケーションの動作を改善するためにZRMでのバックアップ方法を変更するべきか考慮するときに役立ちます。
規定されたレポートの他に、バックアップとMySQLのパラメータの30項目以上でレポートをカスタマイズして保存しておくことができます。
レポートの作成や配信の方法には多様性があります。出力はテキスト形式もしくはHTML形式なのでRSSフィードやメールで配信することができます。ZRMのレポートをすでにお使いの監視ダッシュボードへ統合することもできます。
データベースイベントビューア
データベースイベントビューアでは差分バックアップされたMySQLのバイナリログを視覚的に見ることができるのでどの時点にリストアするのか正確に選択することができます。
データベースの各イベントの日時は個別に表されます。エントリを簡単にスクロールすることができ、インプット欄からログを検索することもできます。
これでトランザクションレベルのリカバリポイントを選択することができます。データベース・イベント・ビューワからリカバリポイントの選択ができます。まずはリカバリする最終トランザクションの横にある日時をクリックします。ZRMはその日時のデータベースをリカバリするリカバリ画面に変わります。
データベース・イベント・ビューワはリカバリ以外にも使えます。例えば悪意のあるもしくは疑わしい活動をするログを検索することができます。
簡単にできるリカバリ
ZRMのRがリカバリを表しているように、ZRMが目指しているのは簡単・確実・効率的なデータのリカバリです。
ZRMはロジカルバックアップでもロウバックアップでもスナップショットでも任意の時点へのリカバリができます。ただし差分バックアップも取られている必要があります。
- 成功したバックアップのレポートにあるタイムスタンプをクリックする
- データベースイベントビューワのリカバリポイントを特定してイベントのタイムスタンプをクリックする
- Restore Whatの画面から最後に取られた完全バックアップもしくはその他の成功したバックアップからリストアする
オリジナルとは別のMySQLサーバにバックアップをリストアすることができます。またリストアしたものから新しいMySQLレプリケーションスレーブのインスタンスを作成することができます。
この簡単なリストアの手順はどのストレージエンジンでもバックアップ手段でも同じです。データをリカバリする時の同じリカバリの手順は効率的で確実でストレスを軽減します。
簡単にできる管理
ZRMはMySQLのバックアップを簡単に管理できるいくつかの機能があります。これらのひとつが役割ベースのアクセス制御です。複数のZRMユーザを管理者やオペレータに定めることができます。管理者はバックアップセットを操作する完全な権限があります。オペレータは割り当てられたバックアップセットのみを操作する権限があります。これでバックアップとリカバリの責任を何人かに分担することができます。
ZRMはデフォルトの設定によりMySQLの環境に適したバックアップセットを即座に作成することができます。バックアップセットの設定時には必要な項目のデフォルトを変更するだけなので設定時間が短くなります。
終わりに
ZmandaリカバリマネージャはMySQLサーバのバックアップとリカバリの処理をすべて管理します。バックアップとリカバリの負担が軽減されるので他の重要な管理作業に集中することができます。
詳細について
詳細についてはZmanda Network http://network.zmanda.com
からデモンストレーション、プレゼンテーション、ホワイトペーパーがご覧いただけます。
Amandaネットワークバックアップ | MySQLバックアップ |パートナー |
サイトマップ |
会社概要 | お問い合わせ
Copyright © Zmanda, Inc. All rights reserved. Translated by Accutechs Co., LTD.
Copyright © Zmanda, Inc. All rights reserved. Translated by Accutechs Co., LTD.