MySQLが広く普及し、ますます企業で採用されるようになるにつれて、データベース管理者はZRM for MySQLのような包括的なバックアップとリカバリのソリューションで重要なデジタル資産を保護することが必要になってきます。ZmandaはMySQLが高く評価する企業でありZmandaのオープンソース型バックアップ製品は優れた機能でMySQLのオープンソース型データベースをサポートしています。
MySQL AB. 最高責任者
試験形状
2 x 2.8Ghz/800 FSB Xeon server
4GB ECC/Registered 333Mhz RAM
9500S-12MI 3Ware SATA Controller
230 GB RAID 1 system array
2.27 TB RAID 0 data array
All Disks 7200 RPM
Operating System - Red Hat Enterprise Linux AS 4
with 2.6.12 kernel
MySQL version 5.0
MyISAM and InnoDB storage engines
Version 1.1 of Enterprise Edition ZRM for MySQL
3Wareの9500 SATAコントローラはおよそ400MB/sの転送速度をサポートしています。テストサーバは平均 37 MB/sの転送速度でファイルをコピーすることができました。
ZRMの本番環境でのバックアップとリカバリの速度をテストするために映画推薦システムの精度の向上をめざすNetflix Prize のプロジェクトの一端としてNetflix データベースを使用しました。InnoDBとMyISAMのストレージエンジンに1000、2000、4000MBのデータベースを使い転送速度がデータベースの大きさによって変化するのかテストしました。各データベースには、映画の題名と映画の評価の2つのテーブルが存在します。転送速度を計算するためにデータベースのサイズをバックアップとリカバリに要した時間で割りました。転送速度の結果は4ページの表をご覧ください。
ZRMから Mysqldumpでロジカルバックアップの指示をだしてテストを始めました。ロジカルバックアップのバックアップファイルはデータベースのリカバリに必要なすべてのMySQLステートメントの入ったテキストファイルなのでリカバリに柔軟性があります。MysqldumpでのロジカルバックアップはNDBエンジン以外のストレージエンジンで利用可能です。（NDBエンジンはMySQLクラスタにのみ使われます）ロジカルバックアップの最大の利点はバックアップを他のアーキテクチャやデータベースにリストアできるという移植性です。ロジカルバックアップでのバックアップイメージを移植できることもZRMをより便利なツールにしています。MySQLのデータ移植の例：
- SolarisのMySQLからLinuxのMySQLへ
- ストレージエンジンから別のストレージエンジンへ
- 32ビット版のサーバから64ビット版のサーバへ
- マネージド・ホスティング・プロバイダからデータセンターや別のMySQLのプロバイダへ
しかし柔軟性のあるリカバリには短所もあります。ロジカルバックアップをしたデータのリストアにはいくつかのMySQLステートメントをすべて読み込んで再発行しなくてはいけないので、長い時間がかかります。MyISAMエンジンでのバックアップ速度は5MB/sで、リストア速度はほんの2MB/sでした。InnoDBエンジンでのバックアップ速度は8MB/sで、リストア速度は2MB/sでした。
ZRMはバックアップ時のMySQLサーバの状態を通知します。例えば、メモリのバッファをフラッシュするのにかかった時間や読み取りロックにかかった時間をお知らせします。MyISAMとInnoDBエンジンのロジカルバックアップ中の読み取りロック時間はバックアップ時間の95％でした。これはバックアップがアプリケーションに与える影響について重要なことです。読み取りロック時間が短くなることはアプリケーションやユーザにとって有益です。
ロジカルバックアップのその他の短所にバックアップファイルのサイズが分かりにくいことがあげられます。データのタイプやデータベーススキーマによってはロジカルバックアップのサイズがデータベース自体よりも大きくなる可能性があります。 テストではMyISAMエンジンのバックアップファイルをデータベースファイルよりも30％大きくしました。ロジカルバックアップはテキストなので通常は大幅に圧縮して対処することができます。おもしろいことに、InnoDBエンジンの圧縮されていないロジカルバックアップファイルはデータベースファイルよりも40％小さいサイズでした。
次にZRMからMyISAMとARCHIVEエンジンにのみ使われるmysqlhotcopyを使ってのローバックアップとリカバリの動作をテストしました。ローバックアップはバイナリファイルになったデータベースのコピーです。
ローバックアップの長所：
- バックアップは高速で、リカバリはさらに高速です。テストの結果、バックアップの転送速度は26MB/sで、ロジカルバックアップの5倍以上の速度でした。リカバリの転送速度は40MB/sで、ロジカルリカバリの20倍以上の速度でした。
- データベースのコピーなのでバックアップのサイズが分かります。
- 読み取りロック時間はバックアップにかかる時間のほんの60％です。
mysqldumpでのロジカルバックアップとmysqlhotcopyでのローバックアップはウォームバックアップになります。ウォームバックアップをする時はバックアップのためにMySQLサーバを中断する必要はありませんが、テーブルはロックされるのでデータを入力することはできません。 MySQLサーバがロジカルボリュームマネージャ（LVM）の組み込まれたLinuxで動作するのなら、ZRMからLVM2のスナップショットを利用したローバックアップができます。スナップショットでのバックアップはすべてのストレージエンジンで速い動作をしますが、InnoDBやFalconなどのトランザクションエンジンで最大の性能を発揮します。トランザクションエンジンではホットバックアップを実行するのでバックアップ中の読み取りロック時間はほとんど無くなります。スナップショットでのバックアップとリカバリの速度は、mysqlhotcopyでのバックアップとリカバリの速度とほぼ同じでした。ローバックアップのリカバリは、同じOSで同じバージョンのMySQLサーバにしかできないので、ローバックアップかロジカルバックアップか選択をする時には考慮してください。
テストではデータベースのサイズの大小によるバックアップとリカバリの転送速度に目立った違いは見られませんでした。
ZRMを使ったMyISAMとInnoDBエンジンのバックアップとリカバリの転送速度
次ページで4000GBのデータベースの転送速度を分かりやすくグラフに表しました。37MB/s上にある灰色の点線はデータベースファイルをcpコマンドでコピーした内部動作を表しています。
テストに使ったハードウェアと同様のものなら、データベースのバックアップとリカバリの時間が推定できます。MyISAMの10GBのテーブルならば、ロジカルバックアップの完了までにおよそ40分かかります。(10,000MB÷4.7MB/s=2128 秒= 35.5分) リストアには1時間半以上かかるでしょう。しかし、スナップショットを使うとバックアップにはたった7分でリカバリには4分しかかかりません。ただし、本番環境では前回から変更のあったデータベースだけをバックアップするのなら差分バックアップをするのが一般的です。通常は差分バックアップのサイズは全データベースファイルの5％以下です。ZRMはあらゆる方法での差分バックアップとストレージエンジンの差分バックアップをサポートします。
今後の計画
以上の結果はユーザがなにも作動させていない時のZRMの速度をテストしたものです。データベース管理者が気にかけている、ユーザがMySQLを使用時のZRMの動作を含めて今後もテストを継続していきます。
ZRMをご使用のご意見、ご感想をメールで
feedback@zmanda.com
,もしくはフォーラム
http://forums.zmanda.comまでお寄せください。
ZRMについての詳細な情報はこちらをご覧ください。
http://www.zmanda.jp/backup-mysql.html
使用説明書はこちらをご覧ください。
http://mysqlbackup.zmanda.com/
ZRMのコミュニティ版はこちらからダウンロードできます。
http://www.zmanda.com/downloads.html
