文書の更新履歴
更新日：2004年11月30日警告：MySQL 4.0.22および4.1.7の重大なバグにより、innobackup Perlスクリプトが2回実行されmysqldサーバ全体のフリーズを引き起こすことがあります。バグは、FLUSH TABLES WITH READ LOCKにより発生していました。純粋なibbackupには影響しません。このバグは、innobackupバージョン1.1.0で修正されました。詳細については、セクション 7.4およびセクション9.2を参照してください。
更新日：2004年10月7日複数のテーブルスペースが使用されている場合に1つのテーブルを復元する方法についてセクション6.3を追加しました。
更新日：2004年10月5日innobackupに影響する既知のMySQLのバグについてセクション7.4を追加しました。
更新日：2004年9月28日バックアップの実行時に長時間におよぶSELECTなどのSQLクエリが存在せず、MyISAMテーブルのサイズが小さい場合には、innobackup Perlスクリプトしか十分に稼動しないことを注としてセクション5に追加しました。また、SELECTのみを指定したクエリはFLUSH TABLES WITH READ LOCKをブロックする点も注に記載しました。
更新日：2004年8月20日innobackup 1.0.0がLinux上で安定であることを公表しました。
InnoDBホット バックアップ、つまりibbackupは、ロックを設定したり、通常のデータベース処理を妨げたりすることなく、MySQLの配下で稼動中のInnoDBデータベースのバックアップを可能にするツールです。厳密にその時点で取得したデータベースのコピーであるかのように、一貫したコピーを入手できます。また、InnoDBホット バックアップは、InnoDBテーブルでMySQLのレプリケーションを使用している場合に新しいスレーブを設定する理想的な手段も提供します。
バックアップを実行する基本コマンドは、ibbackup my.cnf my2.cnfです。ibbackupの原理は、my.cnfファイルからibdataとib_logfileの場所に関する情報を読み取り、my2.cnfファイル内の指定された場所にそれらのバックアップを作成するというものです。
.cnfファイルはMySQLオプション ファイルで、次のパラメータ値を含んでいる必要があります。
datadir=
innodb_data_home_dir=
innodb_data_file_path=
innodb_log_group_home_dir=
innodb_log_files_in_group=
innodb_log_file_size=
ファイルのその他の内容は無視されます。ibbackupはディレクトリ パスのデフォルトを認識しないため、絶対パスを指定する必要があります。データ ファイル数とそれらのサイズの指定は、my.cnfおよびmy2.cnfに合致していなければなりません。最後のデータ ファイルがmy.cnfに自動拡張（auto-extending）として指定された場合は、my2.cnf内のそのファイルも自動拡張として指定する必要があります。
ログファイルの数とそのサイズは明示的に指定する必要がありますが、my.cnfとmy2.cnfでそれらの数とサイズが一致している必要はありません。
例：my.cnfには次の内容が含まれるものとします。
[mysqld]
datadir = /home/heikki/data
innodb_data_home_dir = /home/heikki/data
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /home/heikki/data
set-variable = innodb_log_files_in_group=2
set-variable = innodb_log_file_size=20M
バックアップをディレクトリ/home/heikki/backupに作成します。作成後、my2.cnfは次のようになります。
datadir = /home/heikki/backup
innodb_data_home_dir = /home/heikki/backup
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /home/heikki/backup
set-variable = innodb_log_files_in_group=2
set-variable = innodb_log_file_size=20M
ibbackupはどのファイルも一切上書きしない点に注意してください。バックアップ ディレクトリでは、そこに新しいファイルを作成しそれらを書き込めるように、古いバックアップを消去する必要があります。
コールibbackup --helpは、用法について必要な事柄をすべて表示します。
$ ibbackup --help
InnoDB Hot Backup version 2.0-beta3; Copyright 2003 Innobase Oy
License A00001 is granted to Innobase Oy
Type ibbackup --license for detailed license terms, --help for help
Usage:
ibbackup [--sleep ms] [--suspend-at-end] [--compress [level]]
[--include regexp] my.cnf backup-my.cnf
or
ibbackup --apply-log [--use-memory mb] [--uncompress] backup-my.cnf
or
ibbackup --restore [--use-memory mb] [--uncompress] backup-my.cnf
The first command line call above reads the data file and log file
information from my.cnf, and stores the backup data files and a backup
log file (named 'ibbackup_logfile') in the directories specified in the
backup-my.cnf file.
The .cnf files must contain explicit values of (ibbackup is not aware of defaults):
datadir=...
innodb_data_home_dir=…
innodb_data_file_path=…
innodb_log_group_home_dir=…
set-variable = innodb_log_files_in_group=...
set-variable = innodb_log_file_size=...
If --apply-log is specified, then the program prepares a backup for
starting mysql server on the backup. It applies the log records in
'ibbackup_logfile' to the data files, and creates new log files as
specified in backup-my.cnf.
If --include regexp is specified, only those per-table data files which
match the given regular expression are included in the backup.
For each table with per-table data file a string of the form
db_name.table_name is checked against the regular expression.
If the regular expression matches the complete string db_name.table_name,
the table is included in the backup. The regular expression should be of
the POSIX 1003.2 "extended" form. Example: expression 'sales\.den.*'
matches all tables starting with "den" in database "sales".
Note that on Unix the regular expression should be placed in single
quotes to prevent interpretation by the shell. This feature
is implemented with Henry Spencer's regular expression library.
--restore is an obsolete synonym for --apply-log. The use of --restore
is deprecated, because it may be dropped in the future.
--sleep ms instructs the program to sleep ms milliseconds after each 1 MB
of copied data. You can use this parameter to tune the additional disk i/o
load the backup program causes on the computer. ms must be < 1000000.
The default for ms is 0.
--suspend-at-end makes ibbackup to behave like this: when the backup
procedure is close to ending, ibbackup creates a file called
'ibbackup_suspended' to the log group home dir specified in backup-my.cnf
and waits until the user deletes that file 'ibbackup_suspended'.
You can use this option if you want to write a script which locks
and backs up your MyISAM tables at the end of ibbackup. In that way you
get a consistent snapshot of both InnoDB and MyISAM tables.
--use-memory mb is relevant only when --apply-log is specified.
It tells ibbackup that it can use mb megabytes of memory in recovery.
The default is 100 MB.
--compress instructs the program to compress the backup copies of data
files. Compressed data files are named by adding suffix '.ibz' to the
file name. Compression level can be specified as an optional argument
following --compress option. Compression level is an integer
between 0 and 9: 1 gives fastest compression, 9 gives best compression,
and 0 means no compression. If compression level is not given,
the default level 1 (fastest compression) is used.
--uncompress is relevant only when --apply-log is specified.
It tells ibbackup to recover data files from compressed copies.
Compressed data files are named with suffix '.ibz'.
The backup program does NOT make a backup of the .frm files of the tables,
and it does not make backups of MyISAM tables. You should make backups
of the .frm files with the Unix 'tar' or the Windows WinZip or an equivalent
tool both BEFORE and AFTER ibbackup finishes its work, and also store the
MySQL binlog segment which is generated between the moment you copy the .frm
files to a backup and the moment ibbackup finishes its work. For extra
safety, also use
mysqldump -l -d yourdatabasename
to dump the table CREATE statements in a human-readable form before
ibbackup finishes its work.
From the binlog segment you see if any of the .frm files changed between the
moment you took a .frm files backup and the moment ibbackup finished
its work.
Please send order inquiries and bug reports to Heikki.Tuuri@innodb.com.
ibbackupはInnoDBテーブルとインデックスのバックアップを作成します。ただし、.frmファイル、MyISAMテーブル、またはMyISAMインデックスはバックアップにはコピーしません。完全なバックアップの作成方法の詳細については、セクション2.3を参照してください。
2.1 例：未圧縮のバックアップの作成
バックアップの場所を定義する/home/pekka/.backup-my.cnfというオプション ファイルが用意されています（前のセクションで説明したとおり）。オプション ファイル/home/pekka/.my.cnfは、バックアップするMySQLインストレーションを定義します。これらのオプション ファイルを指定してibbackupを実行します。
$ ibbackup /home/pekka/.my.cnf /home/pekka/.backup-my.cnf
InnoDB Hot Backup version 2.0-beta3; Copyright 2003 Innobase Oy
License A00001 is granted to Innobase Oy
Type ibbackup --license for detailed license terms, --help for help
Contents of /home/pekka/.my.cnf:
innodb_data_home_dir got value /home/pekka/sqldata/simple
innodb_data_file_path got value ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
datadir got value /home/pekka/sqldata/simple
innodb_log_group_home_dir got value /home/pekka/sqldata/simple
innodb_log_files_in_group got value 3
innodb_log_file_size got value 10485760
Contents of /home/pekka/.backup-my.cnf:
innodb_data_home_dir got value /home/pekka/sqldata-backups
innodb_data_file_path got value ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
datadir got value /home/pekka/sqldata-backups
innodb_log_group_home_dir got value /home/pekka/sqldata-backups
innodb_log_files_in_group got value 3
innodb_log_file_size got value 10485760
ibbackup: Found checkpoint at lsn 0 268331310
ibbackup: Starting log scan from lsn 0 268331008
040121 17:35:46 ibbackup: Copying log...
040121 17:35:47 ibbackup: Switching to log file 2, lsn 0 272584704
040121 17:35:49 ibbackup: Log copied, lsn 0 282171935
ibbackup: We wait 10 seconds before starting copying the data files...
040121 17:35:59 ibbackup: Copying /home/pekka/sqldata/simple/ibdata1
040121 17:35:59 ibbackup: Switching to log file 0, lsn 0 283068416
040121 17:36:42 ibbackup: Copying /home/pekka/sqldata/simple/ibdata2
040121 17:38:19 ibbackup: Copying /home/pekka/sqldata/simple/ibdata3
ibbackup: A copied database page was modified at 0 284263243
ibbackup: Scanned log up to lsn 0 291666654
ibbackup: Was able to parse the log up to lsn 0 291666654
ibbackup: Maximum page number for a log record 3127
040121 17:42:15 ibbackup: Full backup completed!
現在、バックアップ ディレクトリにはバックアップ ログとInnoDBデータ ファイルのコピーが含まれています。
$ ls -lh /home/pekka/sqldata-backups
total 824M
-rw-r----- 1 pekka dev 22M Jan 21 17:42 ibbackup_logfile
-rw-r----- 1 pekka dev 100M Jan 21 17:36 ibdata1
-rw-r----- 1 pekka dev 200M Jan 21 17:38 ibdata2
-rw-r----- 1 pekka dev 500M Jan 21 17:42 ibdata3
2.2 例：圧縮済みバックアップの作成
多くのユーザは、バックアップ データ ファイルを圧縮してディスク スペースを節約したいと考えています。--compressオプションを指定すると、ibbackupはバックアップ データ ファイルを圧縮します。
$ ibbackup --compress /home/pekka/.my.cnf /home/pekka/.backup-my.c
InnoDB Hot Backup version 2.0-beta3; Copyright 2003 Innobase Oy
License A00001 is granted to Innobase Oy
Type ibbackup --license for detailed license terms, --help for help
Contents of /home/pekka/.my.cnf:
innodb_data_home_dir got value /home/pekka/sqldata/simple
innodb_data_file_path got value ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
datadir got value /home/pekka/sqldata/simple
innodb_log_group_home_dir got value /home/pekka/sqldata/simple
innodb_log_files_in_group got value 3
innodb_log_file_size got value 10485760
Contents of /home/pekka/.backup-my.cnf:
innodb_data_home_dir got value /home/pekka/sqldata-backups
innodb_data_file_path got value ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
datadir got value /home/pekka/sqldata-backups
innodb_log_group_home_dir got value /home/pekka/sqldata-backups
innodb_log_files_in_group got value 3
innodb_log_file_size got value 10485760
ibbackup: Found checkpoint at lsn 0 411259884
ibbackup: Starting log scan from lsn 0 411259392
040121 18:35:03 ibbackup: Copying log...
040121 18:35:03 ibbackup: Log copied, lsn 0 411393274
ibbackup: We wait 10 seconds before starting copying the data files...
040121 18:35:13 ibbackup: Copying /home/pekka/sqldata/simple/ibdata1
040121 18:36:00 ibbackup: Copying /home/pekka/sqldata/simple/ibdata2
040121 18:37:21 ibbackup: Copying /home/pekka/sqldata/simple/ibdata3
040121 18:38:10 ibbackup: Switching to log file 1, lsn 0 419356672
ibbackup: A copied database page was modified at 0 415285076
ibbackup: Scanned log up to lsn 0 423500074
ibbackup: Was able to parse the log up to lsn 0 423500074
ibbackup: Maximum page number for a log record 9407
ibbackup: Compressed 800 MB of data files to 25 MB (compression 96%).
040121 18:40:24 ibbackup: Full backup completed!
バックアップ ディレクトリは次のように表示されます。圧縮済みのデータ ファイルにはサフィックス.ibzが付いています。通常は、70%以上の圧縮率で圧縮されます。
$ ls -lh /home/pekka/sqldata-backups
total 38M
-rw-r----- 1 pekka dev 12M Jan 21 18:40 ibbackup_logfile
-rw-r----- 1 pekka dev 14M Jan 21 18:35 ibdata1.ibz
-rw-r----- 1 pekka dev 8.8M Jan 21 18:37 ibdata2.ibz
-rw-r----- 1 pekka dev 2.2M Jan 21 18:40 ibdata3.ibz
2.3 MyISAMおよびInnoDBの両方のテーブルのシャープ バックアップの作成
新たなPerlスクリプトinnobackupでは、ここで取り上げる手順を自動化しています。セクション9を参照してください。
--suspend-at-endオプション（ibbackup-1.05に組み込まれた）を使用して、MyISAMとInnoDBの両方のテーブルのシャープ バックアップを取得できます。これは、ibbackupの実行が終わりに近づいたらすべてのMyISAMテーブルをロックおよび フラッシュしてから、MyISAMテーブルをバックアップにコピーする必要があるという発想に基づいています。ibbackupに よって作成されたバックアップは、実行が終了しMyISAMテーブルをロックして停止させた時刻に対応付けられるため、同 時点のMyISAMテーブルのスナップショットを取得できます。アルゴリズムは次のとおりです。
・ibbackup --suspend-at-end …;
・スクリプトが通知すると、ファイルibbackup_suspendedが現れます。
1.FLUSH TABLES WITH READ LOCK;
2.すべての.frmファイルとMyISAMテーブルをデータベース ディレクトリからバックアップの場所へコピーします。
3.ファイルibbackup_suspendedを削除してibbackupの実行を再開します。
4.UNLOCK TABLES;
現在手元にあるバックアップは、別々の時刻に異なるデータベースをコピーしたため、InnoDBの特定のログ シーケンス番号には対応付けられていません。また、ibbackupは、バックアップの実行時に累積したInnoDBログをファイルibbackup_logfileにコピーします。そのファイルをバックアップされたデータ ファイルに適用することで、データ ファイル内のすべてのページをInnoDBログの同一のログ シーケンス番号に対応付けるようにロール フォワードできます。
ログを適用するためのオプションは--apply-logです。2.0より前のバージョンでは、このオプションは--restoreと呼ばれていましたが、データ ファイルを本来のコピー元へコピーし直すわけではないため、restoreという語は誤解を招く恐れがありました。そのため、ibbackupバージョン2.0の--restoreの代わりにオプション--apply-logが追加され、オプション名--restoreは廃止されました。新しい名前は、操作の内容をより的確に示しています。
この段階で、データ ファイルに対応付ける新しいib_logfilesも作成します。
3.1 例：ログのバックアップへの適用
ログをバックアップに適用する前のバックアップ ディレクトリは次のように表示されます。
$ ls -lh /home/pekka/sqldata-backups
total 814M
-rw-r----- 1 pekka dev 13M Jan 21 20:46 ibbackup_logfile
-rw-r----- 1 pekka dev 100M Jan 21 20:40 ibdata1
-rw-r----- 1 pekka dev 200M Jan 21 20:42 ibdata2
-rw-r----- 1 pekka dev 500M Jan 21 20:46 ibdata3
ibbackupを実行して、データ ファイルが同一のログ シーケンス番号に対応付けられるようにそれらをロール フォワードします。
$ ibbackup --apply-log /home/pekka/.backup-my.cnf
InnoDB Hot Backup version 2.0-beta3; Copyright 2003 Innobase Oy
License A00001 is granted to Innobase Oy
Type ibbackup --license for detailed license terms, --help for help
Contents of /home/pekka/.backup-my.cnf:
innodb_data_home_dir got value /home/pekka/sqldata-backups
innodb_data_file_path got value ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
datadir got value /home/pekka/sqldata-backups
innodb_log_group_home_dir got value /home/pekka/sqldata-backups
innodb_log_files_in_group got value 3
innodb_log_file_size got value 10485760
040121 22:57:16 ibbackup: ibbackup_logfile's creation parameters:
ibbackup: start lsn 0 445538304, end lsn 0 459128394,
ibbackup: start checkpoint 0 445538409
InnoDB: Doing recovery: scanned up to log sequence number 0 450781184
InnoDB: Doing recovery: scanned up to log sequence number 0 456024064
InnoDB: Doing recovery: scanned up to log sequence number 0 459128394
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68
69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94
95 96 97 98 99 Setting log file size to 0 10485760
Setting log file size to 0 10485760
Setting log file size to 0 10485760
ibbackup: We were able to parse ibbackup_logfile up to
ibbackup: lsn 0 459128394
ibbackup: Last MySQL binlog file position 0 204358527, file name ./binlog.000002
ibbackup: The first data file is '/home/pekka/sqldata-backups/ibdata1'
ibbackup: and the new created log files are at '/home/pekka/sqldata-backups/'
040121 22:57:37 ibbackup: Full backup prepared for recovery successfully!
ログを適用した後のバックアップ ディレクトリの内容は次のようになります。ibbackupは、InnoDBログ ファイル（ib_logfile*）を作成し、ログ レコードをInnoDBデータ ファイル（ibdata*）に適用しました。
$ ls -lh /home/pekka/sqldata-backups
total 844M
-rw-r----- 1 pekka dev 13M Jan 21 20:46 ibbackup_logfile
-rw-r----- 1 pekka dev 100M Jan 21 22:57 ibdata1
-rw-r----- 1 pekka dev 200M Jan 21 22:57 ibdata2
-rw-r----- 1 pekka dev 500M Jan 21 20:46 ibdata3
-rw-r----- 1 pekka dev 10M Jan 21 22:57 ib_logfile0
-rw-r----- 1 pekka dev 10M Jan 21 22:57 ib_logfile1
-rw-r----- 1 pekka dev 10M Jan 21 22:57 ib_logfile2
3.2 例：ログの圧縮済みバックアップへの適用
バックアップが圧縮されており、ログをそのバックアップに適用する場合は、ibbackupに--uncompressオプションを指定する必要があります。
$ ls -lh /home/pekka/sqldata-backups
total 38M
-rw-r----- 1 pekka dev 12M Jan 21 18:40 ibbackup_logfile
-rw-r----- 1 pekka dev 14M Jan 21 18:35 ibdata1.ibz
-rw-r----- 1 pekka dev 8.8M Jan 21 18:37 ibdata2.ibz
-rw-r----- 1 pekka dev 2.2M Jan 21 18:40 ibdata3.ibz
$ ibbackup --apply-log --uncompress /home/pekka/.backup-my.cnf
InnoDB Hot Backup version 2.0-beta3; Copyright 2003 Innobase Oy
License A00001 is granted to Innobase Oy
Type ibbackup --license for detailed license terms, --help for help
Contents of /home/pekka/.backup-my.cnf:
innodb_data_home_dir got value /home/pekka/sqldata-backups
innodb_data_file_path got value ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
datadir got value /home/pekka/sqldata-backups
innodb_log_group_home_dir got value /home/pekka/sqldata-backups
innodb_log_files_in_group got value 3
innodb_log_file_size got value 10485760
ibbackup: Uncompressing data file '/home/pekka/sqldata-backups/ibdata1.ibz'
ibbackup: Progress in MB: 100
ibbackup: Uncompressing data file '/home/pekka/sqldata-backups/ibdata2.ibz'
ibbackup: Progress in MB: 100 200
ibbackup: Uncompressing data file '/home/pekka/sqldata-backups/ibdata3.ibz'
ibbackup: Progress in MB: 100 200 300 400 500
040121 23:29:02 ibbackup: ibbackup_logfile's creation parameters:
ibbackup: start lsn 0 411259392, end lsn 0 423500074,
ibbackup: start checkpoint 0 411259884
InnoDB: Doing recovery: scanned up to log sequence number 0 416502272
InnoDB: Doing recovery: scanned up to log sequence number 0 421745152
InnoDB: Doing recovery: scanned up to log sequence number 0 423500074
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
98 99 Setting log file size to 0 10485760
Setting log file size to 0 10485760
Setting log file size to 0 10485760
ibbackup: We were able to parse ibbackup_logfile up to
ibbackup: lsn 0 423500074
ibbackup: Last MySQL binlog file position 0 190482265, file name ./binlog.000002
ibbackup: The first data file is '/home/pekka/sqldata-backups/ibdata1'
ibbackup: and the new created log files are at '/home/pekka/sqldata-backups/'
040121 23:29:40 ibbackup: Full backup prepared for recovery successfully!
正常にログをバックアップに適用した後のバックアップ ディレクトリの内容は次のように表示されます。上記のibbackup出力は、データ ファイルがログ シーケンス番号（lsn）423500074にロール フォワードされたことを示しています。ibbackupは、バックアップ内のオリジナルのファイル（圧縮済みのデータ ファイルとibbackupログ ファイル）は一切変更していないことがわかります。つまり、何らかの理由（例えば、ディスク スペースの不足）でログの適用（apply-log）操作が失敗しても何も失われません。問題を修正すれば、支障なくログの適用操作を再試行できます。
$ ls -lh /home/pekka/sqldata-backups
total 869M
-rw-r----- 1 pekka dev 12M Jan 21 18:40 ibbackup_logfile
-rw-r----- 1 pekka dev 100M Jan 21 23:29 ibdata1
-rw-r----- 1 pekka dev 14M Jan 21 18:35 ibdata1.ibz
-rw-r----- 1 pekka dev 200M Jan 21 23:29 ibdata2
-rw-r----- 1 pekka dev 8.8M Jan 21 18:37 ibdata2.ibz
-rw-r----- 1 pekka dev 500M Jan 21 23:29 ibdata3
-rw-r----- 1 pekka dev 2.2M Jan 21 18:40 ibdata3.ibz
-rw-r----- 1 pekka dev 10M Jan 21 23:29 ib_logfile0
-rw-r----- 1 pekka dev 10M Jan 21 23:29 ib_logfile1
-rw-r----- 1 pekka dev 10M Jan 21 23:29 ib_logfile2
3.3 リストアされたバックアップでのmysqldの起動
ログを適用し新しいib_logfileを作成すれば、バックアップ データベースでmysqldを起動できます。
mysqldを起動する前のバックアップ データベース ディレクトリは次のように表示されます。バックアップ ディレクトリにはデータベース サブディレクトリmysql、test、test115が含まれていることがわかります。これらはibbackupによって作成されるわけではなく、ユーザによって手動で、またはinnobackupスクリプトによって自動的に作成されます（セクション9を参照）。
$ ls -lh /home/pekka/sqldata-backups
total 872M
-rw-r----- 1 pekka dev 41M Jan 22 15:33 ibbackup_logfile
-rw-r----- 1 pekka dev 100M Jan 22 15:38 ibdata1
-rw-r----- 1 pekka dev 200M Jan 22 15:38 ibdata2
-rw-r----- 1 pekka dev 500M Jan 22 15:32 ibdata3
-rw-r----- 1 pekka dev 10M Jan 22 15:40 ib_logfile0
-rw-r----- 1 pekka dev 10M Jan 22 15:38 ib_logfile1
-rw-r----- 1 pekka dev 10M Jan 22 15:38 ib_logfile2
drwxr-xr-x 2 pekka dev 4.0k Jan 22 15:33 mysql
drwxr-xr-x 2 pekka dev 4.0k Jan 22 15:33 test
drwxr-xr-x 2 pekka dev 4.0k Jan 22 15:33 test115
バックアップ データベースでmysqldを起動します。
$ mysqld --defaults-file=/home/pekka/.backup-my.cnf
040122 15:41:57 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040122 15:41:57 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 646218252.
InnoDB: Doing recovery: scanned up to log sequence number 0 646218252
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 18 row operations to undo
InnoDB: Trx id counter is 0 239872
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx with id 0 239533, 16 rows to undo
InnoDB: Rolling back of trx id 0 239533 completed
InnoDB: Rolling back trx with id 0 239532, 2 rows to undo
InnoDB: Rolling back of trx id 0 239532 completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Last MySQL binlog file position 0 27183537, file name ./binlog.000005
040122 15:41:57 InnoDB: Flushing modified pages from the buffer pool...
040122 15:41:59 InnoDB: Started; log sequence number 0 646218252
040122 15:41:59 mysql.user table is not updated to new password format;
Disabling new password usage until mysql_fix_privilege_tables is run
mysqld: ready for connections.
現在、mysqldはリストアされたバックアップ データベースで稼動中で、いつでもクライアントにサービスを提供できます。
4.1 ホット バックアップからのポイントインタイム リカバリ
InnoDBは、トランザクションのコミット時にbinlogの位置情報だけをテーブルスペースに格納します。InnoDBに現在のbinlogの位置を認識させるには、binlogが有効になっている状態で少なくとも1つのトランザクションを実行する必要があります。バックアップでibbackup --apply-logを実行すると、ibbackupバージョン1.03以上はバックアップが認識している最新のMySQL binlogの位置を出力します。また、--apply-logの後にバックアップ上でmysqldを起動したときも出力されます。
$ mysqld --defaults-file=/home/pekka/.backup-my.cnf
040122 15:41:57 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
...
InnoDB: Last MySQL binlog file position 0 27183537, file name ./binlog.000005
...
mysqld: ready for connections.
MySQLのバージョンは3.23.48以上または4.0.2以上でなければなりません。
出力された位置は、InnoDBホット バックアップがデータ ファイルのコピーを終了した時点からのMySQL binlogのバイト位置です。これに基づき、その位置から始まるbinlogファイルをリストアされたデータベースに適用できます。
$ mysqlbinlog --position=27183537 /home/pekka/sqldata-backups/binlog.000005 | mysql
データベースを特定の時点に戻す場合は、mysqlbinlogの出力を直接mysqlにパイピングする代わりに、出力ファイルへダイレクトできます。出力ファイルには、binlog内のすべてのSQLステートメントのタイムスタンプが含まれます。次のように、エディタを使用して出力ファイルの終わりの部分を削除し、その出力ファイルをmysqlへリダイレクトします。
$ mysql < youroutputfile
4.2 レプリケーション内のホット バックアップからの新しいスレーブの設定
MySQLレプリケーションを使用してInnoDBテーブルを複製している場合は、InnoDBホット バックアップを使用して、マスターを停止せずにスレーブ データベースを設定できます。これは、リストアされた ホット バックアップを新しいスレーブ データベースにすることができるからです。
1. バックアップを選択し、ibbackup --apply-logを使用してそれをリストアします。リストアされたバックアップとログ ファイルを新しいスレーブの適切な場所へ置きます。
2. 新しいスレーブのmy.cnfファイルを編集し、skip-slave-startを[mysqld]セクションに追加します。
3. 新しいスレーブmysqldを起動します（バージョン3.23.48以上または4.0.2以上）。バックアップが認識している最新のMySQL binlogの位置が出力されます。
...
InnoDB: Last MySQL binlog file position 0 128760128, file name ./hundin-bin.006
...
InnoDBはトランザクションのコミット時にbinlogの位置情報だけをテーブルスペースに格納する点に注意してください。
InnoDBに現在のbinlogの位置を認識させるには、binlogが有効な状態で少なくとも1つのトランザクションを実行する必要があります。
4. スレーブでCHANGE MASTER SQLコマンドを使用して、適切に初期設定します。例：
CHANGE MASTER TO
MASTER_LOG_FILE='hundin-bin.006',
MASTER_LOG_POS=128760128;
5. SLAVE START SQLコマンドを使って、新しいスレーブ内でレプリケーションを開始します。
6. スレーブのmy.cnfファイルからskip-slave-start行を削除します。
4.3 レプリケーション内のマスター データベースのリストア
マスター データベースが破損したものとします。
1. マスター データベースのバックアップを使用し、ibbackup --apply-log yourbackupmy.cnfを実行して、ibdataおよびib_logfileファイルを適切な場所に配置します。その後、.frmファイルを適切な場所に配置します。.frmファイルのtarファイルがあることを前提に、次のコマンドを実行します。
cd mysqldatadir; tar xvf yourtarfile
2. マスターのmy.cnfファイルを編集して、その中のlog-binをコメント化し、スレーブがマスターをリカバリするために必要なbinlogを2回受け取らないようにします。
3. binlogをマスターにパイピングする際には、一時的にスレーブ内のレプリケーションを停止する必要があります。スレーブで次のように実行します。
mysql> STOP SLAVE;
4. リストアされたバックアップ上でマスターに対してmysqldを起動します。
$ mysqld
...
InnoDB: Doing recovery: scanned up to log sequence number 0 64300044
InnoDB: Last MySQL binlog file position 0 5585832, file name
./omnibook-bin.002
...
InnoDBは、binlogファイルと候補となるリカバリ先を出力しました。
5. 次に、残りのbinlogファイルをリストアされたバックアップにパイピングする必要があります。
$ mysqlbinlog --position=5585832 mysqldatadir/omnibook-bin.002 | mysql
$ mysqlbinlog /mysqldatadir/omnibook-bin.003 | mysql
6. これで、マスター データベースはリカバリされました。マスターを停止しmy.cnfを編集して、log-binをアンコメントします。
7. マスターを再起動します。
8. 再度、スレーブでレプリケーションを開始します。
mysql> START SLAVE;
SoftAgencyは株式会社ソフトエイジェンシーの登録商標です。