MySQL論理バックアップmysqldump
8806 ワード
1特徴position位置を自動的に記録します.
2可用性、コンシステンシロックメカニズム
使用法
すべてのライブラリを日常的にバックアップ
指定した複数のライブラリのバックアップ
指定されたライブラリの指定されたテーブルのバックアップ
バックアップ時にテーブルをロックしない
InnoDBエンジン用に、バックアップ時にログを同じ時刻に発生するまでダンプおよびリフレッシュしたい
--flush-logsは、データのバックアップを開始する前にMySQLサーバログファイルをリフレッシュします.このオプションにはRELOAD権限が必要です.このオプションとオプションを組み合わせて--all-databasesを使用すると、ダンプされたデータベースごとにログがリフレッシュされます.時計をロックします.--single-transactionはInnoDBエンジン用のテーブルで、テーブルをロックせず、ホットスペアとも呼ばれます.
リカバリ
またはmysqlでは、
ファイルが
次に、ダンプ・ファイルのロード時にデータベース名を指定します.
または、mysqlでデータベースを作成し、デフォルトのデータベースとして選択してダンプファイルをロードします.
Example
MySQL物理バックアップ:Innobackupexとxtrabackup(ホットスペア)
Percona XtraBackupはMySQLベースのホットバックアップのオープンソースユーティリティで、5.1～5.7バージョンのInnoDB、XtraDB、MyISAMストレージエンジンのテーブルをバックアップできます.Xtrabackupには2つの主要なツールがあります.xtrabackup、innobackupexです.
元のバージョン
(1)
(2)
新しいバージョンの変更
2.3以前のxtrabackupをインストールした場合は、バックアップ中に2つの一般的なバックアップツールが使用される可能性があります.
バージョン2.3以前のXtraBackupをインストールすると、2つの主要なバックアップツールが得られます. xtrabackup innobackupex
xtrabackupはCプログラムです.
innobackupexはperlスクリプトで、xtrabackupというCプログラムをカプセル化し、innodbテーブルをバックアップするとxtrabackupというCプログラムが呼び出されます.
xtrabackupというCプログラムを使用してバックアップを行う場合、innodbとxtradbのテーブルしかバックアップできず、myisamテーブルはバックアップできません.
innobackupexを使用してバックアップを行う場合は、innodbまたはxtradbのテーブルをバックアップしたり、myisamテーブルをバックアップしたりできます.
したがって、通常、XtraBackupバックアップツールを使用してデータバックアップを行う場合、innobackupexコマンドを使用してバックアップを選択します.
では、問題が来ました.
xtrabackupはCプログラムで、innobackupexはperlスクリプトで、それらが2つのプロセスとして実行されると、いつも特に完璧な方法で通信することはありません.それらが全体として仕事をするときはあまりよくありません.このような状況で、いくつかのバグが発生しました.そこで、公式はCを使ってinnobackupexを書き直し、xtrabackupというCプログラムと完璧に統合することにしました.このアイデアは2.3バージョンのXtraBackupで実現された.
公式マニュアルの解釈
xtrabackupは、MyISAM、InnoDB、XtraDBテーブルを使用してMySQLデータベースインスタンス全体をバックアップする機能を提供するコンパイルされたCバイナリファイルです.
2.4バージョンがインストールされています.この場合、innobackupexの機能はxtrabackupに完全に統合されています.innobackupexはperlスクリプトではありませんが、以前のユーザーの使用習慣と互換性を保つために、innobackupexはソフト接続としてxtrabackupを指しています.つまり、2.4バージョンではinnobackupexコマンドを使用してもxtrabackupコマンドを使用しても、xtrabackupコマンドを使用しても、実はこの
次に、新しいコマンド
まず、
すべてそろっている
次のコマンドはmyにないと仮定します.cnfでxtrabackupに関するオプションを構成するバックアップを実行するには、バックアップデータの配置場所を指定する必要があります.ディレクトリです.ディレクトリが存在しない場合、自動的に作成されます.==このディレクトリは再帰的に作成されず、最後のレベルのディレクトリのみが作成されることに注意してください.==存在する場合は、バックアップが直接開始され、元のデータは上書きされません.
1バックアップの開始
バックアップファイルの表示
ディレクトリに入ると、各データベースのデータファイルバックアップディレクトリと同じ名前のディレクトリが表示されます.また、innodbの共有表領域ファイル、ibdata 1は、xtrabackupを使用して多くのデータベースのいずれかをバックアップする場合は、このデータベースを作成するときにinnodb_が開いていることを保証する必要があります.file_per_tableパラメータ.そうしないと、データベース・サーバ内のデータベースを個別にバックアップできません.先ほど説明したデータファイルに加えて、xtrabackupはいくつかのファイルを生成してくれました.これらのファイルがどのように使われているかを見てみましょう(異なるバージョンのxtrabackupで生成されたファイルは異なる可能性があります).
backup-my.cnfこのファイルにはmyが含まれています.cnfのいくつかの設定情報ですが、myではありません.cnfのすべての情報はこのファイルに含まれ、バックアップに必要な情報のみが含まれています.xtrabackup_binlog_infoはバイナリログを開く必要がありますバックアップ開始時のバイナリログファイルを記録した「位置(position)」xtrabackup_checkpointsこのファイルには、今回のバックアップがそのタイプのバックアップなのか、全量なのか増分なのか、バックアップ時に始まるLSN番号、終了するLSN番号などの情報が記録されています.xtrabackup_info今回バックアップしたサマリー情報は、このファイルの情報が比較的包括的です.xtrabackup_logfileにはバックアップ中のログが記録されており、データをprepareする際にログを介して一致した利用可能なデータに復元する必要があります.
リカバリの準備
xtrabackup--backupオプションを使用してバックアップを行うと、直接使用することはできません.まず、リストアするために準備する必要があります.これらのデータファイルを使用してInnoDBを起動しようとすると、破損を検出してクラッシュし、破損したデータ上で実行しないようにします.バックアップされたデータは一致しないため、同時にバックアップされたトランザクション・ログをバックアップに適用する必要があります.完全で一致し、使用可能なデータを得るには、xtrabackupはこのステップをprepareと呼び、直訳すると「準備」です.xtrabackup--prepareステップでファイルを1つの時点で完全に一致させる
バックアップするデータ量が大きい場合は、バックアップ時間が長くなり、バックアップ中のトランザクション・ログの容量が大きくなる可能性があります.では、--use-memoryオプションを使用して、準備作業の完了を加速することができます.メモリサイズを指定しない場合、準備作業はデフォルトで100 MBのメモリを消費します.サーバに一定の空きメモリがある場合は、xtrabackupに指定したサイズのメモリを使用して準備作業を完了させ、準備作業の完了速度を向上させることができます.例の文は次のとおりです.
==バックアップの準備中にxtrabackupプロセスを中断することは推奨されません.データファイルが破損する可能性があるため、バックアップは使用できません.準備プロセスが中断された場合、バックアップの有効性は保証されません.==
バックアップデータの準備が完了すると、次の情報が表示されるはずです.
リカバリ
xtrabackupはcopybackを実行するとデータベースのmyを読み出す.cnfの構成ですがmy.cnfにdatadirが構成されていない場合は、「datadir」オプションが存在する必要があります.また、datadirディレクトリは空のディレクトリでなければなりません.データは存在しません.そうしないと、上記のコマンドを実行するときにエラーが発生します.--copy-backオプションに対応するディレクトリは、私たちが用意した使用可能なデータのディレクトリです.データを正常に復元するには、まずデータベース・サービスが停止し、対応するデータ・ディレクトリにデータが存在しないことを確認し、データの復元作業を行い、データ・ディレクトリのファイルとログを削除します.
データベースを停止するサービスクリーンアップ環境変更権限データベースを起動する
またはrsyncコマンドを使用する
データベースの起動
innobackuperコマンド実装
フル・バックアップの考え方のまとめ
バックアップコマンドの実行
データベースのユーザー名とパスワードを指定してバックアップ・ディレクトリを指定します.最後のレベルのディレクトリのみを自動的に作成できます.
バックアップデータの準備
つまり、--prepareパラメータは、データの統一と完全性を保証します.
サービスを停止し、mysqlのデータディレクトリの下にあるすべてのファイルとフォルダをクリアします.
/var/lib/mysql/このディレクトリは空でなければなりません
データの復元
本質的には、バックアップしたファイルを指定したmysqlデータディレクトリにコピーすることです.
mysqlデータディレクトリの所有者と所有者グループを変更してMySQLサーバープロセスが起動したユーザー、デフォルトはmysql起動サービス
show master status\G;
2可用性、コンシステンシロックメカニズム
使用法
mysqldump -h -u -p > .sql
/* */
mysqldump --help
すべてのライブラリを日常的にバックアップ
//
shell> vi ~/.mysql_user
[mysqldump]
user=root
password=123
shell> mysqldump --defaults-file=~/.mysql_user -h172.16.153.10 --all-databases > `date +%FT%H_%M_%S`dump_all.sql
# INFORMATION_SCHEMA,performance_schema,sys
指定した複数のライブラリのバックアップ
// ，
// --defaults-file=~/.mysql_user -hip
shell> mysqldump --databases db1 db2 db3 > `date +%FT%H_%M_%S`dump_all.sql
指定されたライブラリの指定されたテーブルのバックアップ
shell> mysqldump db1 t1 t3 t7 > dump.sql
バックアップ時にテーブルをロックしない
InnoDBエンジン用に、バックアップ時にログを同じ時刻に発生するまでダンプおよびリフレッシュしたい
shell> mysqldump --all-databases --single-transaction --flush-logs > `date +%FT%H_%M_%S`dump_all.sql
--flush-logsは、データのバックアップを開始する前にMySQLサーバログファイルをリフレッシュします.このオプションにはRELOAD権限が必要です.このオプションとオプションを組み合わせて--all-databasesを使用すると、ダンプされたデータベースごとにログがリフレッシュされます.時計をロックします.--single-transactionはInnoDBエンジン用のテーブルで、テーブルをロックせず、ホットスペアとも呼ばれます.
リカバリ
shell> mysql < dump.sql
またはmysqlでは、
sourceコマンドを使用します.mysql> source dump.sql
ファイルが
CREATE DATABASE文とUSE文を含まない単一のデータベースダンプの場合は、まず必要に応じてデータベースを作成します.shell> mysqladmin create db1
次に、ダンプ・ファイルのロード時にデータベース名を指定します.
shell> mysql db1 < dump.sq1
または、mysqlでデータベースを作成し、デフォルトのデータベースとして選択してダンプファイルをロードします.
mysql> CREATE DATABASE IF NOT EXISTS db1;
mysql> USE db1;
mysql>source dump.sql
Example
shell> mysql --defaults-file=~/.mysql_user < /backup/2016-12-08-04-mysql-all.sql
MySQL物理バックアップ:Innobackupexとxtrabackup(ホットスペア)
Percona XtraBackupはMySQLベースのホットバックアップのオープンソースユーティリティで、5.1～5.7バージョンのInnoDB、XtraDB、MyISAMストレージエンジンのテーブルをバックアップできます.Xtrabackupには2つの主要なツールがあります.xtrabackup、innobackupexです.
元のバージョン
(1)
xtrabackupはInnoDBとXtraDBの2種類のデータエンジンのデータテーブルのみをバックアップでき、MyISAMデータテーブルはバックアップできない(2)
innobackupexはxtrabackupをカプセル化し,スクリプトパッケージであるためinnodbとmyisamを同時にバックアップ処理できるが,myisamを処理する際にはリードロックを追加する必要がある.新しいバージョンの変更
2.3以前のxtrabackupをインストールした場合は、バックアップ中に2つの一般的なバックアップツールが使用される可能性があります.
バージョン2.3以前のXtraBackupをインストールすると、2つの主要なバックアップツールが得られます.
xtrabackupはCプログラムです.
innobackupexはperlスクリプトで、xtrabackupというCプログラムをカプセル化し、innodbテーブルをバックアップするとxtrabackupというCプログラムが呼び出されます.
xtrabackupというCプログラムを使用してバックアップを行う場合、innodbとxtradbのテーブルしかバックアップできず、myisamテーブルはバックアップできません.
innobackupexを使用してバックアップを行う場合は、innodbまたはxtradbのテーブルをバックアップしたり、myisamテーブルをバックアップしたりできます.
したがって、通常、XtraBackupバックアップツールを使用してデータバックアップを行う場合、innobackupexコマンドを使用してバックアップを選択します.
では、問題が来ました.
xtrabackupはCプログラムで、innobackupexはperlスクリプトで、それらが2つのプロセスとして実行されると、いつも特に完璧な方法で通信することはありません.それらが全体として仕事をするときはあまりよくありません.このような状況で、いくつかのバグが発生しました.そこで、公式はCを使ってinnobackupexを書き直し、xtrabackupというCプログラムと完璧に統合することにしました.このアイデアは2.3バージョンのXtraBackupで実現された.
公式マニュアルの解釈
xtrabackupは、MyISAM、InnoDB、XtraDBテーブルを使用してMySQLデータベースインスタンス全体をバックアップする機能を提供するコンパイルされたCバイナリファイルです.
2.4バージョンがインストールされています.この場合、innobackupexの機能はxtrabackupに完全に統合されています.innobackupexはperlスクリプトではありませんが、以前のユーザーの使用習慣と互換性を保つために、innobackupexはソフト接続としてxtrabackupを指しています.つまり、2.4バージョンではinnobackupexコマンドを使用してもxtrabackupコマンドを使用しても、xtrabackupコマンドを使用しても、実はこの
xtrabackup Cプログラムを使っています.実装は異なるが,動作原理的には従来のバージョンとそれほど変わらない.次に、新しいコマンド
xtrabachupで使用します.まず、
xtrabackupがどのように働いているのかを簡単に理解してみましょう.xtrabackup innodbのcrash-recovery(インスタンスリカバリ)機能に基づいて、copy innodbの物理ファイル(このときデータの一貫性は満たされない)を先に行い、その後redo logに基づいてリカバリを行い、データの一貫性を達成する.すべてそろっている
次のコマンドはmyにないと仮定します.cnfでxtrabackupに関するオプションを構成するバックアップを実行するには、バックアップデータの配置場所を指定する必要があります.ディレクトリです.ディレクトリが存在しない場合、自動的に作成されます.==このディレクトリは再帰的に作成されず、最後のレベルのディレクトリのみが作成されることに注意してください.==存在する場合は、バックアップが直接開始され、元のデータは上書きされません.
1バックアップの開始
shell> xtrabackup --backup --user=root --password='123' --target-dir=/backups/
# ， LSN ， ，xtrabackup page 。
バックアップファイルの表示
[root@mysql-master ~]# ls -lh /data/backups/
13M
-rw-r----- 1 root root 487 8 18 09:44 backup-my.cnf
-rw-r----- 1 root root 293 8 18 09:44 ib_buffer_pool
-rw-r----- 1 root root 12M 8 18 09:44 ibdata1
drwxr-x--- 2 root root 4.0K 8 18 09:44 mysql
drwxr-x--- 2 root root 88 8 18 09:44 one_db
drwxr-x--- 2 root root 8.0K 8 18 09:44 performance_schema
drwxr-x--- 2 root root 58 8 18 09:44 shark_db
drwxr-x--- 2 root root 8.0K 8 18 09:44 sys
-rw-r----- 1 root root 115 8 18 09:44 xtrabackup_checkpoints
-rw-r----- 1 root root 446 8 18 09:44 xtrabackup_info
-rw-r----- 1 root root 2.5K 8 18 09:44 xtrabackup_logfile
ディレクトリに入ると、各データベースのデータファイルバックアップディレクトリと同じ名前のディレクトリが表示されます.また、innodbの共有表領域ファイル、ibdata 1は、xtrabackupを使用して多くのデータベースのいずれかをバックアップする場合は、このデータベースを作成するときにinnodb_が開いていることを保証する必要があります.file_per_tableパラメータ.そうしないと、データベース・サーバ内のデータベースを個別にバックアップできません.先ほど説明したデータファイルに加えて、xtrabackupはいくつかのファイルを生成してくれました.これらのファイルがどのように使われているかを見てみましょう(異なるバージョンのxtrabackupで生成されたファイルは異なる可能性があります).
backup-my.cnfこのファイルにはmyが含まれています.cnfのいくつかの設定情報ですが、myではありません.cnfのすべての情報はこのファイルに含まれ、バックアップに必要な情報のみが含まれています.xtrabackup_binlog_infoはバイナリログを開く必要がありますバックアップ開始時のバイナリログファイルを記録した「位置(position)」xtrabackup_checkpointsこのファイルには、今回のバックアップがそのタイプのバックアップなのか、全量なのか増分なのか、バックアップ時に始まるLSN番号、終了するLSN番号などの情報が記録されています.xtrabackup_info今回バックアップしたサマリー情報は、このファイルの情報が比較的包括的です.xtrabackup_logfileにはバックアップ中のログが記録されており、データをprepareする際にログを介して一致した利用可能なデータに復元する必要があります.
リカバリの準備
xtrabackup--backupオプションを使用してバックアップを行うと、直接使用することはできません.まず、リストアするために準備する必要があります.これらのデータファイルを使用してInnoDBを起動しようとすると、破損を検出してクラッシュし、破損したデータ上で実行しないようにします.バックアップされたデータは一致しないため、同時にバックアップされたトランザクション・ログをバックアップに適用する必要があります.完全で一致し、使用可能なデータを得るには、xtrabackupはこのステップをprepareと呼び、直訳すると「準備」です.xtrabackup--prepareステップでファイルを1つの時点で完全に一致させる
shell> xtrabackup --prepare --target-dir=/data/backups/
バックアップするデータ量が大きい場合は、バックアップ時間が長くなり、バックアップ中のトランザクション・ログの容量が大きくなる可能性があります.では、--use-memoryオプションを使用して、準備作業の完了を加速することができます.メモリサイズを指定しない場合、準備作業はデフォルトで100 MBのメモリを消費します.サーバに一定の空きメモリがある場合は、xtrabackupに指定したサイズのメモリを使用して準備作業を完了させ、準備作業の完了速度を向上させることができます.例の文は次のとおりです.
shell> xtrabackup --prepare --use-memory=512M --target-dir=/backups/
==バックアップの準備中にxtrabackupプロセスを中断することは推奨されません.データファイルが破損する可能性があるため、バックアップは使用できません.準備プロセスが中断された場合、バックアップの有効性は保証されません.==
バックアップデータの準備が完了すると、次の情報が表示されるはずです.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 13596200
180818 10:09:19 completed OK!
リカバリ
xtrabackupはcopybackを実行するとデータベースのmyを読み出す.cnfの構成ですがmy.cnfにdatadirが構成されていない場合は、「datadir」オプションが存在する必要があります.また、datadirディレクトリは空のディレクトリでなければなりません.データは存在しません.そうしないと、上記のコマンドを実行するときにエラーが発生します.--copy-backオプションに対応するディレクトリは、私たちが用意した使用可能なデータのディレクトリです.データを正常に復元するには、まずデータベース・サービスが停止し、対応するデータ・ディレクトリにデータが存在しないことを確認し、データの復元作業を行い、データ・ディレクトリのファイルとログを削除します.
データベースを停止するサービスクリーンアップ環境変更権限データベースを起動する
shell> systemctl stop mysqld.service
shell> rm -rf /var/lib/mysql/*
shell> xtrabackup --copy-back --datadir=/var/lib/mysql --target-dir=/data/backups/
#
180818 10:59:25 [01] ...done
180818 10:59:25 completed OK!
shell> chown mysql.mysql -R /var/lib/mysql
またはrsyncコマンドを使用する
shell> rsync -avrP /data/backup/ /var/lib/mysql/
shell> chown mysql.mysql -R /var/lib/mysql
データベースの起動
shell> systemctl start mysqld.service
innobackuperコマンド実装
shell> innobackupex --defaults-file=/etc/my.cnf --host=192.168.1.146 --user=root --password=123123 /backup
shell> nnobackupex --apply-log --use-memory=4G /backup/2018-08-17_15-53-11
shell> systemctl stop mysqld.service
shell> rm -rf /var/lib/mysql/*
shell> innobackupex --datadir=/var/lib/mysql --copy-back 2018-08-17_15-53-11
shell> chown mysql.mysql -R /var/lib/mysql
shell> systemctl start mysqld.service
フル・バックアップの考え方のまとめ
バックアップコマンドの実行
データベースのユーザー名とパスワードを指定してバックアップ・ディレクトリを指定します.最後のレベルのディレクトリのみを自動的に作成できます.
バックアップデータの準備
つまり、--prepareパラメータは、データの統一と完全性を保証します.
サービスを停止し、mysqlのデータディレクトリの下にあるすべてのファイルとフォルダをクリアします.
/var/lib/mysql/このディレクトリは空でなければなりません
データの復元
本質的には、バックアップしたファイルを指定したmysqlデータディレクトリにコピーすることです.
mysqlデータディレクトリの所有者と所有者グループを変更してMySQLサーバープロセスが起動したユーザー、デフォルトはmysql起動サービス