MySQLソリューションバックアップリカバリ

リカバリ手法別比較

リカバリ方式について特徴と、実現手法を記載します。

	特徴	MySQL実現手法	Oracle実現手法
物理ファイルバックアップ時点までの復旧	バックアップメディアからのファイルリストアバックアップボリュームマウントとOSコピーによるリストア論理バックアップのリストアより速い	物理バックアップファイル OSコピー	物理バックアップファイル OSコピー
論理バックアップ時点までの復旧	論理ファイルのインポートユーティリティが必要物理ファイルバックアップのリストアより遅い Oracleではこの方式ではロールフォワードが不可能	論理バックアップファイル権限チェックなしでサーバを起動 Mysqlクライアントによる適用復旧後ロールフォワードが可能	論理バックアップファイル Impユーティリティ DataPumpユーティリティ復旧後のロールフォワードはできない
障害時点までの復旧（ロールフォワード）	トランザクションログを用いて、障害直前までの回復ある時刻への復旧（ポイントタイムリカバリ）	バイナリログ MysqlbinlogコマンドとMySQLクライアントでの反映	アーカイブログ alter database recoverコマンド
クラッシュリカバリ	データベースの強制終了時の不整合における自動リカバリ機能	Myisamchk InnoDBログによるサーバ起動時の自動リカバリ	Redoログによるサーバ起動時の自動リカバリ
スタンバイデータベースのマスター化	スタンバイデータベースを更新可能なマスタデータベースに変更する復旧速度が速い同構成のスタンバイ機が必要	バイナリログによる同期処理 Slave → Masterへの変更	アーカイブログによる同期処理スタンバイ→プライマリの変更
フラッシュバックデータベース	オペレーションミスやアプリケーション不具合による変更をフラッシュバックする専用のフラッシュバック領域が必要	機能なし	フラッシュバックデータベース

障害直前まで早期回復が可能となる、物理ファイル復元＋ロールフォワードがMySQLでもお勧めです。

▲PAGETOP

MySQLバックアップリカバリ　推奨手順（LINUX環境）

MySQLのバックアップリカバリの推奨手順として、物理ファイルのオンラインバックアップリカバリの実例を示します。環境はLINUX＋ローカルディスクを想定しています。

MySQLオンラインバックアップ手順概要

LVM Snapshotはオンラインバックアップ時にボトルネックとなるロック時間を圧縮します。
【補足】Oracleのオンラインバックアップ優位点としてロックをかけずに取得可能（Redoログ出力量は増えます）
【参照】MySQLブログ「MySQLのオンラインバックアップ手順」

▲PAGETOP

バックアップリカバリ所要時間

弊社検証環境でのバックアップリカバリ時間を参考までに紹介します。

検証環境情報

「MySQL Enterpriseの検索性能とスケーラビリティ」と同等。ただし高価用性ソリューションであるDRBD上で実施しているため、5～10%程度通常より遅くなっています。（DRBDはOSブロックレベルの遠隔ミラーリングソリューションです）

ファイルサイズとテーブル量

バックアップファイルサイズトータル：4.5GB
900万件テーブル（InnoDB)×１、 100万件テーブル（InnoDB)×１、100万件テーブル（MyISAM)×２

	Flush tables with read lock + snapshot	Mysqldump	Coldバックアップ
FLUSH TABLES With Read Lock＋Lvcreate～snapshotのマウント	5秒程度	-	-
物理ファイルコピー	1分41秒	-	2分程度
Snapshotのアンマウントと削除	4秒程度	-	-
Mysqldumpコマンド	-	1分20秒	-
ファイルリストア	6分15秒	-	6分程度
Mysqldump反映	-	35分2秒	-
ロールフォワードSQL作成	1秒程度	1秒程度	1秒程度
ロールフォワード（100万件テーブルの反映）	25秒程度	25秒程度	25秒程度

テーブルが１０００万件程度の環境では高価な共有ストレージ機能を利用しなくてもバックアップは十分に可能ですが、Mysqldumpのリストアにはある程度時間を要します。

▲PAGETOP

バックアップ手法別比較

MySQLも他の商用RDBMSと同様に様々なバックアップ手法が用意されています。Oracleとの比較例を以下に記載します。

Colｄバックアップ

■物理バックアップ

特徴	MySQL実現手法	Oracle実現手法
構成ファイルそのものをバックアップデータベース全体で一貫性のあるバックアップ取得が容易バックアップ中はDBサーバの停止が必要	OSコマンドによるファイルコピーストレージ製品の遠隔ミラー機能（EMC MirrorView/AやSnapMirror）による取得	OSコマンドによるファイルコピーストレージ製品の機能（EMC MirrorView/AやSnapMirror）による取得

オンラインバックアップ

■物理バックアップ

特徴	MySQL実現手法	Oracle実現手法
構成ファイルそのものをバックアップサーバ停止無しでバックアップ取得が可能通常、論理バックアップより高速全体で一貫したバックアップを行うには、全テーブルをロックする必要がある。もしくは差分をトランザクションログで補完する	OSコマンドによるファイルコピーストレージ製品の遠隔ミラー機能による取得スナップショット（LVM Snapshot等）＋OSコピーによる取得 Read Table With Read Lock Zmanda（他社製品） InnoDB HotBackup（他社製品）	OSコマンドによるファイルコピーストレージ製品の遠隔ミラー機能による取得スナップショット（LVM Snapshot等）＋OSコピーによる取得 Begin Backup文 Recovery Manager（RMAN)

■論理バックアップ

特徴	MySQL実現手法	Oracle実現手法
テーブル定義やデータを、SQLやCSVファイルとして論理的に取得サーバ停止無しでバックアップ取得が可能全体で一貫したバックアップを行うには、全テーブルをロックする必要がある通常、物理バックアップより低速	Mysqldumpコマンド Select into OUT FILE コマンドバックアップ時点からのロールフォワードが可能	Exportユーティリティ DataPumpユーティリティ ※全体で一貫性を保つにはCONSISTENT=Yオプションや全体へのロックが必要バックアップ時点までの復旧しかできない。（ロールフォワード不可能）

その他

■レプリケーション（スタンバイデータベース）

特徴	MySQL実現手法	Oracle実現手法
レプリケーション側をバックアップDBとして扱うロックが不要、リカバリ所要時間が早い同構成のスタンバイ機が必要	Master-Slaveレプリケーション（バイナリログ適用による同期処理）	Data Guard （アーカイブブログ適用による同期処理）

■増分バックアップ（トランザクションログ）

特徴	MySQL実現手法	Oracle実現手法
バックアップ時点からのトランザクションログを、増分バックアップとして扱う	バイナリログ	アーカイブログ

オンライン中に取得が可能で速度が速い、オンライン物理バックアップのニーズが高いと考えます。
MySQLもOracleと同じように多様なバックアップ選択肢があり、運用スタイルあったバックアップを選択できます。

▲PAGETOP

トランザクションログ

MySQLのトランザクションログはバイナリログと呼ばれます。

MySQL バイナリログについて

MySQLのバイナリログは、OracleでいうRedoログ、アーカイブログに該当し、バックアップリカバリやレプリケーションにおいて、非常に重要な役割を持ちます。

	MySQLバイナリログ	Oracle Redoログ
用途	ロールフォワードリカバリスタンバイデータベース（DRサイト、レプリケーション）（InnoDBのクラッシュリカバリにはInnoDBログを利用、InnoDBログは物理論理ロギング方式）	ロールフォワードリカバリクラッシュリカバリスタンバイデータベース（DR サイト等）
ファイル形式	バイナリファイル（ロールフォワードリカバリ時はMysqlbinlogコマンドにより、SQL文に変換）	バイナリファイル（ロールフォワードリカバリ時は対象ディレクトリに配置、ogMinerにより解析可能）
ロギング方式	論理ロギング（SQL文レベルのロギング）	物理論理ロギング（SQL文レベル＋更新ブロックレベルのロギング）
書込みタイミング	「sync_binlog=1」指定でCommitと同時指定しないと非同期書込み	Commit時 Redoログバッファの1/3を消費した場合
ログスイッチ	ログが1Gを超えた時点、MySQLサーバの起動時、Flush Log文発行時にログスイッチが発生する	Alter system switch log文発行時
ログローテーションとアーカイブ	ログスイッチ時に新規ファイルに書込みが開始、ログファイルの再利用（カレントのローテート）はしない	オンラインRedoログがローテーション、アーカイブログモード時は、オンラインRedoログのスイッチ時にアーカイブ
出力制御	出力なし設定可能	ノーアーカイブログモードが可能、Redoログは必須

Enterprise環境での利用には

起動パラメータ「sync_binlog = 1 」を推奨します。このパラメータを指定することでCommit時のバイナリログ同期書込みが保障されます。

ただし、Ext3ファイルシステムでは更新系パフォーマンスの影響があるため、パフォーマンスとトレードオフの関係となります。

MySQLバックアップリカバリのポイント

MyISAMも更新が頻繁に起こるような場合は、Flush TABLE WITH READ LOCK 文によるバックアップを選択したほうが無難。
ロック時間を極力短くするため、スナップショットやストレージ製品のミラーリングボリューム機能を利用する。
Mysqldumpは、InnoDB取得用と考えたほうがよい。MyISAMテーブルも取るのであれば、ロック時間を覚悟するか、バックアップ中にはMyISAMテーブルを更新しない。
Mysqldumpは、論理バックアップなので、バックアップ、リカバリは遅い。
サーバ停止することが可能であれば、手順が簡素なColdバックアップが効率が良い。
障害時点まで、もしくは指定時間までの回復が必要であればバイナリログの取得が必須。
システム全体で一貫性のあるバックアップ取得には全テーブルにロックをかける必要がある。（Oracleはロックなしで取得可能）
数秒のロックがクリティカル事象となる場合、条件的に厳しくなる可能性がある。