5.1 説明
警告：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を参照してください。
innobackupは、MyISAMおよびInnoDBの両方のテーブルの完全なバックアップを作成するための使い易いツールです。このツールはibbackupと組み合わせて使用され、innobackupの子プロセスとして実行されます。バックアップを作成する以外に、innobackupはバックアップがその上でMySQLサーバを起動し、バックアップ ディレクトリのデータ、インデックス、ログ ファイルを元の場所へコピーし直すことができるようにします。
重要：innobackup Perlスクリプトは、バックアップの実行の最後にコマンドFLUSH TABLES WITH READ LOCKを発行するため、純粋なオンライン バックアップ ツールではありません。innobackupは、次の場合にだけ効果を発揮します。
1. バックアップの実行時点で長時間におよぶSELECTなどのSQLクエリを実行していない場合
2. MyISAMテーブルのサイズが小さい場合
これらの場合、innobackup実行の最後のロック段階は短時間で済み（数秒程度）、mysqldの通常の処理を妨げることはほとんどありません。上記の2通りの状況が使用中のデータベース アプリケーションに当てはまらない場合は、ibbackupバイナリのみを使用してバックアップを作成します。
innobackup 1.1.0のソース コードはこのリンクからダウンロードできます。
innobackupはGNU GPLライセンス バージョン2（1991年6月）に基づいて公開されています。InnoDBホットバックアップのライセンスの購入者は、InnoDBホット バックアップの標準の商用ライセンスと同じライセンスでinnobackupを使用でき、GPLの制限は適用されません。
innobackupは、InnoDBテーブルのオンライン バックアップと、InnoDBテーブルのバックアップのbinlogと同じ場所に対応付けられたMyISAMテーブルのスナップショットを取得するために使用できるPerlスクリプトです。テーブルの.frmファイルもバックアップします。
innobackupを起動するコマンドラインの例：
$ perl innobackup --user=dba --password=xyz --compress /etc/my.cnf /var/lib/mysql/backups
または、オペレーティング システムにPerlインタープリタを検索させる場合：
$ innobackup --user=dba --password=xyz --compress /etc/my.cnf /var/lib/mysql/backups
指定した--userおよび--passwordは、mysqlクライアント プログラムとサーバとの接続に使用されます。このMySQLユーザには、FLUSH TABLES WITH READ LOCKを実行し、サーバのmysqlシステム データベースに対応するダミー マーカー テーブルibbackup_binlog_markerを作成するためのMySQLサーバにおける十分な権限が必要です（必要なMySQL権限の詳細については例5.5を参照してください）。バックアップの実行時に、innobackupは、前に指定したディレクトリ/var/lib/mysql/backupsの下に作成されるサブディレクトリにバックアップを置きます。バックアップ サブディレクトリには、バックアップを実行した日付とクロック時刻を組み合わせた名前が付けられます。
また、innobackupを稼動中のユーザとクーロン ジョブがmysqlを起動しMySQLデータベース ディレクトリからバックアップ ディレクトリへファイルをコピーする権限を持っていることを確認する必要があります。
スクリプトがバックアップの実行中にmysqlクライアント接続を開いたまま保持できるように、接続タイムアウトに十分な長さが指定されていることを確認してください。innobackupは、接続が30分以上アイドル状態になると必ずキープアライブ メッセージを送信して、mysqlクライアント接続を開いたまま保持しようとします。このタイムアウトは、innobackupスクリプトのmysql_keep_alive_timeoutパラメータの値を編集することで変更できます。
innobackupは、実行時に、最初にmysql SQLクライアントとMySQLサーバとの接続をテストします。その後、ibbackupをコールし、InnoDBタイプのテーブルのオンライン バックアップを取得します。この段階で、通常のデータベース処理を妨げることはありません。ibbackupの実行がほぼ完了すると、innobackupがSQLコマンドFLUSH TABLES WITH READ LOCKを実行し、その後、MyISAMテーブルと.frmファイルをバックアップ ディレクトリにコピーします。この時点で、長時間におよぶSELECTなどのクエリが実行されておらず、MyISAMテーブルのサイズが小さい場合、ロック段階は数秒あれば十分です。それ以外の場合は、InnoDBタイプのテーブルを含むデータベース全体をロックするのにかなり長い時間を要することがあります。この後、innobackupは、ibbackupの実行を完了しテーブルをアンロック（UNLOCK）します。
既知のバグと制限：
警告：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を参照してください。
バックアップ アルゴリズムには、既にわかっているが未解決のバグが1つあります。MySQLの4.1.2より前のバージョンでは、ロック段階でのCREATE TABLEまたはRENAME TABLEを阻止しません。そのため、稀に、新たに作成された空のテーブルの.frmファイルがバックアップのbinlogの位置に対応付けられないことがあります。
現在、innobackupはUNIX系のシステムでのみ動作し、Perl 5.005以上が必須となっています。
UTF-8キャラクタのPerl regexpのバグについては、セクション7.2も参照してください。
重要事項
大規模なデータベースの場合、バックアップの実行には長い時間を要することがあります。innobackupが正常に完了したことを常に確認する必要があります。これは、innobackupプロセスが出口コード0を返したかどうか調べるか、またはinnobackupがテキスト"innobackup completed OK!"を出力したかどうかを監視することで確認できます。
5.1.2 使用方法
$ perl innobackup --help
Usage:
innobackup [--sleep=MS] [--compress[=LEVEL]] [--include=REGEXP] [--user=NAME]
[--password=WORD] [--port=PORT] [--socket=SOCKET]
MY.CNF BACKUP-ROOT-DIR
innobackup --apply-log [--use-memory=MB] [--uncompress] MY.CNF BACKUP-DIR
innobackup --copy-back MY.CNF BACKUP-DIR
The first command line above makes a hot backup of a MySQL database.
It creates a backup directory (named by the current date and time)
in the given backup root directory. This command makes a complete
backup of all MyISAM and InnoDB tables and indexes in all databases.
The created backup contains .frm, .MYD, .MYI, and InnoDB data and log files.
The MY.CNF options file defines the location of the database.
This command connects to the MySQL server using mysql client program,
and runs ibbackup (InnoDB Hot Backup program) as a child process.
The command with --apply-log option prepares a backup for starting a MySQL
server on the backup. This command expands InnoDB data files as specified
in BACKUP-DIR/backup-my.cnf using BACKUP-DIR/ibbackup_logfile,
and creates new InnoDB log files as specified in BACKUP-DIR/backup-my.cnf.
The BACKUP-DIR should be a path name of a backup directory created by
innobackup. This command runs ibbackup as a child process, but it does not
connect to the database server.
The command with --copy-back option copies data, index, and log files
from backup directory back to their original locations.
The MY.CNF options file defines the original location of the database.
The BACKUP-DIR is a path name of a backup directory created by innobackup.
On success the exit code of innobackup process is 0. A non-zero exit code
indicates an error.
Options:
--help
Display this helpscreen and exit.
--version
Print version information and exit.
--apply-log
Prepare a backup for starting mysql server on the backup.Expand InnoDB data files as specified in backup-dir/backup-my.cnf, using backup-dir/ibbackup_logfile, and create new log files as specified in backup-dir/backup-my.cnf.
--copy-back
Copy data and index files from backup directory back to their original locations.
--use-memory=MB
This option is passed to the ibbackup child process.It tells ibbackup that it can use MB megabytes of memory in restoration.Try 'ibbackup --help' for more details on this option.
--sleep=MS
This option is passed to the ibbackup child process.It instructs the ibbackup 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 ibbackup program causes on the computer.Try 'ibbackup --help' for more details on this option.
--compress[=LEVEL]
This option is passed to the ibbackup child process.It instructs ibbackup to compress the backup copies of InnoDB data files. Compression level can be specified as an optional argument. 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 is used.Try 'ibbackup --help' for more details on this option.
--include=REGEXP
This option is passed to the ibbackup child process.It tells ibbackup to backup only those per-table data files which match the given regular expression. For each table with a 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. Try 'ibbackup --help' for more details on this option.
--uncompress
This option is passed to the ibbackup child process.It tells ibbackup to uncompress compressed InnoDB data files.Try 'ibbackup --help' for more details on this option.
--user=NAME
This option is passed to the mysql child process.It defines the user for database login if not current user.Try 'mysql --help' for more details on this option.
--password=WORD
This option is passed to the mysql child process.It defines the password to use when connecting to database.Try 'mysql --help' for more details on this option.
--port=PORT
This option is passed to the mysql child process.It defines the port to use when connecting to local database server with TCP/IP.Try 'mysql --help' for more details on this option.
--socket=SOCKET
This option is passed to the mysql child process.It defines the socket to use when connecting to local database server with UNIX domain socket.Try 'mysql --help' for more details on this option.
5.2 例：バックアップの作成
この例では、innobackupに2つの引数が指定されています。バックアップするMySQLインストレーションのオプション ファイルとバックアップ ルート ディレクトリです。最後のコマンドラインの引数である/home/pekka/script/backupsは、innobackupがバックアップ ディレクトリを作成するルート ディレクトリです。
$ perl innobackup /home/pekka/.my.cnf /home/pekka/script/backups
InnoDB Backup Utility v1.0-beta6; Copyright 2003 Innobase Oy
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
innobackup: Using mysql Ver 12.18 Distrib 4.0.11-gamma, for pc-linux (i686)
innobackup: Using InnoDB Hot Backup version 2.0-beta3
innobackup: Created backup directory /home/pekka/script/backups/2004-02-03_13-27-09
innobackup: Starting mysql with options: --unbuffered
innobackup: Connected to database with mysql child process (pid=10450)
innobackup: Connection to database server closed
innobackup: Starting ibbackup with command: ibbackup --suspend-at-end /home/pekka/
.my.cnf /home/pekka/script/backups/2004-02-03_13-27-09/backup-my.cnf
innobackup: Waiting for ibbackup to suspend
innobackup: Suspend file '/home/pekka/script/backups/2004-02-03_13-27-09/ibbackup_suspended'
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/script/backups/2004-02-03_13-27-09/backup-my.cnf:
innodb_data_home_dir got value /home/pekka/script/backups/2004-02-03_13-27-09
innodb_data_file_path got value ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
datadir got value /home/pekka/script/backups/2004-02-03_13-27-09
innodb_log_group_home_dir got value /home/pekka/script/backups/2004-02-03_13-27-09
innodb_log_files_in_group got value 3
innodb_log_file_size got value 10485760
ibbackup: Found checkpoint at lsn 0 649595444
ibbackup: Starting log scan from lsn 0 649595392
040203 13:27:13 ibbackup: Copying log...
040203 13:27:14 ibbackup: Switching to log file 2, lsn 0 649998336
040203 13:27:14 ibbackup: Log copied, lsn 0 654335006
ibbackup: We wait 10 seconds before starting copying the data files...
040203 13:27:24 ibbackup: Copying /home/pekka/sqldata/simple/ibdata1
040203 13:27:46 ibbackup: Switching to log file 0, lsn 0 660482048
040203 13:27:55 ibbackup: Copying /home/pekka/sqldata/simple/ibdata2
040203 13:28:56 ibbackup: Copying /home/pekka/sqldata/simple/ibdata3
040203 13:29:17 ibbackup: Switching to log file 1, lsn 0 670965760
040203 13:30:07 ibbackup: Switching to log file 2, lsn 0 681449472
ibbackup: You had specified the option --suspend-at-end
040203 13:31:31 ibbackup: Suspending the backup procedure to wait
ibbackup: until you delete the marker file /home/pekka/script/backups/2004-02-0
3_13-27-09/ibbackup_suspended
innobackup: Continuing after ibbackup has suspended
innobackup: Starting mysql with options: --unbuffered
innobackup: Connected to database with mysql child process (pid=10462)
innobackup: All tables locked and flushed to disk
innobackup: Starting to backup .frm, .MYD and .MYI files in
innobackup: subdirectories of '/home/pekka/sqldata/simple'
innobackup: Backing up files '/home/pekka/sqldata/simple/mysql/*.{frm,MYD,MYI}' (19 files)
innobackup: Backing up files '/home/pekka/sqldata/simple/test/*.{frm,MYD,MYI}' (22 files)
innobackup: Backing up files '/home/pekka/sqldata/simple/test115/*.{frm,MYD,MYI}' (57 files)
innobackup: Finished backing up .frm, .MYD and .MYI files
innobackup: Resuming ibbackup
040203 13:31:53 ibbackup: Suspension ends. Continuing the backup procedure.
040203 13:31:53 ibbackup: Copying of the last data file is close to ending...
ibbackup: We still once copy the latest flushed log to ibbackup_logfile.
ibbackup: A copied database page was modified at 0 662242440
ibbackup: Scanned log up to lsn 0 683781754
ibbackup: Was able to parse the log up to lsn 0 683781754
ibbackup: Maximum page number for a log record 9790
040203 13:31:53 ibbackup: Full backup completed!
innobackup: All tables unlocked
innobackup: Connection to database server closed
innobackup: Backup created in directory '/home/pekka/script/backups/2004-02-03_13-27-09'
innobackup: innobackup completed OK!
ここで、指定したBACKUP-ROOT-DIRの下にバックアップ ディレクトリがあることがわかります。新しいバックアップそれぞれのディレクトリに、バックアップの実行が開始された日付とクロック時刻（ローカル タイム ゾーン）を組み合わせた名前が付けられています。
$ ls -l /home/pekka/script/backups
total 16
drwxr-xr-x 2 pekka dev 4096 Jan 23 00:20 2004-01-23_00-20-54
drwxr-xr-x 5 pekka dev 4096 Jan 23 00:25 2004-01-23_00-21-17
drwxr-xr-x 5 pekka dev 4096 Feb 3 13:24 2004-01-29_16-43-01
drwxr-xr-x 5 pekka dev 4096 Feb 3 13:31 2004-02-03_13-27-09
バックアップ ディレクトリには、バックアップされたibdataファイルとibbackup_logfileが含まれます。そのサブディレクトリmysql、test、test115は、データベース ディレクトリのコピーで、.frm、.MYD、および.MYIファイルのコピーが含まれます。
$ ls -lh /home/pekka/script/backups/2004-02-03_13-27-09
total 834M
-rw-r--r-- 1 pekka dev 405 Feb 3 13:27 backup-my.cnf
-rw-r----- 1 pekka dev 33M Feb 3 13:31 ibbackup_logfile
-rw-r----- 1 pekka dev 100M Feb 3 13:27 ibdata1
-rw-r----- 1 pekka dev 200M Feb 3 13:28 ibdata2
-rw-r----- 1 pekka dev 500M Feb 3 13:31 ibdata3
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 mysql
-rw-r--r-- 1 pekka dev 0 Feb 3 13:31 mysql-stderr
-rw-r--r-- 1 pekka dev 426 Feb 3 13:31 mysql-stdout
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 test
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 test115
トラブルシューティングのヒント：innobackupは、mysql子プロセスの標準出力をmysql-stdoutファイルへ、さらにエラー出力をmysql-stderrファイルへリダイレクトします。innobackupが発行したすべてのSQLコマンドが正常に実行されると、mysql-stderrファイルは空になります。空でない場合は、mysqlプロセスで何かが正常に処理されなかったか、SQLコマンドが失敗したことを示しています。mysql-stderrを詳しく調べ、バックアップが失敗した理由を特定する必要があります
5.3 例：バックアップ上でのmysqldの起動
この例は、前の例の最後からの続きです。ここでは、ログ レコード（ibbackup_logfileファイル内）をInnoDBデータ ファイル（ibdata*）に適用することで、バックアップがその上でデータベース サーバを起動できるようにします。
$ innobackup --apply-log /home/pekka/.my.cnf /home/pekka/script/backups/2004-02-03_13-27-09
InnoDB Backup Utility v1.0-beta6; Copyright 2003 Innobase Oy
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
innobackup: Using InnoDB Hot Backup version 2.0-beta3
innobackup: Starting ibbackup with command: ibbackup --restore /home/pekka/script/backups/2
004-02-03_13-27-09/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/script/backups/2004-02-03_13-27-09/backup-my.cnf:
innodb_data_home_dir got value /home/pekka/script/backups/2004-02-03_13-27-09
innodb_data_file_path got value ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
datadir got value /home/pekka/script/backups/2004-02-03_13-27-09
innodb_log_group_home_dir got value /home/pekka/script/backups/2004-02-03_13-27-09
innodb_log_files_in_group got value 3
innodb_log_file_size got value 10485760
040203 14:24:56 ibbackup: ibbackup_logfile's creation parameters:
ibbackup: start lsn 0 649595392, end lsn 0 683781754,
ibbackup: start checkpoint 0 649595444
InnoDB: Doing recovery: scanned up to log sequence number 0 654838272
InnoDB: Doing recovery: scanned up to log sequence number 0 660081152
InnoDB: Doing recovery: scanned up to log sequence number 0 665324032
InnoDB: Doing recovery: scanned up to log sequence number 0 670566912
InnoDB: Doing recovery: scanned up to log sequence number 0 675809792
InnoDB: Doing recovery: scanned up to log sequence number 0 681052672
InnoDB: Doing recovery: scanned up to log sequence number 0 683781754
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 683781754
ibbackup: Last MySQL binlog file position 0 12438592, file name ./binlog.000008
ibbackup: The first data file is '/home/pekka/script/backups/2004-02-03_13-27-09/ibdata1'
ibbackup: and the new created log files are at '/home/pekka/script/backups/2004-02-03_13-27-09/'
040203 14:25:44 ibbackup: Full backup prepared for recovery successfully!
innobackup: innobackup completed OK!
正常にログをバックアップへ適用した後のバックアップ ディレクトリの内容は次のとおりです。上記のibbackup出力は、データ ファイルがログ シーケンス番号（lsn）683781754にロール フォワードされたことを示しています。
$ ls -lh /home/pekka/script/backups/2004-02-03_13-27-09
total 864M
-rw-r--r-- 1 pekka dev 405 Feb 3 13:27 backup-my.cnf
-rw-r----- 1 pekka dev 33M Feb 3 13:31 ibbackup_logfile
-rw-r----- 1 pekka dev 100M Feb 3 14:25 ibdata1
-rw-r----- 1 pekka dev 200M Feb 3 14:25 ibdata2
-rw-r----- 1 pekka dev 500M Feb 3 13:31 ibdata3
-rw-r----- 1 pekka dev 10M Feb 3 14:25 ib_logfile0
-rw-r----- 1 pekka dev 10M Feb 3 14:25 ib_logfile1
-rw-r----- 1 pekka dev 10M Feb 3 14:25 ib_logfile2
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 mysql
-rw-r--r-- 1 pekka dev 0 Feb 3 13:31 mysql-stderr
-rw-r--r-- 1 pekka dev 426 Feb 3 13:31 mysql-stdout
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 test
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 test115
これで、このバックアップ上でサーバを起動する準備がほぼ整いました。ただし、これを実行する前に、バックアップの有効なmy.cnfファイルを用意する必要があります。バックアップ ディレクトリのbackup-my.cnfは、ibbackupが必要とする6個のパラメータしか持っていないため、この用途には使用できません。backup-my.cnfファイルのこれらの6個のパラメータと、オリジナルのmy.cnfファイル（この例では、/home/pekka/.my.cnf）によって定義されたその他のパラメータをコピーしたmy.cnfファイルを作成する必要があります。オリジナルのファイルのコピーを作成し、backup-my.cnfに変更を加えます。
$ cat /home/pekka/.my.cnf /home/pekka/script/backups/2004-02-03_13-27-09/backup-my.cnf >＼
/home/pekka/script/backups/2004-02-03_13-27-09/my.cnf
これで、有効なmy.cnfファイル（/home/pekka/script/backups/2004-02-03_13-27-09/my.cnf）が用意されたため、バックアップ上でサーバを起動できます。
$ mysqld --defaults-file=/home/pekka/script/backups/2004-02-03_13-27-09/my.cnf
040203 15:26:53 Warning: Changed limits: max_connections: 200 table_cache: 407
InnoDB: The log file was created by ibbackup --restore at
InnoDB: ibbackup 040203 14:25:44
040203 15:26:53 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...
040203 15:26:54 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 683782156.
InnoDB: Doing recovery: scanned up to log sequence number 0 683782156
InnoDB: Last MySQL binlog file position 0 12438592, file name ./binlog.000008
040203 15:26:54 InnoDB: Flushing modified pages from the buffer pool...
040203 15:26:54 InnoDB: Started; log sequence number 0 683782156
TODO: make sure MySQL sets field->query_id right in prepare/execute
040203 15:26:54 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.
5.4 例：元の場所でのデータベースのリストア
ログ ファイルはバックアップに適用されています（/home/pekka/script/backups/2004-02-03_13-27-09）。ここでは、InnoDBおよびMyISAMインデックスと.frmファイルを元の場所（/home/pekka/.my.cnfファイルにより定義される）にコピーし直します。
$ ls -lh /home/pekka/script/backups/2004-02-03_13-27-09
total 864M
-rw-r--r-- 1 pekka dev 405 Feb 3 13:27 backup-my.cnf
-rw-rw---- 1 pekka dev 79 Feb 3 15:26 binlog.000001
-rw-rw---- 1 pekka dev 16 Feb 3 15:26 binlog.index
-rw-r----- 1 pekka dev 33M Feb 3 13:31 ibbackup_logfile
-rw-r----- 1 pekka dev 100M Feb 3 15:28 ibdata1
-rw-r----- 1 pekka dev 200M Feb 3 15:28 ibdata2
-rw-r----- 1 pekka dev 500M Feb 3 15:28 ibdata3
-rw-r----- 1 pekka dev 10M Feb 3 15:28 ib_logfile0
-rw-r----- 1 pekka dev 10M Feb 3 14:25 ib_logfile1
-rw-r----- 1 pekka dev 10M Feb 3 14:25 ib_logfile2
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 mysql
-rw-r--r-- 1 pekka dev 0 Feb 3 13:31 mysql-stderr
-rw-r--r-- 1 pekka dev 426 Feb 3 13:31 mysql-stdout
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 test
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 test115
$ innobackup --copy-back /home/pekka/.my.cnf ＼
/home/pekka/script/backups/2004-02-03_13-27-09
InnoDB Backup Utility v1.0-beta6; Copyright 2003 Innobase Oy
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
innobackup: Starting to copy InnoDB and MyISAM tables, indexes, and .frm
innobackup: files in '/home/pekka/script/backups/2004-02-03_13-27-09'
innobackup: back to original data directory '/home/pekka/sqldata/simple'
innobackup: Copying file '/home/pekka/script/backups/2004-02-03_13-27-09/ibdata1'
innobackup: Copying file '/home/pekka/script/backups/2004-02-03_13-27-09/ibdata2'
innobackup: Copying file '/home/pekka/script/backups/2004-02-03_13-27-09/ibdata3'
innobackup: Copying file '/home/pekka/script/backups/2004-02-03_13-27-09/ib_logfile0'
innobackup: Copying directory '/home/pekka/script/backups/2004-02-03_13-27-09/mysql'
innobackup: Copying directory '/home/pekka/script/backups/2004-02-03_13-27-09/test'
innobackup: Copying directory '/home/pekka/script/backups/2004-02-03_13-27-09/test115'
innobackup: Copying file '/home/pekka/script/backups/2004-02-03_13-27-09/ib_logfile1'
innobackup: Copying file '/home/pekka/script/backups/2004-02-03_13-27-09/ib_logfile2'
innobackup: Copying file '/home/pekka/script/backups/2004-02-03_13-27-09/binlog.000001'
innobackup: Copying file '/home/pekka/script/backups/2004-02-03_13-27-09/binlog.index'
innobackup: Finished copying back files.
innobackup: innobackup completed OK!
これで、オリジナルのデータベース ディレクトリがバックアップからリストアされたため、その上でサーバを起動できます。
$ ls -lh /home/pekka/sqldata/simple
total 831M
-rw-rw---- 1 pekka dev 79 Feb 3 15:26 binlog.000001
-rw-rw---- 1 pekka dev 16 Feb 3 15:26 binlog.index
-rw-r----- 1 pekka dev 100M Feb 3 15:28 ibdata1
-rw-r----- 1 pekka dev 200M Feb 3 15:28 ibdata2
-rw-r----- 1 pekka dev 500M Feb 3 15:28 ibdata3
-rw-r----- 1 pekka dev 10M Feb 3 15:28 ib_logfile0
-rw-r----- 1 pekka dev 10M Feb 3 14:25 ib_logfile1
-rw-r----- 1 pekka dev 10M Feb 3 14:25 ib_logfile2
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 mysql
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 test
drwxr-xr-x 2 pekka dev 4.0k Feb 3 13:31 test115
5.5 例：innobackupのMySQL権限の設定
innobackupは、バックアップの作成時に、SQLコマンドをMySQLサーバへ送ります。innobackupを実行するユーザに最小限必要なSQL権限は、すべてのデータベースとテーブルに対するRELOAD、mysqlデータベースのibbackup_binlog_markerテーブルに対するCREATE、INSERT、およびDROPです。次のように、ローカルホストから接続するユーザdbaにこれらの権限を設定できます。
$ mysql -u root
Welcome to the MySQL monitor. Commands end with ; or ＼g.
Your MySQL connection id is 19 to server version: 4.1.1-alpha-debug-log
Type 'help;' or '\h' for help. Type '＼c' to clear the buffer.
mysql> GRANT RELOAD on *.* to 'dba'@'localhost';
Query OK, 0 rows affected (0.10 sec)
mysql> GRANT CREATE, INSERT, DROP on mysql.ibbackup_binlog_marker to 'dba'@'localhost';
Query OK, 0 rows affected (0.06 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.15 sec)
複数テーブルスペース機能が有効な場合は、InnoDBテーブルの部分バックアップを作成できます。複数テーブルスペース機能を使うと、各InnoDBテーブルを、1つのテーブルのデータとインデックスだけを保持する個別のテーブルスペースに格納できます。単一テーブルのテーブルスペースは、テーブルのデータベース ディレクトリにあるtable_name.ibdという名前の1つの自動拡張データファイルから構成されます。複数テーブルスペース機能が有効になっていない場合、InnoDBテーブルは通常通り、my.cnfファイルのinnodb_data_file_pathおよびinnodb_data_home_dirパラメータによって定義されたシステム テーブルスペースに格納されます。
--includeオプションを指定すると、テーブル固有のデータファイルの一部を除外した部分バックアップを作成するようにibbackup（v2.0以上）に命令できます。部分バックアップには、システム テーブルスペースと、それらの中でincludeパターンに一致するテーブルに固有のデータファイルが含まれます。
テーブル固有のデータファイルを持つ各テーブルについて、db_name.table_name形式の文字列と--includeオプションに指定された正規表現が照合されます。正規表現が完全な文字列のdb_name.table_nameに一致すると、テーブルはバックアップに内包されます。正規表現は、常に、POSIX拡張形式です。UNIX系のシステムでは、シェル メタキャラクタの解釈を混乱させないように、正規表現を適切に引用符で囲む必要がある点に注意してください。この機能は、ヘンリー スペンサーの正規表現ライブラリを使って実装されています。
innobackup Perlスクリプトが部分バックアップの作成をサポートしているとは言え、部分バックアップからデータベースをリストアするときは十分に注意してください。innobackupは、バックアップに含まれていないテーブルの.frmファイルもコピーしてしまいます。innobackupに--includeオプションを指定した場合は、データベースをリストアする前に、バックアップに含まれていないテーブルの.frmファイルを削除する必要があります。
6.1 例：未圧縮の部分バックアップの作成
MySQLは、一部のInnoDBがそれぞれ独自のテーブルスペースを保持するように設定されています。ここでは、ibで始まる名前を持つtestデータベース内のInnoDBテーブルだけを含む部分バックアップを作成します。testデータベースのデータベース ディレクトリの内容は次に示すとおりです。ディレクトリにはデータベース内の各テーブル（alex1、alex2、alex3、blobt3、ibstest0、ibstest09、ibtest11a、ibtest11b、ibtest11c、およびibtest11d）のMySQL記述ファイル（.frmファイル）が含まれます。これらの10個のファイルのうち6個が（alex1、alex2、alex3、blobt3、ibstest0、ibstest09）テーブル固有のデータファイル（.ibdファイル）に格納されます。
$ ls /home/pekka/sqldata/mts/test
alex1.frm alex2.ibd blobt3.frm ibstest0.ibd ibtest11a.frm ibtest11d.frm
alex1.ibd alex3.frm blobt3.ibd ibtest09.frm ibtest11b.frm
alex2.frm alex3.ibd ibstest0.frm ibtest09.ibd ibtest11c.frm
--includeオプションを指定してibbackupを実行します。
$ ibbackup --include 'test＼.ib.*' /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/mts
innodb_data_file_path got value ibdata1:10M:autoextend
datadir got value /home/pekka/sqldata/mts
innodb_log_group_home_dir got value /home/pekka/sqldata/mts
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:10M: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
Value of include option: 'test\.ib.*'
ibbackup: Found checkpoint at lsn 4 2177623762
ibbackup: Starting log scan from lsn 4 2177623552
040127 15:46:37 ibbackup: Copying log...
040127 15:46:37 ibbackup: Log copied, lsn 4 2177623762
ibbackup: We wait 10 seconds before starting copying the data files...
040127 15:46:47 ibbackup: Copying /home/pekka/sqldata/mts/ibdata1
040127 15:47:34 ibbackup: Copying /home/pekka/sqldata/mts/test/ibstest0.ibd
040127 15:47:45 ibbackup: Copying /home/pekka/sqldata/mts/test/ibtest09.ibd
ibbackup: A copied database page was modified at 4 2177623762
ibbackup: Scanned log up to lsn 4 2177623762
ibbackup: Was able to parse the log up to lsn 4 2177623762
ibbackup: Maximum page number for a log record 0
040127 15:48:00 ibbackup: Full backup completed!
バックアップ ディレクトリにはibstestテーブルとibtest09テーブルのバックアップだけが含まれます。その他のInnoDBテーブルは、includeパターンtest\.ib.*に一致しませんでした。ただし、テーブルibtest11a、ibtest11b、ibtest11c、ibtest11dは、次に示すディレクトリには表示されませんが、バックアップには含まれている点に注意してください。これは、それらが常にバックアップに含まれるシステム テーブルスペース（ibdata1ファイル)に格納されているからです。
$ ls /home/pekka/sqldata-backups/test
ibstest0.ibd ibtest09.ibd
6.2 例：圧縮済み部分バックアップの作成
この時点で、MySQLは各InnoDBテーブルが独自のテーブルスペースを持つように設定されています。ここでは、alexまたはblobで始まる名前を持つInnoDBテーブルだけを含む部分バックアップを作成します。testデータベースのデータベース ディレクトリの内容は次のとおりです。
--compressオプションと--includeオプションを指定してibbackupを実行します。
$ ibbackup --compress --include '.*＼.(alex|blob).*' /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/mts
innodb_data_file_path got value ibdata1:10M:autoextend
datadir got value /home/pekka/sqldata/mts
innodb_log_group_home_dir got value /home/pekka/sqldata/mts
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:10M: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
Value of include option: '.*\.(alex|blob).*'
ibbackup: Found checkpoint at lsn 4 2177623762
ibbackup: Starting log scan from lsn 4 2177623552
040127 17:11:04 ibbackup: Copying log...
040127 17:11:04 ibbackup: Log copied, lsn 4 2177623762
ibbackup: We wait 10 seconds before starting copying the data files...
040127 17:11:14 ibbackup: Copying /home/pekka/sqldata/mts/ibdata1
040127 17:11:56 ibbackup: Copying /home/pekka/sqldata/mts/test/alex2.ibd
040127 17:11:56 ibbackup: Copying /home/pekka/sqldata/mts/test/alex3.ibd
040127 17:11:56 ibbackup: Copying /home/pekka/sqldata/mts/test/blobt3.ibd
040127 17:12:25 ibbackup: Copying /home/pekka/sqldata/mts/test/alex1.ibd
ibbackup: A copied database page was modified at 4 2177623762
ibbackup: Scanned log up to lsn 4 2177623762
ibbackup: Was able to parse the log up to lsn 4 2177623762
ibbackup: Maximum page number for a log record 0
ibbackup: Compressed 246 MB of data files to 51 MB (compression 79%).
040127 17:12:49 ibbackup: Full backup completed!
testデータベースのバックアップ ディレクトリは次のとおりです。.ibzファイルは圧縮済みのテーブル固有のデータファイルです。
$ ls /home/pekka/sqldata-backups/test
alex1.ibz alex2.ibz alex3.ibz blobt3.ibz
6.3 単一の.ibdファイルのリストア
テーブル固有のテーブルスペースを持つテーブル（.ibdファイルに格納）は、MySQLサーバを停止させることなく個別にリストアできます。.ibdファイルの「クリーン」バックアップがある場合は、次のように、バックアップの取得元であるMySQLインストールにそれをリストアできます。
1. リストア先のテーブルへの書き込みをブロックします。これにより、リストアの実行中にユーザがテーブルを変更してしまうのを防ぎます。
LOCK TABLES tbl_name WRITE;
2. 次のALTER TABLEステートメントを発行します。
ALTER TABLE tbl_name DISCARD TABLESPACE;
注意：これは、現在の.ibdファイルを削除します。
3. バックアップ.ibdファイルを適切なデータベース ディレクトリに配置し直します。
4. 次のALTER TABLEステートメントを発行します。
ALTER TABLE tbl_name IMPORT TABLESPACE;
5. これでリストアは完了です。書き込みのロックを解除します。
UNLOCK TABLES;
ここでの「クリーン」な.ibdファイル バックアップとは次のことを意味しています。
・ .ibdファイル内にトランザクションが実行したコミットされていない変更がない
・ .ibdファイル内に、マージされていない挿入バッファ エントリがない
・ 削除がマークされたすべてのインデックスレコードが `.ibd' ファイルから削除されている
・ mysqldによって、.ibdファイルの変更されたすべてのページがバッファプールからファイルにフラッシュされている
このようなクリーン バックアップ.ibdファイルは、次の方法で作成できます。
1. mysqldサーバのすべての活動を停止し、すべてのトランザクションをコミットします。
2. SHOW INNODB STATUSがデータベースにアクティブなトランザクションがないことを示し、InnoDBのメインスレッドの状態がWaiting for server activityになるのを待ちます。これで、.ibdファイルのコピーを作成できます。
.ibdファイルのクリーンなコピーを作成するもう1つの方法として、ibbackupを使用します。
1. ibbackupを使用して、InnoDBインストールをバックアップします。
2. ibbackup --apply-logを実行し、矛盾のないバックアップ データベースのバージョンを作成します。
3. バックアップ上でセカンダリ（ダミー）mysqldサーバを起動し、それにバックアップ内の.ibdファイルをクリーンアップさせます。クリーンアップが終了するまで待ちます。
4. ダミーmysqldサーバを停止します。
5. これで、バックアップからクリーンな.ibdファイルが作成されました。
TODOには、今後の課題として、クリーンな.ibdファイルを別のMySQLインストレーションに移動可能にすることも挙げられています。これを実現するには、.ibdファイル内のトランザクションIDとログ シーケンス番号を設定し直す必要があります。
SoftAgencyは株式会社ソフトエイジェンシーの登録商標です。