MySQLのバックアップ・リカバリ(オープンソースカンファレンス2005)2005年3月26日

ソニーグローバルソリューションズ株式会社
プラットフォーム技術部
松信 嘉範 (MATSUNOBU Yoshinori)© 2005 Sony Global Solutions Inc.

目次
 基本事項の整理
 MySQLの機能概要
 メディア障害とリカバリの流れ バイナリログ
 コールドバックアップ・リカバリ
 オンラインバックアップ・リカバリ
 mysqldump
 FLUSH TABLES WITH READ LOCK その他のトピック メディア障害を考慮したファイル配置
 過去の一時点へのリカバリ
 内部的な動作© 2005 Sony Global Solutions Inc.

MySQLの特徴/機能概要
観点特徴

動作環境

Linux,Solaris,HP-UX,AIX,Windows他

実装言語

C/C++(マルチスレッド)

SQL文・SQL92の大半とSQL99 Coreの一部、また便利な独自構文を提供
・サブクエリは4.1から、ストアドプロシージャは5.0から

テーブル定義・InnoDB、MyISAM等の「型」がある(ストレージエンジン)
・B-Tree索引、整合性制約、シーケンスをサポート(ビューは5.0から)

トランザクション・ロック無しでの読み取り一貫性、行ロック、4段階全ての分離レベルなどをサ
ポート(InnoDBのみ)

バックアップ・ロックをかけずに一貫性のあるオンラインバックアップが可能(InnoDBのみ)
・増分バックアップ相当の機能を提供

リカバリ

・ロールフォワードリカバリ(過去の一時点も含む)が可能
・クラッシュリカバリが可能(InnoDBのみ)

日本語処理

・列単位でキャラクタセットの指定が出来る(4.1から)・ベンダー定義文字のコード変換はサポートしていない(文字化けする)

セキュリティ

・認証手段は、パスワード認証とSSLクライアント証明書認証
・暗号化の手段はSSLとVPN(SSHポートフォワーディングなど)© 2005 Sony Global Solutions Inc.

MySQLのデータベース構成

mysqldプロセス

データベース領域
権限データベース(mysql)
MyISAM表

データベース１

MyISAM表

データベース２

InnoDB表

データベース３
InnoDB表

InnoDB表
MyISAM表© 2005 Sony Global Solutions Inc.

InnoDB表MySQLのディレクトリ/ファイルの種類
ベースディレクトリ
データディレクトリ
データベースディレクトリ
表定義ファイル
InnoDBデータファイル
InnoDBログファイル
MyISAM表ファイル
MyISAM索引ファイル
バイナリログファイル[mysqld]
basedir=/usr/mysql4110
datadir=/data/mysql4110
innodb_data_home_dir=/data/mysql4110/idata
innodb_data_file_path= ibdata1:1000M:autoextend
innodb_log_group_home_dir=/data/mysql4110/ilog
socket=/data/mysql4110/mysql.sock
log-bin=/data/mysql4110/blog/mysql-host
初期化パラメータファイル(my.cnf)

エラーログファイル
一般クエリログファイル
スロークエリログファイル
ソケットファイル
PIDファイル
ディレクトリ・ファイルの種類© 2005 Sony Global Solutions Inc.

テーブル(ストレージエンジン)とファイルの関係
表A〜表C：InnoDB
InnoDB

表D〜表F：MyISAM とすると…

InnoDB
ログバッファ

InnoDBバッファ

コミット済になると同期書込される

非同期に書込まれる

表A.frm
表B.frmIb_logfile0

Ib_logfile1

InnoDBログファイル

表C.frm

表A ibdata1
表B

ibdata2
表C

InnoDBデータファイル
MyISAM

表定義ファイル

表D.MYD表D.MYI

表D.frm

表E.MYD

表E.MYI

表E.frm表F.MYD

表F.MYI

表F.frm表データファイル

索引データファイル

表定義ファイル© 2005 Sony Global Solutions Inc.

メディア障害とは アプリケーションの動作に必要な表やファイルが消失し、アプリケーションとして機能しなくなる障害のこと
 メディア障害の主な要因
 ハードウェア障害
 ソフトウェア障害
 人為的ミス メディア障害からの回復手段
 事前に全体バックアップを取っておく リストアして、リカバリする¾ リストア：バックアップの時点まで復旧すること¾ リカバリ：障害直前の時点まで復旧すること(ロールフォワードリカバリ)© 2005 Sony Global Solutions Inc.

ロールフォワードリカバリの概要
障害発生
時間軸

t1時点での全体バックアップ

t1

t1〜t2間のトランザクションログ(バイナリログ)

t2

t2〜t3間のトランザクションログ(バイナリログ)t3

t3以降のトランザクションログ(バイナリログ)

・過去のバックアップをリストアした後、バックアップ以降のトランザクションログ(バイナリログ)を順次適用し、障害直前の状態に復旧する。これをロールフォワードリカバリと言う。
・MySQLでは、全体バックアップに「一貫性」がなければならない。
※一貫性：t1時点でコミットされているデータのみをバックアップしていること© 2005 Sony Global Solutions Inc.

 基本事項の整理
 MySQLの機能概要
 メディア障害とリカバリの流れ バイナリログ
 コールドバックアップ・リカバリ
 オンラインバックアップ・リカバリ
 mysqldump
 FLUSH TABLES WITH READ LOCK その他のトピック メディア障害を考慮したファイル配置
 過去の一時点へのリカバリ
 内部的な動作© 2005 Sony Global Solutions Inc.

バイナリログ(1) バイナリログとは
 MySQLのトランザクションログ(バイナリファイル)¾ ロールフォワードリカバリには必須
 SQL文を時系列に蓄積したもの コミット後に書き込まれる mysqlbinlogというコマンドでテキスト形式のSQL文に変換できる

use db1;
SET TIMESTAMP=1108825248;
CREATE TABLE tbl1 (col1 INTEGER, col2 DATETIME) ENGINE=InnoDB;
SET TIMESTAMP=1108825248;
INSERT INTO tbl1 VALUES(100,SYSDATE());
SET TIMESTAMP=1108825250;
DROP TABLE tbl1;© 2005 Sony Global Solutions Inc.

バイナリログ(2) バイナリログの取得方法
 デフォルトでは取得されない デフォルトではコミット時同期書き込みではない[mysqld]
basedir=/usr/mysql4110
datadir=/data/mysql4110
innodb_data_home_dir=/data/mysql4110/idata
innodb_data_file_path= ibdata1:100M:autoextend
innodb_log_group_home_dir=/data/mysql4110/ilog
pid-file=/data/mysql4110/mysql-host.pid
socket=/data/mysql4110/mysql.sock
log-bin=/data/mysql4110/blog/mysql-hostinnodb_safe_binlog
ファイル名の拡張子は6桁の連番(4.0系では3桁)→ mysql-host.000001 …
log-binでバイナリログが有効になる(ディレクトリ名とバイナリログの接頭辞を指定する)
innodb_safe_binlogを指定するとコミット時同期書き込みになる© 2005 Sony Global Solutions Inc.

バイナリログ(3) バイナリログの切り替え
 新しくファイルを作成し、書き込み先を切り替える 切り替え後のファイルには書き込みが発生しない
 増分バックアップ相当の機能を実現可能
 切り替えた後のファイルをバックアップすることで可能
書き込み

書き込み

.000001

バイナリログの切り替え.000001.000002

切り替え後のファイルには書き込みは発生しない→バックアップ可能© 2005 Sony Global Solutions Inc.

バイナリログ(4) バイナリログが切り替わるタイミング
 手動切り替え¾ FLUSH LOGS; (SQL文)¾ mysqladmin --flush-logs (OSコマンド) 自動切り替え¾ mysqldの再起動時¾ ファイルが一定サイズを超えた場合
z (max_binlog_size：デフォルト1GB、最大1GB)© 2005 Sony Global Solutions Inc.

 基本事項の整理
 MySQLの機能概要
 メディア障害とリカバリの流れ バイナリログ
 コールドバックアップ・リカバリ
 オンラインバックアップ・リカバリ
 mysqldump
 FLUSH TABLES WITH READ LOCK その他のトピック メディア障害を考慮したファイル配置
 過去の一時点へのリカバリ
 内部的な動作© 2005 Sony Global Solutions Inc.

コールドバックアップ・リカバリ(1) コールドバックアップとは mysqldプロセスを停止して取得するバックアップ
 OSコマンドによって取得する

１．mysqldを停止$mysqladmin shutdown --user=root --password=(パスワード) --socket=(ソケットファイル名)
２．バックアップを取得#cp -rp (データベース領域) (バックアップ先)
３．mysqldを起動$cd <MySQLインストールディレクトリ>$./bin/mysqld_safe --defaults-file=(初期化パラメータファイル名)© 2005 Sony Global Solutions Inc.

コールドバックアップ・リカバリ(2)障害発生
時間軸t1時点での全体バックアップ

t1

t1〜t2間のバイナリログ(mysql-host.000011)

バックアップ済
コールドバックアップ© 2005 Sony Global Solutions Inc.

t2

t2〜t3間のバイナリログ(mysql-host.000012)

t3

t3以降のバイナリログ(mysql-host.000013)

未バックアップコールドバックアップ・リカバリ(3) リストア mysqldを停止した状態でリストアする

１．バックアップファイルをコピー#cp -rp (バックアップ先) (データベース領域)© 2005 Sony Global Solutions Inc.

コールドバックアップ・リカバリ(4) ロールフォワードリカバリ
 mysqldを起動した状態で行う(外部からの接続は遮断すべき) mysqlbinlogによってバイナリログをテキスト形式のSQL文に変換
 適用の開始位置に注意
 文字化けに注意
１．まだバックアップしていないバイナリログをバックアップする#cp –p mysql-host.000013 (バックアップ先)
２．バイナリログの中身をテキスト形式のSQL文に変換$mysqlbinlog --disable-log-bin mysql-host.000011 mysql-host.000012
mysql-host.000013 > (ロールフォワード用SQLファイル名)
３．mysqldを起動$cd (MySQLインストールディレクトリ)$./bin/mysqld_safe --defaults-file=(初期化パラメータファイル名) --skip-networking
４．SQL文を適用$mysql --user=root --password=(パスワード) --socket=(ソケットファイル名)--default-character-set=sjis < (ロールフォワード用SQLファイル名)© 2005 Sony Global Solutions Inc.

コールドバックアップ・リカバリ(5) mysqldの再起動
 初期化パラメータを正常に戻して再起動する

１．mysqldを停止$mysqladmin shutdown --user=root --password=(パスワード) --socket=(ソケットファイル名)
２．mysqldを起動$cd (MySQLインストールディレクトリ)$./bin/mysqld_safe --defaults-file=(初期化パラメータファイル名)© 2005 Sony Global Solutions Inc.

 基本事項の整理
 MySQLの機能概要
 メディア障害とリカバリの流れ バイナリログ
 コールドバックアップ・リカバリ
 オンラインバックアップ・リカバリ
 mysqldump
 FLUSH TABLES WITH READ LOCK その他のトピック メディア障害を考慮したファイル配置
 過去の一時点へのリカバリ
 内部的な動作© 2005 Sony Global Solutions Inc.

mysqldump(1) mysqldumpとは
 MySQL標準のバックアップツール
 バックアップ対象の全ての表に対してSELECT文を実行することで取得
 バックアップ結果はSQL文の羅列
 引数の数が多く、それぞれが極めて重要
 バージョンは4.1.11以降を推奨
 InnoDB以外は、一貫性を保証するために、バックアップ中に共有ロックが必要 部分バックアップも可能 文字化けに注意
１．バックアップを取得$mysqldump --user=root --password=(パスワード) --socket=(ソケットファイル名)--single-transaction--master-data--flush-logs--default-character-set=sjis--all-databases> (バックアップファイル名)© 2005 Sony Global Solutions Inc.

解説：一貫性のあるバックアップ
セッション1

バックアップ実行期間

表Aのバックアップ開始

表Bのバックアップ開始

mysqldump
実行開始
t1

表Aのバックアップ終了

t3
t2

セッション2

t5
t4

表Bを更新

表Bのバックアップ終了

mysqldump
実行終了

t6

t7

t8

時間軸

表Aを更新

 バックアップデータは、いつの時点のものか？
 MyISAM：SELECT文を実行した時刻にコミットされていたデータ¾ 表Aならt2、表Bならt6 →一貫性が無い
 InnoDB：START TRANSACTION WITH CONSISTENT SNAPSHOT文を実行した
時刻にコミットされていたデータ¾ mysqldumpならt1に実行するので、表A、表Bともt1 →一貫性がある InnoDB以外をバックアップする場合、データベース全体に共有ロックをかけておかないと、一貫性のあるバックアップは取れない mysqldumpの引数--lock-all-tables© 2005 Sony Global Solutions Inc.

mysqldump(2)
障害発生
時間軸

t1時点での全体バックアップ

t1

t1〜t2間のバイナリログ(mysql-host.000011)

バックアップ済
mysqldump による全体バックアップ(一貫性必須)© 2005 Sony Global Solutions Inc.

t2

t2〜t3間のバイナリログ(mysql-host.000012)

t3

t3以降のバイナリログ(mysql-host.000013)

未バックアップmysqldump(3) リストア
 mysqldを起動した状態で、SQL文を実行することでリストアする
 mysqlデータベースが消失している場合は、認証機能を無効にする必要がある
１．まだバックアップしていないバイナリログをバックアップ#cp –p mysql-host.000013 (バックアップ先)
２．mysqldを起動$cd (MySQLインストールディレクトリ)$./bin/mysqld_safe --defaults-file=(初期化パラメータファイル名)--skip-networking --skip-grant-tables
３．バックアップしておいたSQL文を実行$ mysql --user=root --password=(パスワード) --socket=(ソケットファイル名)--default-character-set=sjis < (バックアップファイル名)
４．作成されるファイルの一部を削除$ cd (データディレクトリ)$ rm master.info mysql-host-relay-bin.000001 mysql-host-relay-bin.index relay-log.info© 2005 Sony Global Solutions Inc.

mysqldump(4) ロールフォワードリカバリ
 mysqldを起動した状態で行う
 mysqlbinlogによってバイナリログをテキスト形式のSQL文に変換
 適用の開始位置に注意
 文字化けに注意

１．バイナリログの中身をテキスト形式のSQL文に変換$mysqlbinlog --disable-log-bin mysql-host.000011 mysql-host.000012
mysql-host.000013 > (ロールフォワード用SQLファイル名)
２．SQL文を適用$mysql --user=root --password=(パスワード) --socket=(ソケットファイル名)--default-character-set=sjis < (ロールフォワード用SQLファイル名)© 2005 Sony Global Solutions Inc.

 基本事項の整理
 MySQLの機能概要
 メディア障害とリカバリの流れ バイナリログ
 コールドバックアップ・リカバリ
 オンラインバックアップ・リカバリ
 mysqldump
 FLUSH TABLES WITH READ LOCK その他のトピック メディア障害を考慮したファイル配置
 過去の一時点へのリカバリ
 内部的な動作© 2005 Sony Global Solutions Inc.

FLUSH TABLES WITH READ LOCK(1) FLUSH TABLES WITH READ LOCKとは
 データベース全体を共有ロックする(=更新をブロックする)SQL文
 共有ロックを解除するまで、全セッションから一切の更新が出来ない¾ 実行中のトランザクションは、以降の更新系SQL文の発行とCOMMITが出来ない
 MyISAM表データは全てディスクに書き込まれる バージョンは4.1.11以降を推奨© 2005 Sony Global Solutions Inc.

FLUSH TABLES WITH READ LOCK(2) 「共有ロック→全体バックアップ→共有ロック解除」によってバックアップを取得できる

１．共有ロックをかける
mysql> FLUSH TABLES WITH READ LOCK ;２．バックアップを取得#cp -rp (データベース領域) (バックアップ先)
３．バイナリログを切り替える
mysql> FLUSH LOGS ;４．共有ロックを解除
mysql> UNLOCK TABLES ;© 2005 Sony Global Solutions Inc.

バックアップ時間をいかに短縮するかが鍵↓
一部のRAID対応バックアップソフトの同期/スプリット機能や、
LVM、Win2003 VSS等のスナップショット・バックアップ機能の活用

FLUSH TABLES WITH READ LOCK(3)
障害発生
時間軸

t1時点での全体バックアップ

t1

t1〜t2間のバイナリログ(mysql-host.000011)

バックアップ済
FLUSH TABLES WITH
READ LOCK による全体バックアップ© 2005 Sony Global Solutions Inc.

t2

t2〜t3間のバイナリログ(mysql-host.000012)

t3t3以降のバイナリログ(mysql-host.000013)

未バックアップ

FLUSH TABLES WITH READ LOCK(4) リストア mysqldを停止した状態でリストアする リストアしたデータは、InnoDBデータファイルとInnoDBログファイルの同期が取れていないので、mysqld起動時にクラッシュリカバリが行われる

１．バックアップファイルをコピー#cp -rp (バックアップ先) (データベース領域)© 2005 Sony Global Solutions Inc.

解説：クラッシュリカバリ
 InnoDB表の回復処理 mysqld起動時に自動的に行われる、InnoDBログファイルとInnoDBデータファイルの同期をとる処理
 同期が取れていない状態でmysqldを起動すると発生¾ 電源断などのmysqld異常終了時¾ FLUSH TABLES WITH READ LOCK中に取得したバックアップを使う場合
 InnoDB以外の表に対しては行われない

col1
100→1000(コミット)
200→300(未コミット)

100

クラッシュリカバリ

200
tbl1(InnoDB)
100→1000

InnoDBログファイル© 2005 Sony Global Solutions Inc.

200→300(未コミット)

InnoDBデータファイル

1.InnoDBログファイルを読む
2.InnoDBデータファイルを操作
・100→1000にする(ロールフォワード)・300→200にする(ロールバック)FLUSH TABLES WITH READ LOCK(5) ロールフォワードリカバリ(コールドバックアップの際と同様)
 mysqldを起動した状態で行う(外部からの接続は遮断すべき) mysqlbinlogによってバイナリログをテキスト形式のSQL文に変換
 適用の開始位置に注意
 文字化けに注意
１．まだバックアップしていないバイナリログをバックアップする#cp –p mysql-host.000013 (バックアップ先)
２．バイナリログの中身をテキスト形式のSQL文に変換$mysqlbinlog --disable-log-bin mysql-host.000011 mysql-host.000012
mysql-host.000013 > (ロールフォワード用SQLファイル名)
３．mysqldを起動(クラッシュリカバリが自動的に発生)$cd (MySQLインストールディレクトリ)$./bin/mysqld_safe --defaults-file=(初期化パラメータファイル名) --skip-networking
４．SQL文を適用$mysql --user=root --password=(パスワード) --socket=(ソケットファイル名)--default-character-set=sjis < (ロールフォワード用SQLファイル名)© 2005 Sony Global Solutions Inc.

 基本事項の整理
 MySQLの機能概要
 メディア障害とリカバリの流れ バイナリログ
 コールドバックアップ・リカバリ
 オンラインバックアップ・リカバリ
 mysqldump
 FLUSH TABLES WITH READ LOCK その他のトピック メディア障害を考慮したファイル配置
 過去の一時点へのリカバリ
 内部的な動作© 2005 Sony Global Solutions Inc.

メディア障害を考慮したファイル配置(1)データベース領域

バイナリログ以外(InnoDBデータファイル、InnoDBログファイル、frm、MYD、MYI)

バイナリログ

ディスク１

ディスク２

バイナリログが全て無事であれば、全体バックアップとバイナリログによって、最新の状態にロールフォワードリカバリできる。

© 2005 Sony Global Solutions Inc.

メディア障害を考慮したファイル配置(2)データベース領域

バイナリログ以外(InnoDBデータファイル、InnoDBログファイル、frm、MYD、MYI)

バイナリログ

ディスク１

ディスク２

バイナリログ以外が無事であれば、データの消失は起こらない。
ロールフォワードリカバリも不要。
更新はできなくなる。ただし正常シャットダウンが可能なので、停止した上で全体バックアップを取得すれば良い。

© 2005 Sony Global Solutions Inc.

過去の一時点へのリカバリ
 mysqlbinlogの引数--stop-datetimeによって、バイナリログの変換範囲を指定できる
 DATETIME/TIMESTAMP型のフォーマットを指定
 指定した時刻までのバイナリログがSQL文に変換される¾ →指定した時刻までロールフォワードリカバリできる

3/26の13:30までのバイナリログをSQL文に変換$ mysqlbinlog --stop-datetime=”2005-03-26 13:30:00” (バイナリログファイル名)© 2005 Sony Global Solutions Inc.

mysqldumpの動作$ mysqldump --single-transaciton --master-data--flush-logs --all-databases
1) mysqldump実行開始
2) FLUSH TABLES WITH READ LOCK;
3) SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
4) START TRANSACTION WITH CONSISTENT SNAPSHOT;
5) FLUSH LOGS;
6) UNLOCK TABLES;
7) 全ての表に対してSELECT文を実行
8) mysqldump実行終了
1)2) 〜 6)

100

1000

200

2000

tbl1(InnoDB)

tbl2(MyISAM)
他のセッションから更新

7)8)3003000

200

2000tbl1(InnoDB)

tbl2(MyISAM)© 2005 Sony Global Solutions Inc.

2) 〜 6)の間は更新不可(通常は一瞬で終わる)

バックアップデータの中身
100

3000

200

2000tbl2(MyISAM)
tbl1(InnoDB)・InnoDBは2)〜6)時点でコミットされていた行データを選んでバックアップする。また、5)以降のバイナリログを適用してロールフォワードリカバリが可能。
・MyISAM他は7)のSELECT文実行時点でコミットされていた行データをバックアップする。
→全体で見れば一貫性が保証されない。また、どこからロールフォワードリカバリすれば良いか特定できない。

FLUSH TABLES WITH READ LOCKの動作
１．グローバルな共有ロックを確保(以降の更新SQL文を全てブロック)２．未終了の更新SQL文を待つ(SQL文レベル。トランザクションレベルではない)
３．COMMIT文をブロックするためのロックを確保※タイムアウトはしない(innodb_lock_wait_timeoutパラメータは機能しない)※3の部分で不具合があり、4.1.11で解決予定
トランザクション1

トランザクション2

1

START TRANSACTION;

START TRANSACTION;

2

UPDATE tbl1 SET
col1=300;

トランザクション3

100200tbl1(InnoDB)

トランザクション4

UPDATE tbl1 SET
col1=400; (行ロックによる待ち)3

FLUSH TABLES WITH
READ LOCK; (1段階目まで終了し、2段階目で待つ)

4

CREATE TABLE tbl2
(col1 INTEGER); (ロック待ち)

5
6.1

col1COMMIT;

6.2

UPDATE文の実行終了(未コミット)
FLUSH TABLES WITH
READ LOCK の実行終了

6.3
7© 2005 Sony Global Solutions Inc.

COMMIT; (ロック待ち)バイナリログの不具合(5.1で解決予定)
 同一トランザクション内で、InnoDB表を更新した後にMyISAM表を更新すると、MyISAMへの更新結果が、バイナリログに即時反映(コミット時同期書込)されない。

1) START TRANSACTION;
2) InnoDB表を更新
3) MyISAM表を更新
4)--ここで全体バックアップ取得
5) COMMIT;

1)

100

1000

200

2000

tbl1(InnoDB)

tbl2(MyISAM)
バックアップデータの中身

3)

3000

100

3000

2000

200

2000

tbl2(MyISAM)

tbl1(InnoDB)

tbl2(MyISAM)

4)
5)

300
200

tbl1(InnoDB)© 2005 Sony Global Solutions Inc.

4)以降のバイナリログの中身

tbl1(InnoDB) : 100 → 300
tbl2(MyISAM) : 1000→3000

まとめ(1)
 バックアップの手段 コールドバックアップ、オンラインバックアップ、増分バックアップが可能 オンラインバックアップには様々な方法がある

 ロールフォワードリカバリ
 バイナリログを有効にすることで可能(デフォルトでは無効)
 4.1以降では文字コードの指定に注意 ファイル配置
 バイナリログとそれ以外でディスクを分けることを検討すると良い アプリケーション処理
 同一トランザクション内でInnoDB表とMyISAM表を同時に更新することは避ける© 2005 Sony Global Solutions Inc.

まとめ(2) オンラインバックアップの手法比較
バックアップ方法

対象ストレージエンジン

特徴、特記事項

mysqldump

全て(条件付)▲ バックアップに時間がかかる▲ リストアに時間がかかる▲ InnoDB以外は、バックアップ中に共有ロックをかけないと一貫性を保証できない○ ロックをかける期間は実質皆無に近い※ バグのため、バージョン4.1.11以降を推奨

FLUSH TABLES
WITH READ LOCK+OSコマンドでコピー

全て▲ 即時バックアップ機能がほぼ前提○ バックアップ取得時間が短い○ ロックをかける期間は実質皆無に近い※ バグのため、バージョン4.1.11以降を推奨

InnoDB Hot Backup(参考)

原則InnoDBのみ▲ バックアップに時間がかかる▲ 有料▲ frmファイルのバックアップは別途行う必要がある○ ロックはかけない

非同期レプリケーション
(参考)

全て

▲ スレーブ機が別途必要→コスト増につながる○ ロックはかけない© 2005 Sony Global Solutions Inc.

参考資料
 翔泳社 DB Magazine 「本気で取り組むMySQL入門」
2005年6月号、7月号 (バックアップ・リカバリ前編、後編)
 前編：コールドバックアップ、バイナリログ、増分バックアップ
 後編：オンラインバックアップ

 MySQLのマニュアル
 The mysqldump Database Backup Program¾ http://dev.mysql.com/doc/mysql/en/mysqldump.html¾ 日本語の情報はバージョンが古いので注意 InnoDB Hot Backup Online Manual¾ http://www.innodb.com/manual.php

 オライリー「実践ハイパフォーマンスMySQL」
 レプリケーションの解説が深い。

 MySQLメーリングリスト「クラッシュからのリカバリ」(翻訳記事)
 http://www.mysql.gr.jp/mysqlml/mysql/msg/10758© 2005 Sony Global Solutions Inc.