xtrabackup(innobackupex)使用詳細
6082 ワード
innobackupexは実際にpercona-xtrabackupのperl統合スクリプトであり、機能はもちろんより強力である.
xtrabackupバックアップは実際にはオンラインの物理ホットスペアであるが、なぜそう言うのか、実際にはmysql物理ファイルをコピーしてバックアップする方式であるため、データの欠落を避けるためにロックとフックをいくつか加えただけで、優位性はもちろん速く、物理コピーは常に速度が最も速いバックアップ方式であり、欠点は空間を占有することである.
バックアップの原理には多くの文章が書かれているが、バックアップの初期にredoのフックを作成し、バックアップ中に発生したデータを記録できるようにし、データファイルをバックアップする際にもテーブルをロックすることで、データがより完全になることに重点を置いている.
インストール方法は別の文章ですでに述べたので、あまり言わないで、以下は直接使用方法といくつかのパラメータの説明を紹介します.
xtrabackupは全備と増備をサポートしていますが、個人的には増備はお勧めしません.増備効果はあまりよくないし、binlogを直接コピーしても使いやすいので、全備+binlogでいいです.
バックアップ:
完全準備コマンド:
バックアップ完了後に表示
innobackupex: completed OK!
完成しました.
コマンドパラメータの説明:
--defaults-fileデータベースのプロファイルをバックアップするmy.cnfのパス
--user=rootバックアップ操作ユーザー名は、一般的にrootユーザーですが、-password=$pwdrバックアップ操作ユーザー名のパスワード--host=$hostsホストipを変更できます.ローカルでは追加せずにssh転送できます.ポート--parallel=4の並列数を開くには、ホスト構成に応じて適切なものを選択します.デフォルトは1つで、複数はバックアップ速度を速めることができます.
--throttle=400実行io制限数は、一般的に並列に速度を上げることができますが、IOも高く、制限は影響を減らすことができます
--stream=tar圧縮タイプですが、ここでtar形式を選択すると、tar$backupdirバックアップで格納ディレクトリ2>$backupdir/backtipしかないようです.logバックアップログは、バックアップ中の出力情報をlog|gzip>$backupdir/$backnameにリダイレクトする.tar.gzファイルをバックアップした後、パイプで再圧縮し、最後に圧縮ファイルとなり、占有スペースを減らす
一般的なパラメータもいくつかあります.
--databasesはバックアップのデータベースとライブラリのテーブルを指定します.例えば、databases=「db db.table」ですが、多くの共通情報が彼に依存しているため、mysqlライブラリをバックアップします.
--no-lockはinnodbテーブルとfrmファイル以外のバックアップ時にテーブルをロックしないことができますが、masterとslaveのpos情報は記録できません.write_binlog_infoとwrite_slave_info関数はmysql_のみlockall関数で呼び出され、mysql_lockalはflush tables with read lockを呼び出した(生産環境に適していない)
--use-memory preparingプロセスは、システムの使用可能なメモリに応じて、より多くのメモリを割り当てることで速度を向上させることができます.デフォルトは100 MBです.総じて割り当てられたメモリが多ければ多いほど良いです.
従ライブラリの場合は、従ライブラリパラメータを追加することもできます.
--slave-infoバックアップディレクトリでxtrabackup_が生成されます.slave_infoファイル、ここではメインログファイルとオフセットが保存されます.ファイルの内容はCHANGE MASTER TO MASTER_と似ています.LOG_FILE='', MASTER_LOG_POS=0
リカバリ:
リカバリの第一歩:ログを適用します.
に見える
completed OK!
次のステップに進むことができます
手順2:ファイルをコピーします.
に見える
completed OK!
データの復元が完了しました
コマンドパラメータの説明:
--defaults-file=/etc/my.cnfはmyを使用する.cnfファイル、復元する必要があるファイルをmyに復元します.cnfが指定した場所は、一番前に書かなければなりません.そうしないと、エラーが発生します.--apply-logバックアップ時に発生したログを適用し、全体のコピー回復の準備をする--copy-backは完全なバックアップファイルをターゲットディレクトリにコピーし、--defaults-fileで指定したmy.cnf決定
--use-memory=4 Gリカバリを高速化するために、使用可能なメモリパラメータを設定します.
一般的なパラメータもいくつかあります.
--databasesは、リストアされたデータベースとライブラリのテーブルを指定します.
--exportは--apply-logで使用し、InnoDBテーブルごとに作成する.expの最後のファイルを復元する必要があるテーブルのibdとexpファイルをターゲットマシンにコピーし、ターゲットマシンでインポートを実行します:mysql>create table t()engine=innodb;//ここでは、DBAが同じ構造のテーブルまたはテーブルがmysql>ALTER TABLE t DISCARD TABLESPACEにすでに存在することを手動で作成する必要があります.$cp t.ibd t.exp ${DATA_DIR}/${DB}/mysql> ALTER TABLE t IMPORT TABLESPACE;1回の表空間転送を行い、単一の表データを復元することに相当します.
手順3:ファイル権限を変更します.
一般的な操作リカバリで使用されるユーザーはrootなので、リカバリ後はmysql:mysqlの権限ではありませんので、変更します
インクリメンタルバックアップの方法:
インクリメンタル・バックアップは、フル・バックアップに基づいている必要があります.まず、フル・バックアップ(/backup/mysql-data/2016-05-10_09)があり、このフル・テーブルに基づいてインクリメンタル・バックアップが行われていると仮定します.
innobackupex --defaults-file=/****/my.cnf --user=root --password=*** --incremental-basedir=/backup/mysql-data/2016-05-10_09 --incremental/backup/mysql-data
内
--incremental-basedirは全備ディレクトリを指し、
--incrementalはインクリメンタルバックアップのディレクトリを指します.
上記の文が正常に実行されると、--incrementalが実行したディレクトリの下にタイムスタンプディレクトリが作成され、インクリメンタルバックアップのすべてのファイルが格納されます.バックアップディレクトリの下にxtrabackup_というファイルがあります.checkpointsはバックアップ情報を記録しており、完全な情報は以下の通りです.
[plain]
backup_type = full-backuped
from_lsn = 0
to_lsn = 563759005914
last_lsn = 563759005914
このフル・スペア・ベースのインクリメンタル・バックアップの情報は、次のとおりです.
[plain]
backup_type = incremental
from_lsn = 563759005914
to_lsn = 574765133284
last_lsn = 574765133284
インクリメンタルバックアップのfrom_lsnは完全なto_に等しいlsn.
また、インクリメンタル・バックアップに加えてインクリメンタル・バックアップを行うこともできます.
innobackupex --defaults-file=/*****/my.cnf --user=root --password=*** --incremental-basedir=/backup/mysql-data/2016-05-10_09 --incremental/backup/mysql-data
そのxtrabackup_checkpointsはバックアップ情報を以下のように記録しています.
[plain]
backup_type = incremental
from_lsn = 574765133284
to_lsn = 574770200380
last_lsn = 574770200950
このインクリメンタルバックアップのfrom_lsnは前回のインクリメンタルバックアップからto_lsnが始まりました.
インクリメンタル・バックアップのリカバリは、すべてのバックアップ・ディレクトリの下でコミットされたログを再作成するよりも複雑です.
インクリメンタル・バックアップのリカバリは、フル・バックアップよりも複雑です.最初のステップは、すべてのバックアップ・ディレクトリの下でコミットされたログをやり直します.たとえば、次のようにします.
[plain]
innobackupex --apply-log --redo-only BASE-DIR
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
innobackupex --apply-log BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
ここで、BASE-DIRとはフル・スペア・ディレクトリ、INCREMENTAL-DIR-1とは1回目のインクリメンタル・バックアップ、INCREMENTAL-DIR-2とは2回目のインクリメンタル・バックアップのことである.
ここで注意したいのは、最後のステップのインクリメンタルバックアップには--redo-onlyオプションはありません.また、--use_を使用できます.memoryは性能を向上させる.
上記の文が正常に実行された後、最終データはBASE-DIR(すなわち、フル・スペア・ディレクトリ)の下にあります.
最初のステップが完了すると、次のステップに進みます.未完了のログをロールバックします.
[plain]
innobackupex --apply-log BASE-DIR
上記の実行が完了すると、BASE-DIRのバックアップファイルは完全に準備されており、最後のステップはコピーです.
[plain]
innobackupex --copy-back BASE-DIR
同様に、コピーが完了したら、データディレクトリの権限が正しいかどうかを確認してください.
xtrabackupバックアップは実際にはオンラインの物理ホットスペアであるが、なぜそう言うのか、実際にはmysql物理ファイルをコピーしてバックアップする方式であるため、データの欠落を避けるためにロックとフックをいくつか加えただけで、優位性はもちろん速く、物理コピーは常に速度が最も速いバックアップ方式であり、欠点は空間を占有することである.
バックアップの原理には多くの文章が書かれているが、バックアップの初期にredoのフックを作成し、バックアップ中に発生したデータを記録できるようにし、データファイルをバックアップする際にもテーブルをロックすることで、データがより完全になることに重点を置いている.
インストール方法は別の文章ですでに述べたので、あまり言わないで、以下は直接使用方法といくつかのパラメータの説明を紹介します.
xtrabackupは全備と増備をサポートしていますが、個人的には増備はお勧めしません.増備効果はあまりよくないし、binlogを直接コピーしても使いやすいので、全備+binlogでいいです.
バックアップ:
完全準備コマンド:
# , mysql
/etc/init.d/mysql status
# ,
/usr/bin/innobackupex --defaults-file=$cnfdir --user=root --password=$pwdr --host=$hosts --parallel=4 --throttle=400 --stream=tar $backupdir 2>$backupdir/backtip.log |gzip >$backupdir/$backname.tar.gzバックアップ完了後に表示
innobackupex: completed OK!
完成しました.
コマンドパラメータの説明:
--defaults-fileデータベースのプロファイルをバックアップするmy.cnfのパス
--user=rootバックアップ操作ユーザー名は、一般的にrootユーザーですが、-password=$pwdrバックアップ操作ユーザー名のパスワード--host=$hostsホストipを変更できます.ローカルでは追加せずにssh転送できます.ポート--parallel=4の並列数を開くには、ホスト構成に応じて適切なものを選択します.デフォルトは1つで、複数はバックアップ速度を速めることができます.
--throttle=400実行io制限数は、一般的に並列に速度を上げることができますが、IOも高く、制限は影響を減らすことができます
--stream=tar圧縮タイプですが、ここでtar形式を選択すると、tar$backupdirバックアップで格納ディレクトリ2>$backupdir/backtipしかないようです.logバックアップログは、バックアップ中の出力情報をlog|gzip>$backupdir/$backnameにリダイレクトする.tar.gzファイルをバックアップした後、パイプで再圧縮し、最後に圧縮ファイルとなり、占有スペースを減らす
一般的なパラメータもいくつかあります.
--databasesはバックアップのデータベースとライブラリのテーブルを指定します.例えば、databases=「db db.table」ですが、多くの共通情報が彼に依存しているため、mysqlライブラリをバックアップします.
--no-lockはinnodbテーブルとfrmファイル以外のバックアップ時にテーブルをロックしないことができますが、masterとslaveのpos情報は記録できません.write_binlog_infoとwrite_slave_info関数はmysql_のみlockall関数で呼び出され、mysql_lockalはflush tables with read lockを呼び出した(生産環境に適していない)
--use-memory preparingプロセスは、システムの使用可能なメモリに応じて、より多くのメモリを割り当てることで速度を向上させることができます.デフォルトは100 MBです.総じて割り当てられたメモリが多ければ多いほど良いです.
従ライブラリの場合は、従ライブラリパラメータを追加することもできます.
--slave-infoバックアップディレクトリでxtrabackup_が生成されます.slave_infoファイル、ここではメインログファイルとオフセットが保存されます.ファイルの内容はCHANGE MASTER TO MASTER_と似ています.LOG_FILE='', MASTER_LOG_POS=0
リカバリ:
リカバリの第一歩:ログを適用します.
# ,
# mysql
/etc/init.d/mysql stop
# datadir mysql
rm -rf /data/mysql/data/*
#
innobackupex --defaults-file=****/my.cnf --apply-log --use-memory=4G /backup/ に見える
completed OK!
次のステップに進むことができます
手順2:ファイルをコピーします.
# my.cnf datadir , ,
ll /data/mysql/data/
#
innobackupex --defaults-file=****/my.cnf --copy-back /backup/
# --apply-log datadir , , に見える
completed OK!
データの復元が完了しました
コマンドパラメータの説明:
--defaults-file=/etc/my.cnfはmyを使用する.cnfファイル、復元する必要があるファイルをmyに復元します.cnfが指定した場所は、一番前に書かなければなりません.そうしないと、エラーが発生します.--apply-logバックアップ時に発生したログを適用し、全体のコピー回復の準備をする--copy-backは完全なバックアップファイルをターゲットディレクトリにコピーし、--defaults-fileで指定したmy.cnf決定
--use-memory=4 Gリカバリを高速化するために、使用可能なメモリパラメータを設定します.
一般的なパラメータもいくつかあります.
--databasesは、リストアされたデータベースとライブラリのテーブルを指定します.
--exportは--apply-logで使用し、InnoDBテーブルごとに作成する.expの最後のファイルを復元する必要があるテーブルのibdとexpファイルをターゲットマシンにコピーし、ターゲットマシンでインポートを実行します:mysql>create table t()engine=innodb;//ここでは、DBAが同じ構造のテーブルまたはテーブルがmysql>ALTER TABLE t DISCARD TABLESPACEにすでに存在することを手動で作成する必要があります.$cp t.ibd t.exp ${DATA_DIR}/${DB}/mysql> ALTER TABLE t IMPORT TABLESPACE;1回の表空間転送を行い、単一の表データを復元することに相当します.
手順3:ファイル権限を変更します.
一般的な操作リカバリで使用されるユーザーはrootなので、リカバリ後はmysql:mysqlの権限ではありませんので、変更します
# data
cd /data/mysql
#
chown -R mysql.mysql data/
#
/etc/init.d/mysqld start
# , インクリメンタルバックアップの方法:
インクリメンタル・バックアップは、フル・バックアップに基づいている必要があります.まず、フル・バックアップ(/backup/mysql-data/2016-05-10_09)があり、このフル・テーブルに基づいてインクリメンタル・バックアップが行われていると仮定します.
innobackupex --defaults-file=/****/my.cnf --user=root --password=*** --incremental-basedir=/backup/mysql-data/2016-05-10_09 --incremental/backup/mysql-data
内
--incremental-basedirは全備ディレクトリを指し、
--incrementalはインクリメンタルバックアップのディレクトリを指します.
上記の文が正常に実行されると、--incrementalが実行したディレクトリの下にタイムスタンプディレクトリが作成され、インクリメンタルバックアップのすべてのファイルが格納されます.バックアップディレクトリの下にxtrabackup_というファイルがあります.checkpointsはバックアップ情報を記録しており、完全な情報は以下の通りです.
[plain]
backup_type = full-backuped
from_lsn = 0
to_lsn = 563759005914
last_lsn = 563759005914
このフル・スペア・ベースのインクリメンタル・バックアップの情報は、次のとおりです.
[plain]
backup_type = incremental
from_lsn = 563759005914
to_lsn = 574765133284
last_lsn = 574765133284
インクリメンタルバックアップのfrom_lsnは完全なto_に等しいlsn.
また、インクリメンタル・バックアップに加えてインクリメンタル・バックアップを行うこともできます.
innobackupex --defaults-file=/*****/my.cnf --user=root --password=*** --incremental-basedir=/backup/mysql-data/2016-05-10_09 --incremental/backup/mysql-data
そのxtrabackup_checkpointsはバックアップ情報を以下のように記録しています.
[plain]
backup_type = incremental
from_lsn = 574765133284
to_lsn = 574770200380
last_lsn = 574770200950
このインクリメンタルバックアップのfrom_lsnは前回のインクリメンタルバックアップからto_lsnが始まりました.
インクリメンタル・バックアップのリカバリは、すべてのバックアップ・ディレクトリの下でコミットされたログを再作成するよりも複雑です.
インクリメンタル・バックアップのリカバリは、フル・バックアップよりも複雑です.最初のステップは、すべてのバックアップ・ディレクトリの下でコミットされたログをやり直します.たとえば、次のようにします.
[plain]
innobackupex --apply-log --redo-only BASE-DIR
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
innobackupex --apply-log BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
ここで、BASE-DIRとはフル・スペア・ディレクトリ、INCREMENTAL-DIR-1とは1回目のインクリメンタル・バックアップ、INCREMENTAL-DIR-2とは2回目のインクリメンタル・バックアップのことである.
ここで注意したいのは、最後のステップのインクリメンタルバックアップには--redo-onlyオプションはありません.また、--use_を使用できます.memoryは性能を向上させる.
上記の文が正常に実行された後、最終データはBASE-DIR(すなわち、フル・スペア・ディレクトリ)の下にあります.
最初のステップが完了すると、次のステップに進みます.未完了のログをロールバックします.
[plain]
innobackupex --apply-log BASE-DIR
上記の実行が完了すると、BASE-DIRのバックアップファイルは完全に準備されており、最後のステップはコピーです.
[plain]
innobackupex --copy-back BASE-DIR
同様に、コピーが完了したら、データディレクトリの権限が正しいかどうかを確認してください.