MySQL バックアップ リカバリ概要 オープンソース コンピテンシコンピテンシ センター日本ヒューレットパッカードヒューレットパッカード株式会社 2006 年 12 月 6 日 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice
内容 バックアップ方法 全体バックアップの方法 バイナリログ バックアップ対象ファイル データの復元 リストアとロールフォワードリカバリ クラッシュリカバリ バイナリログとOracleのREDOログ 物理ディスクへの配置について 2 平成 18 年 12 月 6 日
バックアップ方法 全体バックアップの方法 コールドバックアップ データーベースを停止してバックアップ データファイル等を直接バックアップ ホットバックアップ データーベースを停止せずにバックアップ MySQL コマンドの mysqldump を使用した方法 FLUSH TBALE WITH READ LOCK 文を使用した方法 増分バックアップ MySQL のバイナリログを定期的にバックアップ 注意 デフォルトではバイナリログは記録されないので明示的に設定することが必要 重要 3 平成 18 年 12 月 6 日
全体バックアップの方法 コールドバックアップ ホットバックアップ (mysqldump) ホットバックアップ (FLUSH TABLES WITH READ LOCK 文 ) 4 平成 18 年 12 月 6 日 利点 確実に全体バックアップを取得できる MySQL サーバを停止させる必要がない 特定のデータベースやテーブルを対象とした部分バックアップの取得も可能 テーブルの論理バックアップなので リストアする前に取得したバックアップファイルの SQL 文を変更することが可能 InnoDB だけを使用している場合なら バックアップ中のロック時間を短くできる MySQL サーバを停止させる必要がない データベース全体に共有ロックをかけるが LVM スナップショット機能を使えば 短いロック時間でバックアップの取得が可能 欠点 MySQL サーバを停止させる必要がある バックアップ取得とリストアに必要な時間が長くなる MyISAM を使用している場合には すべてのテーブルをロックしてデータの整合性をとる必要がある LVM スナップショット機能を使用する場合 MyISAM テーブルのディスクへの同期書き込みを確認した上でバックアップを取得する必要がある
バイナリログとは 1 INSERT INTO atable VALUES(1, name1 ) MySQL 2 2 1 name1 データ : 更新 SQL 文更新 SQL 文 バイナリログ INSERT INTO atable VALUES(1, name1 ) MySQLに対して行った更新系 SQL 文をバイナリ形式で記録するファイル データを修正しないSQL 文は記録しない バイナリログファイルの切り替え 一定の大きさになると自動的に切り替わる サーバの再起動時に切り替わる コマンドによる切り替え 使用目的 データベース障害復旧時のロールフォーワードリカバリ 増分バックアップとして利用 MySQLレプリケーション マスターのデータをスレーブに複製する 5 平成 18 年 12 月 6 日
バックアップ対象ファイル データディレクトリ (/var/lib/mysql) MySQL 用データディレクトリ 設定ファイル (my.cnf /etc からリンク ) データディレクトリ (~/data) < データベース名 > (MyISAM) テーブル定義ファイル (.frm) MyISAMデータファイル (.MYD) MyISAMインデックスファイル (.MYI) < データベース名 >(InnoDB) テーブル定義ファイル (.frm) 設定ファイル 定義ファイル データファイル 増分 リカバリデータ 全体バックアップ InnoDB データファイル (ibdata1) InnoDB ログファイル (ib_logfilen) 増分バックアップ バイナリログのインデックスファイル (hostname-bin.index) 6 平成 18 年 12 月 6 日 バイナリログファイル (hostname-bin.xxxxxx)
データの復元 リストア 取得したバックアップをファイルシステムに戻すことにより バックアップを取得した時点までデータベースの状態を戻すこと リカバリ 障害が発生した時点までデータベースの状態を戻すこと ロールフォワードリカバリ メディア障害が発生した場合のリカバリ 全体バックアップと増分バックアップを使用 クラッシュリカバリ プロセス障害が発生した場合のリカバリ InnoDB データファイルと InnoDB ログファイルを使用 mysql 起動時に自動的に復元 7 平成 18 年 12 月 6 日
リストアとロールフォワードリカバリ 全体バックアップ 増分バックアップ ( バイナリログ ) binlog.00001 binlog.00002 t1からt2の増分 t2からt3の増分 binlog.00003 t3 から t4 の増分 データ 障害発生 ロールフォワード t1 時点のデータ t1 時点のデータ + t1 から t2 の増分 t2 時点のデータ + t2 から t3 の増分 t3 時点のデータ + t3 から t4 の増分 リカバリ リストア t1 t2 t3 t4 時間の経過 8 平成 18 年 12 月 6 日
クラッシュリカバリ トランザクションに対する操作の記録を残したファイル トランザクションを確実なものにする プロセス障害が発生したときに クラッシュリカバリを行うために必要なファイル プロセス 時間の経過 check point commit commit 障害発生 InnoDB ログファイル 同期 Transaction A Transaction B 不整合 Transaction C データファイル Transaction A Transaction B 再起動時のクラッシュリカバリ 9 平成 18 年 12 月 6 日
バイナリログと Oracle の REDO ログ REDO ログ = バイナリログ + InnoDB ログ メディア障害 ( ロールフォワードリカバリ ) プロセス障害 ( クラッシュリカバリ ) MySQL バイナリログ InnoDB ログ Oracle REDO ログ 10 平成 18 年 12 月 6 日
物理ディスクへの配置について ロールフォワードリカバリに必要なファイル 全体バックアップとバイナリログ クラッシュリカバリに必要なファイル データファイルと InnoDB ログファイル ディスク配置 データファイル InnoDB ログファイルを入れるディスクと バイナリログを入れるディスクを別なディスクに配置することによって リカバリ可能 パフォーマンスを考慮する場合は 更に InnoDB ログファイルを別ディスクに配置 バイナリログデータファイル + InnoDB ログ 全体バックアップ 11 平成 18 年 12 月 6 日
付録
URL MySQL のサイト http://www.mysql.com/ 日本 HP の MySQL のサイト http://www.hp.com/jp/mysql 13 平成 18 年 12 月 6 日
コールドバックアップとリカバリ手順 バックアップ MySQL サーバを停止 データディレクトリをバックアップ $ cd /var/lib/mysql/data $ tar zcvf /mysql.backup/mysqlbackup-2006-0412.tar.gz. バイナリログをバックアップバックアップ $ tar zcvf /mysql.backup/binlogs-2006-0412.tar.gz binlog-000010 binlog-000011 リストア MySQL サーバを停止 コールドバックアップからからリストア $ cd /var/lib/mysql/data $ tar zxvf /mysql.backup/mysqlbackup-2006-0412.tar.gz ( データディレクトリが残っている場合はリストアの前に別のディレクトリに退避しておくと良いでしょう ) リカバリ バイナリログを SQL 文に変換 $ mysqlbinlog --disable-log-bin binlog.000012 binlog.000013 --result-file=/mysql.sql/binlog12-13.sql MySQL サーバをネットワークネットワーク接続無接続無しでしで起動 $ /usr/bin/mysqld_safe --user=mysql --skip-networking & 14 平成 18 年 12 月 6 日 ロールフォーワードリカバリ ( バイナリログの復元 ) $ mysql -u root --default-character-set=cp932 < /mysql.sql/binlog12-13.sql MySQL サーバを再起動
mysqldump を用いた ホットバックアップとリカバリ手順 バックアップ バックアップ前のバイナリログバイナリログを確認 mysqldumpでバックアップ $ mysqldump --user=root --password=<password> --lock-all-tables --flush-logs --hex-blob --default-character-set=cp932 --all-databases --result-file=/mysql.backup.dump/mysqlbackup-2006-0412.dump バックアップ後のバイナリログバイナリログを確認 リストア MySQL サーバを停止 InnoDB 関係のファイルファイルを削除 バイナリログを SQL 文に変換 MySQL サーバをネットワークネットワーク無しでしで起動 $ /usr/bin/mysqld_safe --user=mysql --skip-networking & mysqldumpでバックアップバックアップしておいた SQL 文を実行実行する $ mysql --user=root --default-charcter-set=cp932 < /mysql.backup/mysqlbakcup-2006-0412.dump リカバリ ロールフォーワードリカバリ ( バイナリログの復元 ) MySQL サーバを再起動 15 平成 18 年 12 月 6 日
FLUSH TABLES WITH READ LOCK 文を用いた ホットバックアップとリカバリ手順 バックアップ FLUSH TABLES WITH READ LOCK 文で共有共有ロックロックを確保 $ mysql -u root -e "FLUSH TABLES WITH READ LOCK" FLUSH LOGS 文でバイナリログバイナリログの切替 $ mysql u root e FLUSH LOGS バイナリログの確認 データディレクトリをバックアップ $ tar zcvf /mysql.backup/mysqlbackup-2006-0412.tar.gz. UNLOCK 文で共有共有ロックロックを解除 $ mysql -u root -e "UNLOCK TABLES" リストア MySQL サーバを停 バックアップからからリストア $ cd /var/lib/mysql/data $ tar zxvf /mysql.backup/mysqlbackup-2006-0412.tar.gz リカバリ バイナリログを SQL 文に変換 MySQL サーバをネットワークネットワーク接続無接続無しでしで起動 ロールフォーワードリカバリ ( バイナリログの復元 ) MySQL サーバを再起動 16 平成 18 年 12 月 6 日