MySQL备份和恢复（三）Xtrabackup实现热备：完全备份+增量备份-mysql チュートリアル-php.cn

ホームページ

データベース

mysql チュートリアル

MySQL备份和恢复（三）Xtrabackup实现热备：完全备份+增量备份

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 02:53 PM

mysqlxtrabackupバックアップ成し遂げる回復する

Percona XtraBackup is the world’s only open-source, free MySQL hot backup software that performs non-blocking backups for InnoDB and XtraDB databases. With Percona XtraBackup, you can achieve the following benefits: Backups that complete

Percona XtraBackup is the world’s only open-source, free MySQL hot backup software that performs non-blocking backups for InnoDB and XtraDB databases. With Percona XtraBackup, you can achieve the following benefits:

Backups that complete quickly and reliably
Uninterrupted transaction processing during backups
Savings on disk space and network bandwidth
Automatic backup verification
Higher uptime due to faster restore time

以上摘自官方文档对Xtrabackup的描述。

Xtrabackup是Percona公司的开源mysql热备软件，软件自身支持完全备份和增量备份，功能强大，使用简单，且备份结束会自动检查备份的可用性。对于InnoDB和XtraDB可以实现无阻塞的备份。

Xtrabackup会在备份目录下自动生成以当前日期和时间为名的目录，目录下包含当前备份所有数据文件和丰富的当前备份时的状态信息。

实例演示：

xtrabackup的安装，安装包可从官网下载http://www.percona.com/software/percona-xtrabackup，官方提供了二进制和源码包，根据自己需要下载

/* 下载官方的rpm包安装，xtrabackup要依赖perl-DBD-mysql包，不想手动解决依赖关系可以yum localinstall安装 */
[root@console ~]# yum localinstall --nogpgcheck percona-xtrabackup-2.1.4-656.rhel6.x86_64.rpm -y

/* xtrabackup安装后生成的文件不多 */
[root@console ~]# rpm -ql percona-xtrabackup
/usr/bin/innobackupex        /* 备份时用的命令,会根据mysql版本自动调用xtrabackup_{55,56} */
/usr/bin/innobackupex-1.5.1     
/usr/bin/xbcrypt        /* 提供备份过程加密支持 */
/usr/bin/xbstream        /* 支持流式备份 */
/usr/bin/xtrabackup
/usr/bin/xtrabackup_55    / * 这个和下面那个才是备份过程实际调用的备份程序 */
/usr/bin/xtrabackup_56
/usr/share/doc/percona-xtrabackup-2.1.4
/usr/share/doc/percona-xtrabackup-2.1.4/COPYING    /* 文档只有一个软件授权文件，没有man文档，不过--help给出的帮助信息也比较丰富 */

备份过程：

/* 在库db1中准备一张表tb1，做效果比较用 */
MariaDB [(none)]> CREATE DATABASE db1;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> USE db1
Database changed
MariaDB [db1]> CREATE TABLE `tb1` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `Name` varchar(30) NOT NULL,   `Gender` enum('F','M','O') NOT NULL,   PRIMARY KEY (`id`) );
Query OK, 0 rows affected (0.22 sec)

MariaDB [db1]> DESC tb1;
+--------+-------------------+------+-----+---------+----------------+
| Field  | Type              | Null | Key | Default | Extra          |
+--------+-------------------+------+-----+---------+----------------+
| id     | int(11)           | NO   | PRI | NULL    | auto_increment |
| Name   | varchar(30)       | NO   |     | NULL    |                |
| Gender | enum('F','M','O') | NO   |     | NULL    |                |
+--------+-------------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

MariaDB [db1]> INSERT INTO tb1 (Name,Gender) VALUES ('Tom','M'),('Jerry','F');
Query OK, 2 rows affected (0.05 sec)
Records: 2  Duplicates: 0  Warnings: 0

MariaDB [db1]> SELECT * FROM tb1;
+----+-------+--------+
| id | Name  | Gender |
+----+-------+--------+
|  1 | Tom   | M      |
|  2 | Jerry | F      |
+----+-------+--------+
2 rows in set (0.00 sec)

/* 创建一个用于备份的最小权限的用户 */
MariaDB [(none)]> CREATE USER 'bakuser'@'localhost' IDENTIFIED BY 'backupass';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> REVOKE ALL PRIVILEGES,GRANT OPTION FROM 'bakuser'@'localhost';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> GRANT RELOAD,LOCK TABLES,REPLICATION CLIENT ON *.* TO 'bakuser'@'localhost';
Query OK, 0 rows affected (0.00 sec)

现在先做一次完全备份：

/* 全备只需指定用于备份的用户名、密码和备份路径即可，最后出现innobackupex: completed OK! 则代表备份成功 */
[root@node1 ~]# innobackupex --user=bakuser --password=backupass /innobackup/
innobackupex: Backup created in directory '/innobackup/2014-07-31_09-27-36'
innobackupex: MySQL binlog position: filename 'mysql-bin.000001', position 1270
140731 09:27:39  innobackupex: Connection to database server closed
140731 09:27:40  innobackupex: completed OK!

/* 看一下备份都生成了哪些文件,除了数据库文件外还多了一些文件，注意由于我用root登陆系统，备份后的文件属主属组都是root，恢复后要改为运行mysqld进程的用户，不然mysql起不来 */
[root@node1 ~]# cd /innobackup/2014-07-31_09-27-36/
[root@node1 2014-07-31_09-27-36]# ll
total 18476
-rw-r--r--. 1 root root      260 Jul 31 09:27 backup-my.cnf /* 备份命令用到的配置选项信息 */
drwx------. 2 root root     4096 Jul 31 09:27 db1    
drwx------. 2 root root     4096 Jul 31 09:27 hellodb
-rw-r-----. 1 root root 18874368 Jul 31 09:27 ibdata1
drwx------. 2 root root     4096 Jul 31 09:27 mydb
drwxr-xr-x. 2 root root     4096 Jul 31 09:27 mysql
drwxr-xr-x. 2 root root     4096 Jul 31 09:27 performance_schema
drwxr-xr-x. 2 root root     4096 Jul 31 09:27 test
-rw-r--r--. 1 root root       13 Jul 31 09:27 xtrabackup_binary    /* 记录备份过程实际用的备份程序 */
-rw-r--r--. 1 root root       24 Jul 31 09:27 xtrabackup_binlog_info    /* 记录备份时的二进制日志文件和当前的位置 */
-rw-r-----. 1 root root       89 Jul 31 09:27 xtrabackup_checkpoints    /* 记录备份类型、
状态（是否prepared)、是否压缩、备份的LSN(Log Sequence Number日志序列号）范围等信息 */
-rw-r-----. 1 root root     2560 Jul 31 09:27 xtrabackup_logfile    /* xtrabackup自己的日志文件，新版本中不直接可见 */

[root@node1 2014-07-31_09-27-36]# cat backup-my.cnf 
# This MySQL options file was generated by innobackupex.

# The MySQL server
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=5242880
innodb_fast_checksum=0
innodb_page_size=16384
innodb_log_block_size=512
[root@node1 2014-07-31_09-27-36]# cat xtrabackup_binary 
xtrabackup_55[root@node1 2014-07-31_09-27-36]# 
[root@node1 2014-07-31_09-27-36]# cat xtrabackup_binlog_info 
mysql-bin.000001	1270		
[root@node1 2014-07-31_09-27-36]# cat xtrabackup_checkpoints 
backup_type = full-backuped
from_lsn = 0
to_lsn = 1660869
last_lsn = 1660869
compact = 0
[root@node1 2014-07-31_09-27-36]# file xtrabackup_logfile 
xtrabackup_logfile: data

全备完成后，对数据库做一些修改后再做一次增备：

/* 第一次增量备份,--incremental 备份类型为增量， --incremental-basedir 指定这次增备是相对哪一个备份做的增量,这里是相对全备  */
[root@node1 innobackup]# innobackupex --user=bakuser --password=backupass --incremental /innobackup/ --incremental-basedir=/innobackup/2014-07-31_09-27-36/
innobackupex: Backup created in directory '/innobackup/2014-07-31_11-51-19'
innobackupex: MySQL binlog position: filename 'mysql-bin.000001', position 1525
140731 11:51:48  innobackupex: Connection to database server closed
140731 11:51:48  innobackupex: completed OK!

/* 做些修改，做第二次增备 */
MariaDB [db1]> DELETE FROM tb1 WHERE Name='Tom';
Query OK, 1 row affected (0.09 sec)

MariaDB [db1]> UPDATE tb1 SET Gender='F' WHERE Name='Dongfang Bubai';
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [db1]> SELECT * FROM tb1;
+----+----------------+--------+
| id | Name           | Gender |
+----+----------------+--------+
|  2 | Jerry          | F      |
|  3 | Bob            | M      |
|  4 | Dongfang Bubai | F      |
+----+----------------+--------+
3 rows in set (0.00 sec)

/* incremental-basedir 相对第一次增量的增量 */
[root@node1 innobackup]# innobackupex --user=bakuser --password=backupass --incremental /innobackup/ --incremental-basedir=/innobackup/2014-07-31_11-51-19/
innobackupex: Backup created in directory '/innobackup/2014-07-31_11-59-29'
innobackupex: MySQL binlog position: filename 'mysql-bin.000001', position 1922
140731 11:59:33  innobackupex: Connection to database server closed
140731 11:59:33  innobackupex: completed OK!

/* 第二次增备完成后，再做一些数据修改操作，以模拟实际生产环境数据库突然崩溃场景 */
MariaDB [db1]> INSERT INTO tb1 (Name,Gender) VALUES ('Kangshifu Guamian','O');
Query OK, 1 row affected (0.04 sec)

/* 将二进制日志备份出来一份，生产环境中二进制日志切记不要和数据文件放在一起，
最好不要在同一分区甚至同一物理磁盘, 以免一旦玉石俱焚，悔之晚矣 */
[root@node1 innobackup]# mysql -e 'SHOW MASTER STATUS;'
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |     2168 |              |                  |
+------------------+----------+--------------+------------------+
[root@node1 innobackup]# cp /mydata/data/
aria_log.00000001   hellodb/            ib_logfile1         mysql-bin.000001    node1.bob.org.pid
aria_log_control    ibdata1             mydb/               mysql-bin.index     performance_schema/
db1/                ib_logfile0         mysql/              node1.bob.org.err   test/
[root@node1 innobackup]# cp /mydata/data/mysql-bin.000001 /innobackup/

/* 人工让数据库彻底崩盘 */
[root@node1 innobackup]# service mysqld stop
Shutting down MySQL..                                      [  OK  ]
[root@node1 innobackup]# rm -rf /mydata/data/*

恢复：

xtrabackup的恢复比较特殊，恢复前要先执行prepare过程，prepare主要完成把已提交的事务数据同步到数据文件，未完成的事务则回滚，这是对于只有一个完全备份来说。当还需要结合其他的增备时，则在些过程只需要将已提交的事务同步，未提交的事务则不用回滚，因为在本次备份时未提交的事务可能会在下一备份中已经提交，以避免这种无谓的劳动。

/* 注意 backup_type 和 to_lsn的变化 */
[root@node1 innobackup]# cat 2014-07-31_09-27-36/xtrabackup_checkpoints 
backup_type = full-backuped
from_lsn = 0
to_lsn = 1660869
last_lsn = 1660869
compact = 0 

/* Prepare全备,--apply-log 指定要prepare, --redo-only 只处理已提交事务，未提交的事务则不回滚
 backup_type由full-backuped --> full-prepared */
[root@node1 innobackup]# innobackupex --apply-log --redo-only /innobackup/2014-07-31_09-27-36/
...
140731 15:05:53  innobackupex: completed OK!
[root@node1 innobackup]# cat 2014-07-31_09-27-36/xtrabackup_checkpoints 
backup_type = full-prepared
from_lsn = 0
to_lsn = 1660869
last_lsn = 1660869
compact = 0

/* prepare 增备1， --incremental-dir 增备的路径 */
[root@node1 innobackup]# innobackupex --apply-log --redo-only /innobackup/2014-07-31_09-27-36/ --incremental-dir /innobackup/2014-07-31_11-51-19/

/* 再来看full backup 的 to_lsn 已经 --> 增备1 的 to_lsn了，此时增量1也就退出舞台了 */
[root@node1 innobackup]# cat 2014-07-31_11-51-19/xtrabackup_checkpoints 
backup_type = incremental
from_lsn = 1660869
to_lsn = 1661993
last_lsn = 1661993
compact = 0
[root@node1 innobackup]# cat 2014-07-31_09-27-36/xtrabackup_checkpoints 
backup_type = full-prepared
from_lsn = 0
to_lsn = 1661993
last_lsn = 1661993
compact = 0

/* prepare 增备2，增量1已经prepare上去了，所以基准还是全备，--incremental-dir 指向增量2 */
[root@node1 innobackup]# innobackupex --apply-log /innobackup/2014-07-31_09-27-36/ --incremental-dir=/innobackup/2014-07-31_11-59-29/

/* 完事后再瞅一眼，全备的 to_lsn 已经 --> 增量2 的了 */
[root@node1 innobackup]# cat 2014-07-31_09-27-36/xtrabackup_checkpoints 
backup_type = full-prepared
from_lsn = 0
to_lsn = 1664255
last_lsn = 1664255
compact = 0
[root@node1 innobackup]# cat 2014-07-31_11-59-29/xtrabackup_checkpoints 
backup_type = incremental
from_lsn = 1661993
to_lsn = 1664255
last_lsn = 1664255
compact = 0

至此，恢复的预准备工作已完成，两个增备也完成了历史使命，恢复只要用全备的一个就可以了：

/* 恢复过程灰常简单，恢复过程也不需要启动mysql, 但是备份过程是一定要启动mysql的，因为要以备份用户身份连到Mysql上的嘛 */
[root@node1 innobackup]# innobackupex --copy-back /innobackup/2014-07-31_09-27-36/
/* 现在还不能启动mysql, 对了，属主属组还没改 */
[root@node1 innobackup]# ll /mydata/data/
total 18456
drwxr-xr-x. 2 root root     4096 Jul 31 15:54 db1
drwxr-xr-x. 2 root root     4096 Jul 31 15:54 hellodb
-rw-r--r--. 1 root root 18874368 Jul 31 15:54 ibdata1
drwxr-xr-x. 2 root root     4096 Jul 31 15:54 mydb
drwxr-xr-x. 2 root root     4096 Jul 31 15:54 mysql
drwxr-xr-x. 2 root root     4096 Jul 31 15:54 performance_schema
drwxr-xr-x. 2 root root     4096 Jul 31 15:54 test
[root@node1 innobackup]# chown -R mysql.mysql /mydata/data/*

/* 现在就可以启动了 。。 */
[root@node1 innobackup]# service mysqld start
Starting MySQL.....                                        [  OK  ]

/* 正常启动，数据都在 */
MariaDB [db1]> SELECT * FROM tb1;
+----+----------------+--------+
| id | Name           | Gender |
+----+----------------+--------+
|  2 | Jerry          | F      |
|  3 | Bob            | M      |
|  4 | Dongfang Bubai | F      |
+----+----------------+--------+
3 rows in set (0.00 sec)

再加上最后的二进制日志恢复，整个恢复过程就全搞颠了

[root@node1 innobackup]# cat /innobackup/2014-07-31_11-59-29/xtrabackup_binlog_info 
mysql-bin.000001	1922		
[root@node1 innobackup]# mysqlbinlog --start-position=1922 mysql-bin.000001 > 11.sql
[root@node1 innobackup]# mysql < 11.sql 

MariaDB [(none)]> SELECT * FROM db1.tb1;
+----+-------------------+--------+
| id | Name              | Gender |
+----+-------------------+--------+
|  2 | Jerry             | F      |
|  3 | Bob               | M      |
|  4 | Dongfang Bubai    | F      |
|  5 | Kangshifu Guamian | O      |
+----+-------------------+--------+
4 rows in set (0.01 sec)
/* 二进制日志恢复，kangshifu guamian finnaly O 出锅了 */

To be continued ...

声明

この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

MySQLはオープンソースのリレーショナルデータベース管理システムであり、主にデータを迅速かつ確実に保存および取得するために使用されます。その実用的な原則には、クライアントリクエスト、クエリ解像度、クエリの実行、返品結果が含まれます。使用法の例には、テーブルの作成、データの挿入とクエリ、および参加操作などの高度な機能が含まれます。一般的なエラーには、SQL構文、データ型、およびアクセス許可、および最適化の提案には、インデックスの使用、最適化されたクエリ、およびテーブルの分割が含まれます。

MySQLの重要性：データストレージと管理Apr 12, 2025 am 12:18 AM

MySQLは、データストレージ、管理、クエリ、セキュリティに適したオープンソースのリレーショナルデータベース管理システムです。 1.さまざまなオペレーティングシステムをサポートし、Webアプリケーションやその他のフィールドで広く使用されています。 2。クライアントサーバーアーキテクチャとさまざまなストレージエンジンを通じて、MySQLはデータを効率的に処理します。 3.基本的な使用には、データベースとテーブルの作成、挿入、クエリ、データの更新が含まれます。 4.高度な使用には、複雑なクエリとストアドプロシージャが含まれます。 5.一般的なエラーは、説明ステートメントを介してデバッグできます。 6.パフォーマンスの最適化には、インデックスの合理的な使用と最適化されたクエリステートメントが含まれます。

なぜMySQLを使用するのですか？利点と利点Apr 12, 2025 am 12:17 AM

MySQLは、そのパフォーマンス、信頼性、使いやすさ、コミュニティサポートに選択されています。 1.MYSQLは、複数のデータ型と高度なクエリ操作をサポートし、効率的なデータストレージおよび検索機能を提供します。 2.クライアントサーバーアーキテクチャと複数のストレージエンジンを採用して、トランザクションとクエリの最適化をサポートします。 3.使いやすく、さまざまなオペレーティングシステムとプログラミング言語をサポートしています。 4.強力なコミュニティサポートを提供し、豊富なリソースとソリューションを提供します。

InnoDBロックメカニズム（共有ロック、排他的ロック、意図ロック、レコードロック、ギャップロック、次のキーロック）を説明します。Apr 12, 2025 am 12:16 AM

INNODBのロックメカニズムには、共有ロック、排他的ロック、意図ロック、レコードロック、ギャップロック、次のキーロックが含まれます。 1.共有ロックにより、トランザクションは他のトランザクションが読み取らないようにデータを読み取ることができます。 2.排他的ロックは、他のトランザクションがデータの読み取りと変更を防ぎます。 3.意図ロックは、ロック効率を最適化します。 4。ロックロックインデックスのレコードを記録します。 5。ギャップロックロックインデックス記録ギャップ。 6.次のキーロックは、データの一貫性を確保するためのレコードロックとギャップロックの組み合わせです。

貧弱なMySQLクエリパフォーマンスの一般的な原因は何ですか？Apr 12, 2025 am 12:11 AM

MySQLクエリのパフォーマンスが低いことの主な理由には、インデックスの使用、クエリオプティマイザーによる誤った実行計画の選択、不合理なテーブルデザイン、過剰なデータボリューム、ロック競争などがあります。 1.インデックスがゆっくりとクエリを引き起こし、インデックスを追加するとパフォーマンスが大幅に向上する可能性があります。 2。説明コマンドを使用してクエリ計画を分析し、オプティマイザーエラーを見つけます。 3.テーブル構造の再構築と結合条件を最適化すると、テーブルの設計上の問題が改善されます。 4.データボリュームが大きい場合、パーティション化とテーブル分割戦略が採用されます。 5.高い並行性環境では、トランザクションの最適化とロック戦略は、ロック競争を減らすことができます。

複数の単一列インデックスに対して複合インデックスをいつ使用する必要がありますか？Apr 11, 2025 am 12:06 AM

データベースの最適化では、クエリ要件に従ってインデックス作成戦略を選択する必要があります。1。クエリに複数の列が含まれ、条件の順序が固定されている場合、複合インデックスを使用します。 2。クエリに複数の列が含まれているが、条件の順序が修正されていない場合、複数の単一列インデックスを使用します。複合インデックスは、マルチコラムクエリの最適化に適していますが、単一列インデックスは単一列クエリに適しています。

MySQLでスロークエリを識別して最適化する方法は？（スロークエリログ、Performance_schema）Apr 10, 2025 am 09:36 AM

MySQLスロークエリを最適化するには、slowquerylogとperformance_schemaを使用する必要があります。1。LowerQueryLogを有効にし、しきい値を設定して、スロークエリを記録します。 2。performance_schemaを使用してクエリの実行の詳細を分析し、パフォーマンスのボトルネックを見つけて最適化します。

MySQLおよびSQL：開発者にとって不可欠なスキルApr 10, 2025 am 09:30 AM

MySQLとSQLは、開発者にとって不可欠なスキルです。 1.MYSQLはオープンソースのリレーショナルデータベース管理システムであり、SQLはデータベースの管理と操作に使用される標準言語です。 2.MYSQLは、効率的なデータストレージと検索機能を介して複数のストレージエンジンをサポートし、SQLは簡単なステートメントを通じて複雑なデータ操作を完了します。 3.使用の例には、条件によるフィルタリングやソートなどの基本的なクエリと高度なクエリが含まれます。 4.一般的なエラーには、SQLステートメントをチェックして説明コマンドを使用することで最適化できる構文エラーとパフォーマンスの問題が含まれます。 5.パフォーマンス最適化手法には、インデックスの使用、フルテーブルスキャンの回避、参加操作の最適化、コードの読み取り可能性の向上が含まれます。

See all articles

ホットAIツール

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

脱衣画像を無料で

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

EditPlus 中国語クラック版

サイズが小さく、構文の強調表示、コードプロンプト機能はサポートされていません

メモ帳++7.3.1

使いやすく無料のコードエディター

SecLists

SecLists は、セキュリティテスターの究極の相棒です。これは、セキュリティ評価中に頻繁に使用されるさまざまな種類のリストを 1 か所にまとめたものです。 SecLists は、セキュリティテスターが必要とする可能性のあるすべてのリストを便利に提供することで、セキュリティテストをより効率的かつ生産的にするのに役立ちます。リストの種類には、ユーザー名、パスワード、URL、ファジングペイロード、機密データパターン、Web シェルなどが含まれます。テスターはこのリポジトリを新しいテストマシンにプルするだけで、必要なあらゆる種類のリストにアクセスできるようになります。

MinGW - Minimalist GNU for Windows

このプロジェクトは osdn.net/projects/mingw に移行中です。引き続きそこでフォローしていただけます。 MinGW: GNU Compiler Collection (GCC) のネイティブ Windows ポートであり、ネイティブ Windows アプリケーションを構築するための自由に配布可能なインポートライブラリとヘッダーファイルであり、C99 機能をサポートする MSVC ランタイムの拡張機能が含まれています。すべての MinGW ソフトウェアは 64 ビット Windows プラットフォームで実行できます。