Innobackupex と mydumper、mysql バックアップ ツール

------------------------------------------------

------物理バックアップツール Innobackupex------

----------------------------- --- ------------------

公式マニュアル: https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html

主​​にホット バックアップに使用 InnoDB や MyISAM などのエンジンに保存されているデータをバックアップする場合、バックアップされるデータはメモリにロードされ、ディスク上のバックアップ データファイルに書き込まれます。バックアップ中に変更されたデータは、REDO ログのリカバリと同じ方法でバックアップ ファイルに追加されます。

=============================================== == ===============================================

innobackupex の完全な準備プロセス:

1. xtrabackup_logfile を有効にします。 InnoDB ストレージ エンジンでの新しい DML 操作によってデータ変更が発生したときに、これらの新しいデータ変更を xtrabackup_logfile にリアルタイムで記録するために使用されます

2。ページ単位 データ ファイル: 共有テーブル スペース ibdataX および .ibd ファイル。コピー中にページが書き込まれている可能性があるため、ページの先頭と末尾のチェックサム値は異なります。したがって、後でバックアップ ファイルを生成する場合は、不完全なページの修復に使用する前にログを適用する必要があります。

3. 読み取りロックを使用してテーブルをフラッシュします。 MyISAM テーブルに読み取りロックを追加して、非トランザクション エンジン MyISAM に保存されているデータをコピーします

4. .frm、.MYD、.MYI ファイルをコピーします。

5. バックアップが完了した時点での binlog の最新の位置を取得します: xtrabackup_binlog_info (InnoDB データ ファイルが更新される可能性があります)。

6. テーブルのロックを解除します。

7. (1) バックアップが完了したら、バックアップを開始するために必要な最小限のパラメーターをbackup-my.cnf

に記録します。 (2) LSN を xtrabackup_logfile に記録します。

(3) バックアップの種類(フルバックアップ:完全、増分:増分。ログが適用されたバックアップは完全準備に変更されます)およびその他の情報をxtrabackup_checkpointsに記録します。

(4) その他のバックアップ情報を記録します:

(1) Backup-my.cnf

(2) xtrabackup_binlog_info: データ バックアップのために MyISAM と混合すると、xtrabackup_binlog_pos_innodb よりも正確になります

(3) xtrabackup_binlog_pos_innodb: ログ適用後に新しく生成されたファイル。MyISAM

によって生成されたビンログを計算せずに、innodb のビンログの場所のみを記録します。 (4) xtrabackup_checkpoints

(5) xtrabackup_info

( 6) xtrabackup_logfile (コア ファイル)

(7 ) xtrabackup_slave_info (ライブラリから重要なファイルをバックアップ): バックアップ時に --slave-info オプションを追加する必要があります。このファイルに記録されます。バックアップ ファイルを使用してスレーブ データベースを復元した後、この情報は同期のためにマスター データベースを指すために使用されます。

=============================================== == ===============================================

innobackupex 増分バックアップ プロセス

innobackupex InnoDB テーブル データを増分バックアップする場合、完全バックアップ プロセスと比較して、バックアップがページをコピーするときに、バックアップ ファイルの LSN が現在のデータのページと比較されます。データ関連のページの場合、LSN が増加します。そのため、innobackupex は LSN が変更されたページのみをバックアップする必要があります。

MyISAM をバックアップするときも、完全バックアップ操作が実行されます。

=============================================== == ===============================================

バックアップステートメントの例

バックアップアカウントに必要な権限: RELOAD、LOCK TABLES、REPLICATION CLIENT

(1) Full:

step1:

innobackupex --defaults-file=/usr/local/mysql/my . cnf --user=username --password='user_passwd' --host=[HOST]--port=[PORT] --no-timestamp /tmp/innobackup_all

step2：

innobackupex --apply-log - -defaults-file=/tmp/innobackup_all/backup-my.cnf --user=username --password='user_passwd' --host=[HOST] --port=[PORT] --/tmp/innobackup_all

（ 2 ) 部分バックアップ: バックアップの形式は次のとおりです: mydatabase.mytable

step1:

正規表現で --include を使用します

innobackupex --include='^mydatabase[.]mytable' /path/to/backup --no-timestamp

完全なテーブル名を記録するテキスト ファイルで --tables-file を使用します (1 行に 1 つのテーブル名)

echo "mydatabase.mytable" > /tmp/tables.txt

innobackupex - -tables-file=/tmp/tables.txt /path/to/backup --no-timestamp

--databases を使用してライブラリとテーブルを指定します (たとえば、バックアップ テーブル: mydatabase.mytable およびライブラリ: mysql)

innobackupex --databases="mydatabase.mytable mysql" /path/to/backup --no-timestamp - -user= Backup --password=backup

step2:

部分バックアップを準備します: innobackupex --apply-log --export /path/to/backup/

(--databases 指定されていないライブラリ テーブル。準備ステージ「メモは存在しますか?」、このメッセージは無視できます)

(3) 増分バックアップ (完全バックアップを想定、パス: $FULLBACKUP)

ステップ 1:

最初の増分バックアップ (完全バックアップに基づく): innobackupex - -incremental $INCREMENTALBACKUP_1 --incremental-basedir=$FULLBACKUP --user=USER --password=PASSWORD

2 回目の増分バックアップ (最初の増分バックアップに基づく): innobackupex --incremental $INCREMENTALBACKUP_2 --incremental-basedir= NCREMENTALBACKUP_1 --user=USER --password=PASSWORD

(...)

N回目

step2: prepare

innobackupex --apply-log --redo-only $FULLBACKUP --use-memory= 1G --user=USER --password=PASSWORD

innobackupex --apply-log --redo-only $FULLBACKUP--incremental-dir=$INCREMENTALBACKUP_1 --use-memory=1G - -user=DVADER --password= D4RKS1D3

innobackupex --apply-log --redo-only $FULLBACKUP --incremental-dir=$INCREMENTALBACKUP_2 --use-memory=1G --user=DVADER --password=D4RKS1D3

(...)

innobackupex --apply-log--redo-only $FULLBACKUP --incremental-dir=$INCREMENTALBACKUP_N --use-memory=1G --user=DVADER --password= D4RKS1D3

innobackupex --apply-log $ FULLBACKUP --use-memory=1G --user=$USERNAME --password=$PASSWORD

--use-memory: 準備が使用できるメモリを指定します。 -- use apply-log を一緒に使用して準備を高速化します準備フェーズでは、最初の完全バックアップと増分バックアップの統合プロセス中に --redo-only を追加する必要があります。最後に、すべての増分バックアップが統合された後、増分バックアップに統合された完全バックアップ ファイルを再度準備する必要があります。

=============================================== == ===============================================

その他の一般的に使用されるパラメーター:

一緒に使用します: --stream=xbstream --compress --compress-threads=8 --Parallel=4 > backupfile.xbstream (xbstream オプションは、ibd ファイルを圧縮してストリーミングします)テーブルを 1 つずつ実行するため、innodb-file-per-table パラメーターをオンにする必要があります)

--Parallel: バックアップ同時実行数 (ibd ファイルのコピーを指し、圧縮スレッドとは異なります)。圧縮を実行するスレッドの数)

--stream: tar、xbstream 。 innobackupex [...] --stream=tar /backupdir/ | gzip - > backupfile.tar.gz

--tmpdir: リモート マシンにストリーミングする前の一時ディレクトリの場所

- -encryption : バックアップ暗号化。実際の状況では、より一般的に使用されるのは

(1) openssl で、上記の tar+gz メソッドに暗号化オプションを追加します。 innobackupex [...] --stream=tar /backupdir/ - | openssl aes-256 -cbc -k "abc" > バックアップファイル.tar.gz.aes-256-cbc

(2)des3,innobackupex [...] --stream=tar /backupdir/ - | k " abc" > バックアップファイル.tar.gz.des3

================================ ==== ============================================= ==== =========

innobackupex リカバリ プロセス

1. innobackupex --apply-log、目的は​​、xtrabackup_log から REDO ログを取得し、いくつかの不完全なページを更新して、先頭と末尾のチェックサム値、および LSN はバックアップ プロセス中に最新の LSN 番号に更新されます (実際にはバックアップ プロセスに分割する必要があります)

2. バックアップ データをデータベース データ ディレクトリにコピーします。データ ディレクトリのアクセス許可を変更して開始します。

=============================================== == ===============================================

リカバリステートメントの例:

1. リカバリの前にインスタンスを閉じます

2. 元のデータディレクトリをバックアップします (REDO ログと UNDO ログが分離されている場合はバックアップする必要があります)

3.コピーバック --user=username - -password='user_passwd' --socket=/usr/local/mysql/run/mysqld.sock --defaults-file=/usr/local/mysql/my.cnf /tmp/ innobackup_all (または、準備したバックアップ ファイルを直接コピーします)

4. ディレクトリのアクセス許可を変更し、mysql を起動します

========================== =========== ====================================== =========== ===========

任意の InnoDB データベースから個々のテーブル データをエクスポートします (innodb_file_per_table オプションがオンになっている場合)

Percona XtraBackup を使用すると、次のことができます。任意の InnoDB データベースから個々のテーブルをエクスポートし、XtraDB または MySQL 5.6 を使用して Percona Server にインポートします (ソースは XtraDB または MySQL 5.6 である必要はありませんが、宛先は個々の .ibd ファイルでのみ機能します)。独自の ibd ファイルに含まれていないテーブルはエクスポートできません。

準備段階で --export オプションを使用して単一のテーブルをエクスポートする必要があります。

完全バックアップが作成されたら、- を使用して準備します。 -export オプション:

$ innobackupex --apply-log --export /path/to/backup

これにより、独自のテーブルスペースを持つ InnoDB ごとに .exp 拡張子を持つファイルが作成されます。

各 innodb テーブルのテーブルスペースに対して .exp で終わるファイルが作成されます

出力ファイルの形式は次のとおりです:

/data/backups/mysql/test/export_test.exp
/data/backups/mysql/ test/export_test.ibd
/data/backups/mysql/test/export_test.cfg

他のサーバーからテーブルをインポートする場合、最初にテーブルを作成する必要があります(独立テーブルファイルにはテーブル構造情報がないため):

mysqlfrm --diagnostic /data/2017-03-22_16-13-00/yayun/t1.frm (mysql-utilities ツールで mysqlfrm を使用して、バックアップ ファイルからテーブル構造を読み取ります)

mysql> CREATE TABLE mytable ( ...) ENGINE =InnoDB; (前に読み取ったテーブル構造に基づいてテーブルを作成します)

テーブルスペースファイルを削除します:

mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

エクスポートされた .ibd と .ibd をコピーします。 exp ファイルをデータ ディレクトリにコピーします。 次に:

この後、mytable.ibd および mytable.exp (MySQL 5.6 にインポートする場合は mytable.cfg) ファイルをデータベースのホームにコピーします

次に、テーブルスペースをインポートします:

mysql> .mytable IMPORT TABLESPACE;

------------------------------------------ ----------

--- ---論理バックアップツール mydumper-----

------------------------ ---------- ---------

英語文献の一部は GitHub の README から抜粋しています: https://github.com/maxbube/mydumper

5.5 /5.6 バージョンの MySQL データベースは、正式バージョンの Mysqldump と比較してシングルスレッド バックアップを実行し、マルチスレッド バックアップ ツール mydumper には独自の利点があります。 (MySQL 5.7.11 以降のバージョンでは、公式は並列ロジック バックアップ ツール mysqlpump の一貫したバックアップの問題を最終的に修正しました。mysqlpump については、Daniel Jiang Chengyao の紹介を参照してください: http://www.tuicool.com/articles/ E77bYz7)

欠点: 同時ストリーミングを通じてリモート バックアップ センターにバックアップするのは難しく、多くの場合、ローカル ディスクに直接バックアップされます。

== 一貫性のあるスナップショットはどのように機能しますか? ==
これはすべて、MySQL のベストプラクティスと伝統に従って行われます:

* 予防策として、サーバー上で実行中のクエリが遅い場合はダンプが中止されるか、強制終了されます
* グローバル書き込みロックを取得します ("FLUSH TABLES WITH READ LOCK")
* 各種メタデータを読み取ります ("SHOW SLAVE STATUS"、"SHOW MASTER STATUS")
* 他のスレッドが接続してスナップショットを確立します ("START TRANSACTION WITH CONSISTENT SNAPSHOT")
** 4.1.8 より前では、ダミーの InnoDB テーブルを作成し、そこから読み取ります。
* すべてのワーカー スレッドがスナップショットの確立を発表すると、マスターは「UNLOCK TABLES」を実行し、ジョブのキューイングを開始します。

mydumper の整合性実装メカニズム:

*遅いクエリが発生すると、dump が実行を停止するか、mydumper が遅いクエリを強制終了します。 ( --long-query-guard パラメータは、遅いクエリの時間を合意するために使用されます。デフォルトは 60 秒です。 --kill-long-queries をこのパラメータに追加すると、遅いクエリはアクティブに強制終了されます。追加されていない場合、mydumper は遅いクエリに遭遇すると自動的にそのクエリを強制終了し、実行を停止します)
* 「FLUSH TABLES WITH READ LOCK」を使用してグローバル読み取りロックを適用し、DML ステートメントを防止します
* メタデータを表示します。 : "SHOW SLAVE STATUS"、"SHOW MASTER STATUS"

* "START TRANSACTION WITH "consistent snapshot": starttransaction はトランザクションを開始し、現在のトランザクションの整合性のある読み取りスナップショットをただちに作成します。 with オプションを使用しない場合、トランザクションの最初のステートメントが実行されるまでトランザクションは実際に開始されず、一貫した読み取りスナップショットが確立されます

* バージョン 4.1.8 以降、mydumper は InnoDB タイプの仮想テーブルを作成し、そこからデータを読み取りますそれ

* すべてのスレッドが整合性スナップショットが確立されたことを報告したら、「UNLOCK TABLES」を実行してキュータスクを開始します。

バックアップステートメントの例:

mydumper --user=username --password=user_passwd --socket=/... --regex '^(?!(mysql))' --output=/backupdir - -compress --verbose=3 --logfile=/backupdir/mydumper_backup.log

共通パラメータの説明:

--database はバックアップする必要があるライブラリを指定します
--tables-list はバックアップする必要があるテーブルを指定します(正規表現オプションが競合する場合、正規表現が優先されます) で区切ってバックアップする必要があります

--regex '^(?!(mysql|test))': データベース フィルタリング オプション

--output=/backupdir: バックアップ ファイル出力パス

--compress : 圧縮された出力ファイル (拡張子 .gz)

--verbose=3: バックアップ ステータスを簡単に観察できる出力ログ レベル情報 (0 = サイレント、1 = エラー、2 = 警告、3 = 情報) 、デフォルト 2)

- -logfile=/backupdir/mydumper_backup.log: mydumper 実行ログ ファイルの場所を指定します

--threads バックアップ中に使用されるスレッドの数を指定します。デフォルトは 4 です

-- state-size: SQL ステートメントの最大長を制限します (mydumper はバックアップ時に SQL をマージします)
--rows: テーブルを行数で分割します。 myloader 時の同時実行パフォーマンスを向上します
--chunk-filesize: 出力ファイルのサイズに応じてテーブル データを分割します。 myloader の同時実行パフォーマンスを改善します
--no-locks: テーブルをロックしません (データに一貫性がない可能性があります)
--binlogs: binlog をバックアップします。バックアップが失敗した場合は、バックアップ バイナリ ログを確認して、バックアップ ポイント付近のエラーの原因を見つけることができます。 出力バックアップ ファイル ディレクトリ:

* ライブラリ構造: dbname-schema-create.sql.gz

* テーブル構造: dbname.tblname1-schema.sql.gz

* テーブル データ: dbname.tblname1.sql.gz

(各ライブラリとテーブルには独自の独立したバックアップ ファイルがあります。単一のテーブルのみを復元する必要がある場合は、mydumper を使用して単一のテーブル + バイナリの完全なデータを復元します回復増分)

* メタデータ: バックアップ中のバイナリログの現在の場所が含まれます

----------------------------- --- ----------------------------------

ダンプ開始日: 2017-07-04 09: 45:57
SHOW MASTER STATUS :
Log: mysql-bin.000048
Pos: 107
GTID:(null)
ダンプ終了時刻: 2017-07-04 09:45:57

------ -------------------- ------------------------------ -------------------- -

* mydumper_backup.log: バックアッププログラムの動作を記録します

リカバリコマンドmyloaderの関連パラメータの説明
--ディレクトリのバックアップ ファイルの場所
--queries-per-transaction 各トランザクションで実行される SQL の数、デフォルトは 1000 です
--overwrite-tables 最初に既存のテーブルを削除してから復元します (次の場合にテーブル構造をバックアップする必要があります)ファイルのバックアップ)
--database は復元する必要があるデータベースを指定します
--enable-binlog はデータの復元操作の binlog を記録します
-- thread は復元中に使用されるスレッドの数を指定します、デフォルトは 4 です

--enable-binlog: バックアップされた binlog を復元します

注: myloader はライブラリ レベルでのみ復元できます。また、SQL ステートメントを含むファイルは、対応する関数を直接呼び出すことができます。 innobackupex は、バックアップが完了するこの時点より前のデータをバックアップしますが、mydumper (mysqldump、mysqlpump などを含む) によってバックアップされたデータの時点は、バックアップの開始時点となります。

リカバリの主な考え方について触れておきます。物理バックアップであっても論理バックアップであっても、最も信頼できるリカバリの前提条件は、データベースが一時的にデータの書き込みを禁止する必要があるということです。次に、最初に完全バックアップを復元し、最も近い障害ポイントに増分バックアップを適用してから、binlog ログを適用して障害ポイントをスキップします。

単一テーブル上のいくつかの誤操作ステートメントに対してオンライン サーバーでの書き込み操作を停止し、完全 + 増分リカバリ方法を使用することは、労力の無駄であり、利益が損失を上回ることを常に考慮してください。レプリケーション遅延戦略を備えたスタンバイ データベースがない場合は、mydumper によってバックアップされたファイルを使用して単一のテーブルを復元するか、一歩下がってフラッシュバックを使用することが迅速で優れた解決策です。

ヒント:

Innobackupex または mydumper を使用して大部分のデータを復元した後、mysqlbing を使用して上記のバックアップ プログラムではカバーできないデータ部分を埋めます。

Mysqlbinlog パラメータの説明:

–start-position=N (読み取り時に含まれます)

バイナリ ログの最初の位置が N パラメータと等しい場合、イベントから読み取りを開始します。

–stop-position=N (読み取り時には含まれません)
バイナリ ログの最初の位置が N パラメーター以上の場合、イベントからの読み取りを停止します。

mysqlbinlog を使用して binlog ログを適用する場合、複数のファイルにまたがる必要がある場合は、複数のファイルを同時に読み取ります。start-position は最初の binlog ファイルの開始点であり、stop-position は最初の binlog ファイルの終了点です。最後のファイル。 example：mysql-bin.000048（POS856）、mysql-bin.000051（pos1042）

/usr/local/mysql/bin/bin/mysqlbinlog mysql-bin.000048 mysql-bin.000049 mysql-bin.00000505050505050505050505050505050505050505050505050505050550 bin.000051 --start-position=856 --stop-position=1042 > /tmp/backup1/backup_new.sql

ヒント:

上記 2 つのバックアップ ツールオブジェクトは主にデータ ディレクトリに含まれており、バイナリ ログにも一部のデータが含まれており、バイナリ ログもバックアップする必要があることに注意してください。

バックアップ戦略について簡単に説明します。私たちが策定するバックアップ戦略はビジネスの種類に基づいて決定されます。

データグロース型ビジネスの場合はフル+インクリメンタル戦略を採用し、データ更新型の場合はフルバックアップを採用します。

論理バックアップは、MySQL のバージョン アップグレードや単一テーブルのリカバリなどの操作によく使用されます。

要約すると、オンライン データベースでは通常、物理バックアップが主な方法として、論理バックアップが補助として、そしてバイナリ ログ バックアップが採用されます。

参考ドキュメント:

innobackupex バックアップ生成ファイルの手順:

http://fordba.com/xtrabackup-Produce-file-intruduction.html

innobackupex のレシピ:

https://www.percona.com/ doc/percona-xtrabackup/LATEST/how-tos.html#recipes-ibk

innobackupex によって生成された完全バックアップから 1 つのテーブルを復元する方法:

https://www.percona.com/doc/percona -xtrabackup /2.2/innobackupex/restoring_individual_tables_ibk.html

https://www.percona.com/blog/2012/01/25/how-to-recover-a-single-innodb-table-from-a-full- backup/

https://www.percona.com/blog/2017/03/15/restore-single-innodb-table-full-backup-accidentally-dropping/

実際の単一テーブルのリカバリケース:

http://www.cnblogs.com/gomysql/p/6600616.html

部分バックアップの作成と復元:

https://www.percona.com/doc/percona-xtrabackup/2.2/innobackupex/partial_backups_innobackupex .html

リカバリのために mysqldump と binlog を組み合わせたケーススタディ:

http://blog.chinaunix.net/uid-25135004-id-1761635.html

http://www.cnblogs.com/hanyifeng/p /5756462.html

単一データベースのリカバリに mysqldump 完全ファイルを使用します (テスト対象)

https://stackoverflow.com/questions/1013852/can-i-restore-a-single-table-from-a-full -mysql-mysqldump -ファイル