您的当前位置：首页正文

使用xtrabackup备份恢复Mariadb数据库

2023-11-09 来源：帮我找美食网

Xtrabackup简介

Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具。特点：

(1)备份过程快速、可靠；

(2)备份过程不会打断正在执行的事务；

(3)能够基于压缩等功能节约磁盘空间和流量；

(4)自动实现备份检验；

(5)还原速度快；

官方介绍和下载地址：https://www.percona.com/software/percona-xtrabackup

xtrabackup安装

官方有系统rpm包版的软件，可以下载rpm包版的软件直接安装，由于xtrabackup是使用perl脚本编写的所以需要安装perl-DBD-MySQL否则会报依赖。

[root@MariaDB~]# yum -y install perl-DBD-MySQL[root@MariaDB~]# rpm -ivh percona-xtrabackup-2.2.3-4982.el6.x86_64.rpm

innobackupex: 客户端工具, 以mysql协议连入mysqld，不支持离线备份，但是支持离线恢复

一次完全备份和恢复1、完全备份

使用innobakupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命令的目录中。

在使用innobackupex进行备份时，还可以使用--no-timestamp选项来阻止命令自动创建一个以时间命名的目录；如此一来，innobackupex命令将会创建一个BACKUP-DIR目录来存储备份数据。

示例：

[root@MariaDB~]# innobackupex --user=root --password=centos /backup/[root@MariaDB~]# ll /backup/total4drwxr-xr-x2 root root 4096 Jun 16 02:28 2015-06-16_02-28-54

备份时报了一个错

innobackupex:Error: The xtrabackup child process has died at /usr/bin/innobackupex line2672.

解决方法：修改innodb日志文件大小为5M，修改完成重启服务生效

[root@MariaDB~]# vim /etc/my.cnfinnodb_log_file_size= 5M

备份完成之后在/backup目录下就有了如下内容

[root@MariaDB ~]# ll /backup/2015-06-15_23-49-43/total 18468-rw-r--r-- 1 root root      356 Jun 15 23:49 backup-my.cnfdrwxr-xr-x 2 root root     4096 Jun 15 23:49 hellodb-rw-r----- 1 root root 18874368 Jun 15 23:49ibdata1drwxr-xr-x 2 root root     4096 Jun 15 23:49 mysqldrwxr-xr-x 2 root root     4096 Jun 15 23:49 performance_schemadrwxr-xr-x 2 root root     4096 Jun 15 23:49 test-rw-r--r-- 1 root root       23 Jun 15 23:49 xtrabackup_binlog_info-rw-r----- 1 root root       89 Jun 15 23:49 xtrabackup_checkpoints-rw-r--r-- 1 root root      559 Jun 15 23:49 xtrabackup_info-rw-r----- 1 root root     2560 Jun 15 23:49 xtrabackup_logfile

文件说明：

(1)xtrabackup_checkpoints—— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；

每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。

[root@MariaDB 2015-06-15_23-49-43]# catxtrabackup_checkpointsbackup_type = full-backuped   #备份类型，full-backuped表示完全备份from_lsn = 0                     #日志序列开始to_lsn = 1597945                #最大日志序列号last_lsn = 1597945              #当前日志序列号compact = 0                      #表示没有打包

(2)xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。

[root@MariaDB 2015-06-15_23-49-43]# catxtrabackup_binlog_infomysql-bin.000005  245

(3)backup-my.cnf —— 备份命令用到的配置选项信息和备份无关的不会记录，备份配置文件的话需要单独备份

[root@MariaDB 2015-06-15_23-49-43]# catbackup-my.cnf# This MySQL options file was generated byinnobackupex. # The MySQL server[mysqld]innodb_checksum_algorithm=innodbinnodb_log_checksum_algorithm=innodbinnodb_data_file_path=ibdata1:10M:autoextendinnodb_log_files_in_group=2innodb_log_file_size=5242880innodb_fast_checksum=0innodb_page_size=16384innodb_log_block_size=512innodb_undo_tablespaces=0

（4）xtrabackup_info —— 记录了mariadb的版本信息和一些属性信息，还原是检测版本匹配度时用到

[root@MariaDB 2015-06-15_23-49-43]# catxtrabackup_infouuid = 25b79086-1376-11e5-980a-000c29bad792name =tool_name = innobackupextool_command = --user=root --password=... /backup/tool_version = 1.5.1-xtrabackupibbackup_version = xtrabackup version 2.2.3 basedon MySQL server 5.6.17 Linux (x86_64) (revision id: )server_version = 5.5.43-MariaDB-logstart_time = 2015-06-15 23:49:43end_time = 2015-06-15 23:49:46lock_time = 1binlog_pos = filename ‘mysql-bin.000005‘, position245innodb_from_lsn = 0innodb_to_lsn = 1597945partial = Nincremental = Nformat = filecompact = Ncompressed = Nencrypted = N

2、准备一个完全备份

一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处于不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。

innobakupex命令的--apply-log选项可用于实现上述功能。如下面的命令：

[root@MariaDB 2015-06-15_23-49-43]# innobackupex--apply-log /backup/2015-06-15_23-49-43/

如果执行正确，其最后输出的一行信息通常如下：

150615 23:58:59 innobackupex: completed OK!

在实现“准备”的过程中，innobackupex通常还可以使用--use-memory选项来指定其可以使用的内存的大小，默认通常为100M。如果有足够的内存可用，可以多划分一些内存给prepare的过程，以提高其完成速度。

3、从一个完全备份中恢复数据

innobackupex命令的--copy-back选项用于执行恢复操作，其通过复制所有数据相关的文件至mysql服务器DATADIR目录中来执行恢复过程。innobackupex通过backup-my.cnf来获取DATADIR目录的相关信息。

语法：

# innobackupex --copy-back /path/to/BACKUP-DIR

当数据恢复至DATADIR目录以后，还需要确保所有数据文件的属主和属组均为正确的用户，如mysql，否则，在启动mysqld之前还需要事先修改数据文件的属主和属组。

模拟数据库损坏

删除mariadb数据目录中的所有内容，模拟数据库损坏

[root@MariaDB~]# rm -rf /mydata/data/*[root@MariaDB~]# ll /mydata/data/total0

恢复数据

[root@MariaDB~]# innobackupex --copy-back /backup/2015-06-15_23-49-43/[root@MariaDB ~]# chown -R  mysql:mysql /mydata/data/[root@MariaDB~]# ll /mydata/data/total 28692drwxr-xr-x2 mysql mysql     4096 Jun 16 00:01hellodb-rw-r--r--1 mysql mysql 18874368 Jun 16 00:01 ibdata1-rw-r--r--1 mysql mysql  5242880 Jun 16 00:01ib_logfile0-rw-r--r--1 mysql mysql  5242880 Jun 16 00:01ib_logfile1drwxr-xr-x2 mysql mysql     4096 Jun 16 00:01 mysqldrwxr-xr-x2 mysql mysql     4096 Jun 16 00:01performance_schemadrwxr-xr-x2 mysql mysql     4096 Jun 16 00:01 test-rw-r--r--1 mysql mysql      559 Jun 16 00:01xtrabackup_info

恢复完成之后，还需要启动一下Mysql服务，否则Mariadb是是不会记录二进制日志的，这个时候启动起来是重新记录二进制日志的。

[root@MariaDB ~]# service mysqld start

提示：在恢复完成之后应该再次做一次完全备份，后期的增量备份都依照这次的完全备份来做。

[root@MariaDB ~]# innobackupex --user root --password centos/backup

使用innobackupex进行增量备份

每个InnoDB的页面都会包含一个LSN信息，每当相关的数据发生改变，相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础，即innobackupex通过备份上次完全备份之后发生改变的页面来实现。

要实现第一次增量备份，可以使用下面的命令进行：

# innobackupex --incremental /backup--incremental-basedir=BASEDIR

其中，BASEDIR指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。另外，在执行过增量备份之后再一次进行增量备份时，其--incremental-basedir应该指向上一次的增量备份所在的目录。

需要注意的是，增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。

“准备”(prepare)增量备份与整理完全备份有着一些不同，尤其要注意的是：

(1)需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。“重放”之后，所有的备份数据将合并到完全备份上。

(2)基于所有的备份将未提交的事务进行“回滚”。

于是，操作就变成了：

# innobackupex --apply-log --redo-onlyBASE-DIR

接着执行：

# innobackupex --apply-log --redo-onlyBASE-DIR --incremental-dir=INCREMENTAL-DIR-1

而后是第二个增量：

# innobackupex --apply-log --redo-only BASE-DIR--incremental-dir=INCREMENTAL-DIR-2

其中BASE-DIR指的是完全备份所在的目录，而INCREMENTAL-DIR-1指的是第一次增量备份的目录，INCREMENTAL-DIR-2指的是第二次增量备份的目录，其它依次类推，即如果有多次增量备份，每一次都要执行如上操作；

备份过程

由于上面的完全备份恢复之后又进行了一次完全备份，这里不再进行完全备份，增量备份直接根据上面的完全备份进行。

查看lsn日志的起始和结束位置，第一次增量备份的LSN起始位置就是完全备份LSN的结束位置

[root@MariaDB ~]# cat/backup/2015-06-15_23-45-01/xtrabackup_checkpointsbackup_type = full-backupedfrom_lsn = 0to_lsn = 1602246last_lsn = 1602246compact = 0

修改数据库内容

MariaDB[hellodb]> select * from tb1;+------+|id   |+------+|    1 ||    2 ||    3 ||   21 ||   22 ||   23 |+------+MariaDB[hellodb]> delete from tb1 where id=21;MariaDB[hellodb]> delete from tb1 where id=22;MariaDB[hellodb]> select * from tb1;+------+|id   |+------+|    1 ||    2 ||    3 ||   23 |+------+

第一次增量备份

只需要指向上一次完全备份的位置和这一次增量备份的存储位置即可

[root@MariaDB ~]# innobackupex --user root--password centos --incremental /backup/ --incremental-basedir=/backup/2015-06-15_23-45-01/

备份完成之后查看checkpoints信息

[root@MariaDB ~]# cat/backup/2015-06-15_23-47-02/xtrabackup_checkpointsbackup_type = incremental   #备份类型表示为增量from_lsn = 1602246           #表示备份的起始位置to_lsn = 1604539last_lsn = 1604539compact = 0

再次修改一些数据

MariaDB[hellodb]> insert into tb1 values (1000),(9000);MariaDB[hellodb]> select * from tb1;+------+|id   |+------+|    1 ||    2 ||    3 ||   23 ||1000 ||9000 |+------+

第二次做增量备份

这是备份是基于第一次增量备份进行

[root@MariaDB ~]# innobackupex --user root--password centos --incremental /backup--incremental-basedir=/backup/2015-06-15_23-47-02/[root@MariaDB ~]# cat/backup/2015-06-15_23-51-55/xtrabackup_checkpointsbackup_type = incrementalfrom_lsn = 1604539 #备份起始位置是第一次增量备份的结束位置to_lsn = 1604539last_lsn = 1605623compact = 0

再次修改一次数据，这次修改没有做备份

MariaDB[hellodb]> insert into tb1 values (88888);MariaDB[hellodb]> select * from tb1;+-------+|id    |+-------+|     1 ||     2 ||     3 ||    23 ||  1000 ||  9000 ||88888 |+-------+

说明：由于没有实现将bin-log文件和数据目录分开，所以我先导入二进制日志文件中的修改内容。

查看binlog_info日志位置记录位置为1621，那么只需要把1621之后的修改导出为sql文件即可。

[root@MariaDB~]# cat /backup/2015-06-15_23-51-55/xtrabackup_binlog_info mysql-bin.000005    979  [root@MariaDB ~]# mysqlbinlog --start-position=979/mydata/data/mysql-bin.000005 > /backup/timepoint.sql

模拟损坏

停止mysqld服务，然后删除数据目录下的所有数据，模拟硬盘损坏

[root@MariaDB~]# service mysqld stop[root@MariaDB~]# rm -rf /mydata/data/*

数据恢复

恢复过程：合并完全备份

[root@MariaDB ~]# innobackupex --apply-log-redo-only /backup/2015-06-15_23-45-01/

合并第一个增量备份

[root@MariaDB ~]# innobackupex --apply-log-redo-only /backup/2015-06-15_23-45-01/--incremental-dir=/backup/2015-06-15_23-47-02/

合并第二个增量备份

[root@MariaDB ~]# innobackupex --apply-log-redo-only /backup/2015-06-15_23-45-01/--incremental-dir=/backup/2015-06-15_23-51-55/

使用合并后的命令进行恢复

[root@MariaDB ~]# innobackupex --copy-back/backup/2015-06-15_23-45-01/

设置完成之后修改数据目录的属主属组

[root@MariaDB data]# chown -R mysql.mysql ./*[root@MariaDB data]# lltotal 18452drwxr-xr-x 2 mysql mysql     4096 Jun 16 00:01 hellodb-rw-r--r-- 1 mysql mysql 18874368 Jun 16 00:01ibdata1drwxr-xr-x 2 mysql mysql     4096 Jun 16 00:01 mysqldrwxr-xr-x 2 mysql mysql     4096 Jun 16 00:01 performance_schemadrwxr-xr-x 2 mysql mysql     4096 Jun 16 00:01 test-rw-r--r-- 1 mysql mysql      632 Jun 16 00:01 xtrabackup_info

设置完成之后启动Mysql服务器

[root@MariaDBdata]# service mysqld start

查看数据库这个时候还没有第二次增量备份之后修改的数据

MariaDB[hellodb]> select * from tb1;+------+|id   |+------+|    1 ||    2 ||    3 ||   23 ||1000 ||9000 |+------+

将从二进制导出的sql文件，导入到数据库

[root@MariaDB ~]# mysql -u root -p < /backup/timepoint.sql

查看数据就已经恢复了

MariaDB[hellodb]> select * from tb1;+-------+|id    |+-------+|     1 ||     2 ||     3 ||    23 ||  1000 ||  9000 ||88888 |+-------+

导入或导出单张表

默认情况下，InnoDB表不能通过直接复制表文件的方式在mysql服务器之间进行移植，即便使用了innodb_file_per_table选项。而使用Xtrabackup工具可以实现此种功能，不过，此时需要“导出”表的mysql服务器启用了innodb_file_per_table选项（严格来说，是要“导出”的表在其创建之前，mysql服务器就启用了innodb_file_per_table选项），并且“导入”表的服务器同时启用了innodb_file_per_table和innodb_expand_import选项。

(1)“导出”表

导出表是在备份的prepare阶段进行的，因此，一旦完全备份完成，就可以在prepare过程中通过--export选项将某表导出了：

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

此命令会为每个innodb表的表空间创建一个以.exp结尾的文件，这些以.exp结尾的文件则可以用于导入至其它服务器。

(2)“导入”表

要在mysql服务器上导入来自于其它服务器的某innodb表，需要先在当前服务器上创建一个跟原表表结构一致的表，而后才能实现将表导入：

mysql> CREATE TABLE mytable (...) ENGINE=InnoDB;

然后将此表的表空间删除：

mysql> ALTER TABLEmydatabase.mytable DISCARD TABLESPACE;

接下来，将来自于“导出”表的服务器的mytable表的mytable.ibd和mytable.exp文件复制到当前服务器的数据目录，然后使用如下命令将其“导入”：

mysql> ALTER TABLEmydatabase.mytable IMPORT TABLESPACE;

为了方便称呼，将导出表的服务器称为“源服务器”，导入表的服务器称为目标服务器。

操作：将源服务器hellodb数据库中的tb1表，导出到目标服务器的mydb数据库。源服务器导出表

设置之前先做一次全库备份，因为导出表是根据备份进行导出的

[root@MariaDB~]# innobackupex --user root --password centos /backup/

源服务器导出所有innodb存储引擎的表

[root@MariaDB~]# innobackupex --apply-log --export /backup/2015-06-16_00-14-21/

查看hellodb导出的表文件

[root@MariaDB ~]# ls/backup/2015-06-16_00-14-21/hellodb/classes.frm coc.MYD      courses.MYI  scores.MYI   tb1.cfg  teachers.frm  toc.MYDclasses.MYD coc.MYI      db.opt       students.frm  tb1.exp teachers.MYD  toc.MYIclasses.MYI courses.frm  scores.frm   students.MYD tb1.frm  teachers.MYIcoc.frm     courses.MYD  scores.MYD   students.MYI tb1.ibd  toc.frm

目标服务器导入表准备

目标服务器创建数据库和准备导入的表

创建的表需要和源服务器上面的创建表的时候使用一模一样的命令；源服务器查看创建表的方法如下

MariaDB[hellodb]> show create table tb1;+-------+---------------------------------------------------------------------------------------+|Table | Create Table                                                                         |+-------+---------------------------------------------------------------------------------------+|tb1   | CREATE TABLE `tb1` (  `id` int(11) DEFAULT NULL)ENGINE=InnoDB DEFAULT CHARSET=utf8 |+-------+---------------------------------------------------------------------------------------+

获取到源服务器创建表的命令后，目标服务器就可以直接复制用来创建表

MariaDB[(none)]> create database mydb;MariaDB[(none)]> use mydb;MariaDB[mydb]> CREATE TABLE `tb1` (    ->  `id` int(11) DEFAULT NULL    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;MariaDB[mydb]> show tables;+----------------+|Tables_in_mydb |+----------------+|tb1            |+----------------+

目标服务器需要启用每表一个表空间的选项，此选项我在安装Mariadb时已经开启。

MariaDB[mydb]> show global variables like ‘innodb_file%‘;+--------------------------+----------+|Variable_name            | Value    |+--------------------------+----------+|innodb_file_format       | Antelope ||innodb_file_format_check | ON       ||innodb_file_format_max   | Antelope ||innodb_file_per_table    | ON       |   #此处为ON表示启用+--------------------------+----------+4rows in set (0.00 sec)

目标服务器删除创建表的表空间

MariaDB[mydb]> ALTER TABLE tb1 DISCARD TABLESPACE;

复制表空间文件到远程服务器

[root@MariaDBhellodb]# scp tb1.frm tb1.ibd 172.16.4.10:/mydata/data/mydb

修改属组和属主为Mysql

[root@MariaDB~]# cd /mydata/data/mydb/[root@MariaDBmydb]# lltotal112-rw-rw----1 mysql mysql    65 May 27 22:45 db.opt-rw-rw----1 mysql mysql  8556 May 27 22:53 tb1.frm-rw-r-----1 root  root  98304 May 27 22:53 tb1.ibd[root@MariaDBmydb]# chown -R mysql:mysql tb1.ibd [root@MariaDBmydb]# lltotal112-rw-rw----1 mysql mysql    65 May 27 22:45 db.opt-rw-rw----1 mysql mysql  8556 May 27 22:53 tb1.frm-rw-r-----1 mysql mysql 98304 May 27 22:53 tb1.ibd

重新导入表空间

MariaDB[mydb]> ALTER TABLE tb1 IMPORT TABLESPACE;

查看数据库状态

MariaDB[mydb]> show table status like ‘tb1‘G;ERROR2006 (HY000): MySQL server has gone awayNoconnection. Trying to reconnect...Connectionid:    1Currentdatabase: mydb ***************************1. row ***************************           Name: tb1         Engine: InnoDB        Version: 10     Row_format: Compact           Rows: 8 Avg_row_length: 2048    Data_length: 16384Max_data_length:0   Index_length: 0      Data_free: 0 Auto_increment: NULL    Create_time: 2015-05-27 22:53:24    Update_time: NULL     Check_time: NULL      Collation: utf8_general_ci       Checksum: NULL Create_options:         Comment: 1row in set (0.01 sec) ERROR:No query specified

查看表已经有了数据

MariaDB[mydb]> select * from tb1;+------+|id   |+------+|    1 ||    2 ||    3 ||   23 ||1000 ||9000 |+------+6rows in set (0.01 sec)

补充：如果对于MyISAM存储引擎来说，直接复制三个文件（.frm: 表结构 .MYD：表数据.MYI：表索引）到表目录下即可，MyISAM会自动识别的。

本文出自 “梅花香自苦寒来” 博客，请务必保留此出处http://ximenfeibing.blog.51cto.com/8809812/1664771

使用xtrabackup备份恢复Mariadb数据库

标签：xtrabackup 数据库备份恢复

小编还为您整理了以下内容，可能对您也有帮助：

如何使用xtrabackup备份来恢复到已有mysql上

Xtrabackup 是由 percona 开源的免费数据库热备份软件，它能对 InnoDB 和 XtraDB 存储引擎的数据库非阻塞地备份。

为了方便建立从库，Xtrabackup 在备份完成后会将 binlog position 与 GTID 的相关信息保存于 xtrabackup_binlog_info 文件中。但是当你使用 Xtrabackup 生成的备份建立一个从库时，会发现恢复后的实例执行 show master status，显示的 Executed_Gtid_Set 与 xtrabackup_binlog_info 文件中记录的信息并不一致，而且使用 Xtrabackup 2.4 与 8.0（对 MySQL 8.0 进行备份）生成的备份在恢复后，信息不一致的表现又不相同。本篇文章主要针对该现象进行简单的分析。一、Xtrabackup 2.4.18 for MySQL 5.7.26

现象

1. 使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：# cat xtrabackup_binlog_infomysql-bin.000003 86412752 55d3d9b9-4d49-11ea-932c-02000aba3fa6:1-5958592. 将该备份恢复至一个新实例并启动该实例，执行 show master status; 查看信息：mysql> show master statusG*************************** 1. row *************************** File: mysql-bin.000001 Position: 154 Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 55d3d9b9-4d49-11ea-932c-02000aba3fa6:1-3266611 row in set (0.00 sec)此时会发现使用备份恢复的实例显示已执行过的 GTID 是 1-326661，而备份文件显示的是 1-595859，这是否表示两者相差的 GTID:326662-595859 代表的事务丢失了？通过对原实例（进行备份的实例）的 binlog 进行解析，来查询 GTID:326662-595859 这部分事务所生成的数据在新实例（通过备份恢复的实例）上是否存在。可以发现 GTID:326662-595859 这部分事务的数据都存在于新实例上，也就是说数据与 xtrabackup_binlog_info 文件记录的是一致的，只不过与 show master status 命令获取的信息的不一致。

原因分析

首先我们要清楚 Xtrabackup 2.4 的备份流程，大致如下：

1. start backup

2. copy ibdata1 / copy .ibd file

3. Excuted ftwrl

4. backup non-InnoDB tables and files

5. Writing xtrabackup_binlog_info

6. Executed FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS

7. Executed UNLOCK TABLES

8. Copying ib_buffer_pool

9. completed OK!

结合备份时的 general log 可知，Xtrabackup 在执行 ftwrl 并备份完所有非 InnoDB 表格的文件后通过 show master status 获取了 binlog position 和 GTID 的信息，将其记录到 xtrabackup_binlog_info 文件中。

那么 show master status 获取的是哪些信息？

该命令提供本实例的 binlog 文件的状态信息，显示正在写入的 binlog 文件，以及当前的binlog position，并且 MySQL 5.7 在 MySQL 库下引入了 gtid_executed 表，该表会记录当前执行过的 GTID。

那么目前看来问题可能就出在 gtid_executed 表格上，通过测试和官方文档提供的信息可知，该表格虽然是 InnoDB 表，但是其中的数据并非是实时更新的，且该表格记录信息的方式存在以下两个情况：1. 如果禁用了 log_bin，实例不会在该表格记录任何信息；若从库的 log_slave_updates 为 OFF，那么从库会在应用 relay-log 中的每个事务时执行一次 insert mysql.gtid_executed 的操作。2. 如果启用了 log_bin，则该表格记录的是在 binlog 发生切换（rotate）的时候直到上一个 binlog 文件执行过的全部 GTID，而此时 show master status 获取的 Gtid 信息不再由 mysql.gtid_executed 表提供，而是由全局系统变量 gtid_exected 提供；如果服务器意外停止，则当前 binlog 文件中的 Gtid 集合不会保存在 mysql.gtid_executed 表中，在实例恢复期间，这些 Gtid 从 binlog 文件中读取并添加到表中。

小结

所以当备份恢复时，实际 show master status 可能会出现以下情况：1. 当 log_bin 禁用或者 log_slave_updates 为 OFF 时，备份恢复后的实例 show master status 显示为空。2. 当开启了 log_bin，但是该实例并未发生过 binlog 的切换时，备份恢复后的实例 show master status 显示也为空。3. 当开启了 log_bin，其该实例的 binlog 发生过切换时，备份恢复后的实例 show master status 显示的信息会比 xtrabackup_binlog_info 文件中记录的 GTID 缺失一部分，这一部分就是 mysql.gtid_executed 表格未记录的部分。二、Xtrabackup 8.0.8 for MySQL 8.0.18现象1. 使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：# # cat xtrabackup_binlog_infobinlog.000033 1459 70ec927f-4c6d-11ea-b88c-02000aba3fb1:1-6216832. 查看备份实例相对应的 binlog 解析后的内容：

# mysqlbinlog -vv binlog.000033 | less

定位至 70ec927f-4c6d-11ea-b88c-02000aba3fb1:621683

# at 508

#200213 13:46:47 server id 663728 end_log_pos 583 GTID last_committed=0 sequence_number=2 rbr_only=yes original_committed_timestamp=1581572807720907 immediate_commit_timestamp=15815728

07720907 transaction_length=317

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

# original_commit_timestamp=1581572807720907 (2020-02-13 13:46:47.720907 CST)

# immediate_commit_timestamp=1581572807720907 (2020-02-13 13:46:47.720907 CST)

/*!80001 SET @@session.original_commit_timestamp=1581572807720907*//*!*/;

/*!80014 SET @@session.original_server_version=80018*//*!*/;

/*!80014 SET @@session.immediate_server_version=80018*//*!*/;

SET @@SESSION.GTID_NEXT= '70ec927f-4c6d-11ea-b88c-02000aba3fb1:621683'/*!*/;

# at 583

#200213 13:46:47 server id 663728 end_log_pos 659 Query thread_id=214 exec_time=0 error_code=0

SET TIMESTAMP=1581572807/*!*/;

BEGIN

/*!*/;

# at 659

#200213 13:46:47 server id 663728 end_log_pos 708 Rows_query

# insert into t1 values(null,2)

# at 708

#200213 13:46:47 server id 663728 end_log_pos 758 Table_map: `mysqlslap`.`t1` mapped to number 314

# at 758

#200213 13:46:47 server id 663728 end_log_pos 798 Write_rows: table id 314 flags: STMT_END_F

BINLOG '

x+JEXh2wIAoAMQAAAMQCAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVsbCwyKQ==

x+JEXhOwIAoAMgAAAPYCAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=

x+JEXh6wIAoAKAAAAB4DAAAAADoBAAAAAAEAAgAC/wCKAAEAAgAAAA==

'/*!*/;

### INSERT INTO `mysqlslap`.`t1`

### SET

### @1=65674 /* INT meta=0 nullable=0 is_null=0 */

### @2=2 /* INT meta=0 nullable=1 is_null=0 */

# at 798

#200213 13:46:47 server id 663728 end_log_pos 825 Xid = 2436045

COMMIT/*!*/;

可以发现该文件提供的 binlog position 与 GTID 并不对应。而 binlog.000033:1459 对应的 GTID 是 70ec927f-4c6d-11ea-b88c-02000aba3fb1:621685 提交后的下一个位置：

# at 1142

#200213 13:46:47 server id 663728 end_log_pos 1217 GTID last_committed=2 sequence_number=4 rbr_only=yes original_committed_timestamp=1581572807724646 immediate_commit_timestamp=15815728

07724646 transaction_length=317

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

# original_commit_timestamp=1581572807724646 (2020-02-13 13:46:47.724646 CST)

# immediate_commit_timestamp=1581572807724646 (2020-02-13 13:46:47.724646 CST)

/*!80001 SET @@session.original_commit_timestamp=1581572807724646*//*!*/;

/*!80014 SET @@session.original_server_version=80018*//*!*/;

/*!80014 SET @@session.immediate_server_version=80018*//*!*/;

SET @@SESSION.GTID_NEXT= '70ec927f-4c6d-11ea-b88c-02000aba3fb1:621685'/*!*/;

# at 1217

#200213 13:46:47 server id 663728 end_log_pos 1293 Query thread_id=215 exec_time=0 error_code=0

SET TIMESTAMP=1581572807/*!*/;

BEGIN

/*!*/;

# at 1293

#200213 13:46:47 server id 663728 end_log_pos 1342 Rows_query

# insert into t1 values(null,2)

# at 1342

#200213 13:46:47 server id 663728 end_log_pos 1392 Table_map: `mysqlslap`.`t1` mapped to number 314

# at 1392

#200213 13:46:47 server id 663728 end_log_pos 1432 Write_rows: table id 314 flags: STMT_END_F

BINLOG '

x+JEXh2wIAoAMQAAAD4FAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVsbCwyKQ==

x+JEXhOwIAoAMgAAAHAFAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=

x+JEXh6wIAoAKAAAAJgFAAAAADoBAAAAAAEAAgAC/wCMAAEAAgAAAA==

'/*!*/;

### INSERT INTO `mysqlslap`.`t1`

### SET

### @1=65676 /* INT meta=0 nullable=0 is_null=0 */

### @2=2 /* INT meta=0 nullable=1 is_null=0 */

# at 1432

#200213 13:46:47 server id 663728 end_log_pos 1459 Xid = 2436047

COMMIT/*!*/;

# at 1459

3. 再看将备份恢复到一个新实例并启动后，执行 show master status 显示的信息：mysql> show master statusG*************************** 1. row *************************** File: binlog.000034 Position: 191 Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 70ec927f-4c6d-11ea-b88c-02000aba3fb1:1-6216851 row in set (0.00 sec)

可以发现与 Xtrabackup 2.4 不同的是，该备份的 xtrabackup_binlog_info 文件记录的信息并不准确，而备份恢复后显示的信息却是准确的。

原因

首先我们来看一下 Xtrabackup 8.0 针对 MySQL 8.0 备份的大致过程：1. start backup2. copy .ibd file3. backup non-InnoDB tables and files4. Executed FLUSH NO_WRITE_TO_BINLOG BINARY LOGS5. Selecting LSN and binary log position from p_s.log_status6. copy last binlog file7. Writing /mysql/backup/backup/binlog.index8. Writing xtrabackup_binlog_info9. Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS10. copy ib_buffer_pool11. completed OK!由以上步骤可知，Xtrabackup 8.0 对 MySQL 8.0 的备份与 Xtrabackup 2.4 略有不同，根据 percona 官方文档的信息，当 MySQL 8.0 中仅存在 InnoDB 引擎的表格时，不再执行ftwrl（当存在非 InnoDB 的表格或者使用 --slave-info 选项时会执行），而是根据上述步骤的第 5 步，Xtrabackup 8.0 会通过SELECT server_uuid, local, replication, storage_engines FROM performance_schema.log_status

来获取 LSN 、binlog position and Gtid。1. performance_schema.log_status 是 MySQL 8.0 提供给在线备份工具获取复制日志文件信息的表格。查询 log_status 表时，服务器将阻止日志的记录和相关的更改来获取足够的时间以填充该表，然后释放资源。Log_status 表通知在线备份工具应记录主库的 binlog 的哪个位点和 gtid_executed 的值，还有每个复制通道的 relay log。它还为各个存储引擎提供了相关信息，例如 InnoDB 存储引擎使用的最后一个日志序列号（LSN）和最后一个检查点的 LSN。2. 经过测试发现，当无数据写入时， performance_schema.log_status 提供的 binlog position 与 GTID 是一致的，但是当有大量数据持续写入时，该表格提供的 binlog position 与 GTID 信息将不再一致，如下图：

3. 既然 performance_schema.log_status 提供的信息不一致，那么为什么备份恢复后，GTID 没有缺失？这是因为 Xtrabackup 8.0 在备份过程中多了两步操作，FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 和 copy binlog，Xtrabackup 8.0 在备份完非 InnoDB 表格的文件时会先切换 binlog，然后将切换后的 binlog 也进行备份，这样使用该备份恢复的新实例在启动后不仅会读取 gtid_executed 表，也会读取 binlog 文件来更新 GTID，就可以保持与备份时 xtrabackup_binlog_info 文件记录的 binlog position 保持一致（需要注意的是 MySQL 8.0 的 gtid_executed 表格不再是当 binlog 切换时更新，而是会不断的实时更新，但需要注意在有大量数据写入时也不能做到和全局变量 gtid_exeuted 保持严格一致）。4. 当 MySQL 8.0 中存在非 InnoDB 的表格，比如 MyISAM 表时，Xtrabackup 8.0 会在执行完 FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 后执行 ftwrl，此时查询 performance_schema.log_status 得到的 binlog position 与 GTID 是一致的，且备份恢复后 show master status 显示的信息也与 xtrabackup_binlog_info 文件记录的信息一致。

总结1. Xtrabackup 2.4 备份后生成的 xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，但是备份恢复后 show master status 显示的 GTID 是不准确的。2. Xtrabackup 8.0 在备份只有 InnoDB 表的实例时，xtrabackup_binlog_info 文件记录的 GTID 信息不一定是准确的，但是备份恢复后 show master status 显示的 GTID 是准确的。3. Xtrabackup 8.0 在备份有非 InnoDB 表格的实例时，xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，备份恢复后 show master status 显示的 GTID 也是准确的。

注意：此处的“准确”主要指 xtrabackup_binlog_info 文件中记录的 GTID 与备份中实际的 binlog position & 数据是否一致。

如何使用xtrabackup备份来恢复到已有mysql上

Xtrabackup 是由 percona 开源的免费数据库热备份软件，它能对 InnoDB 和 XtraDB 存储引擎的数据库非阻塞地备份。

现象

原因分析

首先我们要清楚 Xtrabackup 2.4 的备份流程，大致如下：

1. start backup

2. copy ibdata1 / copy .ibd file

3. Excuted ftwrl

4. backup non-InnoDB tables and files

5. Writing xtrabackup_binlog_info

6. Executed FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS

7. Executed UNLOCK TABLES

8. Copying ib_buffer_pool

9. completed OK!

那么 show master status 获取的是哪些信息？

小结

# mysqlbinlog -vv binlog.000033 | less

定位至 70ec927f-4c6d-11ea-b88c-02000aba3fb1:621683

# at 508

#200213 13:46:47 server id 663728 end_log_pos 583 GTID last_committed=0 sequence_number=2 rbr_only=yes original_committed_timestamp=1581572807720907 immediate_commit_timestamp=15815728

07720907 transaction_length=317

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

# original_commit_timestamp=1581572807720907 (2020-02-13 13:46:47.720907 CST)

# immediate_commit_timestamp=1581572807720907 (2020-02-13 13:46:47.720907 CST)

/*!80001 SET @@session.original_commit_timestamp=1581572807720907*//*!*/;

/*!80014 SET @@session.original_server_version=80018*//*!*/;

/*!80014 SET @@session.immediate_server_version=80018*//*!*/;

SET @@SESSION.GTID_NEXT= '70ec927f-4c6d-11ea-b88c-02000aba3fb1:621683'/*!*/;

# at 583

#200213 13:46:47 server id 663728 end_log_pos 659 Query thread_id=214 exec_time=0 error_code=0

SET TIMESTAMP=1581572807/*!*/;

BEGIN

/*!*/;

# at 659

#200213 13:46:47 server id 663728 end_log_pos 708 Rows_query

# insert into t1 values(null,2)

# at 708

#200213 13:46:47 server id 663728 end_log_pos 758 Table_map: `mysqlslap`.`t1` mapped to number 314

# at 758

#200213 13:46:47 server id 663728 end_log_pos 798 Write_rows: table id 314 flags: STMT_END_F

BINLOG '

x+JEXh2wIAoAMQAAAMQCAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVsbCwyKQ==

x+JEXhOwIAoAMgAAAPYCAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=

x+JEXh6wIAoAKAAAAB4DAAAAADoBAAAAAAEAAgAC/wCKAAEAAgAAAA==

'/*!*/;

### INSERT INTO `mysqlslap`.`t1`

### SET

### @1=65674 /* INT meta=0 nullable=0 is_null=0 */

### @2=2 /* INT meta=0 nullable=1 is_null=0 */

# at 798

#200213 13:46:47 server id 663728 end_log_pos 825 Xid = 2436045

COMMIT/*!*/;

可以发现该文件提供的 binlog position 与 GTID 并不对应。而 binlog.000033:1459 对应的 GTID 是 70ec927f-4c6d-11ea-b88c-02000aba3fb1:621685 提交后的下一个位置：

# at 1142

#200213 13:46:47 server id 663728 end_log_pos 1217 GTID last_committed=2 sequence_number=4 rbr_only=yes original_committed_timestamp=1581572807724646 immediate_commit_timestamp=15815728

07724646 transaction_length=317

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

# original_commit_timestamp=1581572807724646 (2020-02-13 13:46:47.724646 CST)

# immediate_commit_timestamp=1581572807724646 (2020-02-13 13:46:47.724646 CST)

/*!80001 SET @@session.original_commit_timestamp=1581572807724646*//*!*/;

/*!80014 SET @@session.original_server_version=80018*//*!*/;

/*!80014 SET @@session.immediate_server_version=80018*//*!*/;

SET @@SESSION.GTID_NEXT= '70ec927f-4c6d-11ea-b88c-02000aba3fb1:621685'/*!*/;

# at 1217

#200213 13:46:47 server id 663728 end_log_pos 1293 Query thread_id=215 exec_time=0 error_code=0

SET TIMESTAMP=1581572807/*!*/;

BEGIN

/*!*/;

# at 1293

#200213 13:46:47 server id 663728 end_log_pos 1342 Rows_query

# insert into t1 values(null,2)

# at 1342

#200213 13:46:47 server id 663728 end_log_pos 1392 Table_map: `mysqlslap`.`t1` mapped to number 314

# at 1392

#200213 13:46:47 server id 663728 end_log_pos 1432 Write_rows: table id 314 flags: STMT_END_F

BINLOG '

x+JEXh2wIAoAMQAAAD4FAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVsbCwyKQ==

x+JEXhOwIAoAMgAAAHAFAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=

x+JEXh6wIAoAKAAAAJgFAAAAADoBAAAAAAEAAgAC/wCMAAEAAgAAAA==

'/*!*/;

### INSERT INTO `mysqlslap`.`t1`

### SET

### @1=65676 /* INT meta=0 nullable=0 is_null=0 */

### @2=2 /* INT meta=0 nullable=1 is_null=0 */

# at 1432

#200213 13:46:47 server id 663728 end_log_pos 1459 Xid = 2436047

COMMIT/*!*/;

# at 1459

可以发现与 Xtrabackup 2.4 不同的是，该备份的 xtrabackup_binlog_info 文件记录的信息并不准确，而备份恢复后显示的信息却是准确的。

原因

注意：此处的“准确”主要指 xtrabackup_binlog_info 文件中记录的 GTID 与备份中实际的 binlog position & 数据是否一致。

Xtrabackup 能不能做单库的备份恢复

大数据量备份与还原，始终是个难点。当MYSQL超10G，用mysqlmp来导出就比较慢了。在这里推荐xtrabackup,这个工具比mysqlmp要快很多。一、Xtrabackup介绍 1、Xtrabackup是什么 Xtrabackup是一个对InnoDB做数据备份的工具，支持在线热备份(备份时不影响数据读写)，是商业备份工具InnoDB Hotbackup的一个很好的替代品。 Xtrabackup有两个主要的工具：xtrabackup、innobackupex 1、xtrabackup只能备份InnoDB和XtraDB两种数据表，而不能备份MyISAM数据表 2、 innobackupex是参考了InnoDB Hotbackup的innoback脚本修改而来的.innobackupex是一个perl脚本封装，封装了xtrabackup。主要是为了方便的同时备份InnoDB和MyISAM引擎的表，但在处理myisam时需要加一个读锁。并且加入了一些使用的选项。如slave-info可以记录备份恢复后，作为slave需要的一些信息，根据这些信息，可以很方便的利用备份来重做slave。 2、Xtrabackup可以做什么 : 在线(热)备份整个库的InnoDB、 XtraDB表在xtrabackup的上一次整库备份基础上做增量备份(innodb only) 以流的形式产生备份，可以直接保存到远程机器上(本机硬盘空间不足时很有用) MySQL数据库本身提供的工具并不支持真正的增量备份，二进制日志恢复是point-in-time(时间点)的恢复而不是增量备份。 Xtrabackup工具支持对InnoDB存储引擎的增量备份，工作原理如下： (1)首先完成一个完全备份，并记录下此时检查点的LSN(Log Sequence Number)。 (2)在进程增量备份时，比较表空间中每个页的LSN是否大于上次备份时的LSN，如果是，则备份该页，同时记录当前检查点的LSN。首先，在logfile中找到并记录最后一个checkpoint(“last checkpoint LSN”)，然后开始从LSN的位置开始拷贝InnoDB的logfile到xtrabackup_logfile；接着，开始拷贝全部的数据文件.ibd；在拷贝全部数据文件结束之后，才停止拷贝logfile。因为logfile里面记录全部的数据修改情况，所以，即时在备份过程中数据文件被修改过了，恢复时仍然能够通过解析xtrabackup_logfile保持数据的一致。因为innobackupex支持innodb,myisam,所以本文说一下，怎么使用innobackupex。二，安装xtrabackup 1、下载地址 /downloads/XtraBackup/ 2、安装根据需求，选择不同的版本，我选择的是rpm安装包，如果报以下错误复制代码代码如下: [root@localhost xtrabackup]# rpm -ivh percona-xtrabackup-2.2.4-5004.el6.x86_64.rpm warning: percona-xtrabackup-2.2.4-5004.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY error: Failed dependencies: perl(Time::HiRes) is needed by percona-xtrabackup-2.2.4-5004.el6.x86_64 解决办法：复制代码代码如下: [root@localhost xtrabackup]# yum -y install perl perl-devel lio lio-devel perl-Time-HiRes perl-DBD-MySQL //安装依赖包 [root@localhost xtrabackup]# rpm -ivh percona-xtrabackup-2.2.4-5004.el6.x86_64.rpm //重新安装 warning: percona-xtrabackup-2.2.4-5004.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY Preparing... ########################################### [100%] 1:percona-xtrabackup ########################################### [100%]

Xtrabackup 能不能做单库的备份恢复

MySQL 常用备份工具流程解析

xtrabackup工具介绍

Percona 公司

官网：www.percona.com
percona-server
InnoDB --> XtraDB

Xtrabackup备份工具

percona提供的mysql数据库备份工具，惟一开源的能够对innodb和xtradb数据库进行热备的工具
手册：https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html

xtrabackup 特点：

备份还原过程快速、可靠

备份过程不会打断正在执行的事务

能够基于压缩等功能节约磁盘空间和流量

自动实现备份检验

开源，免费

xtrabackup工具文件组成

Xtrabackup2.2 版之前包括4个可执行文件：

innobackupex: Perl 脚本

xtrabackup: C/C++，编译的二进制程序

xbcrypt: 加解密

xbstream: 支持并发写的流文件格式

xtrabackup 是用来备份 InnoDB 表的，不能备份非 InnoDB 表，和 MySQL Server 没有交互

innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，还会和MySQL Server 发送命令进行交互，如加全局读锁（FTWRL）、获取位点（SHOW SLAVE STATUS）等。即innobackupex是在 xtrabackup 之上做了一层封装实现的

xtrabackup的新版变化

xtrabackup版本升级到2.4后，相比之前的2.1有了比较大的变化：innobackupex 功能全部集成到
xtrabackup 里面，只有一个 binary程序，另外为了兼容考虑，innobackupex作为 xtrabackup 的软链
接，即xtrabackup现在支持非Innodb表备份，并且 Innobackupex 在下一版本中移除，建议通过
xtrabackup替换innobackupex

xtrabackup备份过程

技术图片

备份生成的相关文件

使用innobackupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相
关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库
配置信息相关的文件。这些文件会被保存至一个以时间命名的目录中,在备份时，innobackupex还会在
备份目录中创建如下文件：

xtrabackup_info：文本文件，innobackupex工具执行时的相关信息，包括版本，备份选项，备份时长，备份LSN(log sequence number日志序列号)，BINLOG的位置

xtrabackup_checkpoints：文本文件，备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN范围信息,每个InnoDB页(通常为16k大小)都会包含一个日志序列号LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的

xtrabackup_binlog_info：文本文件，MySQL服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置，可利用实现基于binlog的恢复

backup-my.cnf：文本文件，备份命令用到的配置选项信息

xtrabackup_logfile：备份生成的二进制日志文件

数据库的·xtrabackup的备份和还原

实战案例：利用xtrabackup完全，增量备份及还原

未完待续

MySQL备份和恢复[4]-xtrabackup备份工具

标签：doc 文件组 number 服务 arc http 文件 percona ber

MySQL 常用备份工具流程解析

xtrabackup工具介绍

Percona 公司

官网：www.percona.com
percona-server
InnoDB --> XtraDB

Xtrabackup备份工具

percona提供的mysql数据库备份工具，惟一开源的能够对innodb和xtradb数据库进行热备的工具
手册：https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html

xtrabackup 特点：

备份还原过程快速、可靠

备份过程不会打断正在执行的事务

能够基于压缩等功能节约磁盘空间和流量

自动实现备份检验

开源，免费

xtrabackup工具文件组成

Xtrabackup2.2 版之前包括4个可执行文件：

innobackupex: Perl 脚本

xtrabackup: C/C++，编译的二进制程序

xbcrypt: 加解密

xbstream: 支持并发写的流文件格式

xtrabackup 是用来备份 InnoDB 表的，不能备份非 InnoDB 表，和 MySQL Server 没有交互

xtrabackup的新版变化

xtrabackup备份过程

技术图片

备份生成的相关文件

xtrabackup_info：文本文件，innobackupex工具执行时的相关信息，包括版本，备份选项，备份时长，备份LSN(log sequence number日志序列号)，BINLOG的位置

xtrabackup_binlog_info：文本文件，MySQL服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置，可利用实现基于binlog的恢复

backup-my.cnf：文本文件，备份命令用到的配置选项信息

xtrabackup_logfile：备份生成的二进制日志文件

数据库的·xtrabackup的备份和还原

实战案例：利用xtrabackup完全，增量备份及还原

未完待续

MySQL备份和恢复[4]-xtrabackup备份工具

标签：doc 文件组 number 服务 arc http 文件 percona ber

linux备份mysql

mysql如何备份和还原数据库？

备份数据库使用mysqlmp命令备份数据库复制代码代码如下:#如果要将game数据库进行备份：mysqlmp-uroot-pgame>game_backup.sql#如果希望备份所有的数据库：mysqlmp-uroot-p--all-databases>all_backup.sql还原数据库

1、使用mysql命令还原数据库将game_backup.sql还原至game数据库：复制代码代码如下:mysql-uroot-pgamegame_backup.sql

2、使用source命令还原数据库如果数据库过大，建议可以使用source命令复制代码代码如下:mysql>sourcegame_backup.sql

mysql备份问题，mysql版本5.7.2？

1、你用mysqlpump压缩备份lz4的后缀名不应该是sql，你要.lz4才行。

mysqlpump--compress-output=LZ4>mp.lz4

lz4_decompressmp.lz4mp.txt

2、mysqlpump和mysqlmp一样，属于逻辑备份，备份以SQL形式的文本保存。

3、这个没啥好建议，你数据库太大了，本来还想说用XtraBackup工具，但是这个只支持linux系统。

MySQL中,备份数据库的命令是？

使用mysqlmp工具进行备份：

1）备份所有数据库：$mysqlmp-uroot-p--all-database>all.sql（2）备份数据库test$mysqlmp-uroot-ptest>test.sql（3）备份数据库test下的表emp$mysqlmp-uroot-ptestemp>emp.sql（4）备份数据库test下的表emp和dept$mysqlmp-uroot-ptestempdept>emp_dept.sql

Mysql实时备份实现方法？

数据备份是数据容灾的最后一道防线，即便有着两地三中心的架构，备份也依然重要。如果备份出问题，备份时影响了交易业务，备份数据无法恢复，这些也是企业难以承受的。所以选择合适的备份工具尤为重要。

每个企业级数据库都会有配套的备份工具，MEB(MySQLEnterpriseBackup)就是MySQL企业版中非常重要的工具之一，是为企业级客户提供的数据备份方案。

Xtrabackup一直作为MEB开源版备胎而存在，从MySQL8.0开始情况可能会变得有所不同。

在MySQL8.0的BackupLock、RedoLogArchiving、PageTracking等新特性的加持下，MEB备份/恢复体验会更好，目前xtrabackup还不支持这些特性。

MySQL企业版还有哪些功能？

特性1：BackupLock

8.0之前使用xtrabackup或MEB做物理备份，为了保证备份时InnoDB引擎表与其他引擎数据文件、及binlog日志的一致性会上全局读锁，再拷贝非InnoDB文件，这期间MySQL会变成只读，数据无法写入。表数量越多，可能加上时间越长，如果使用的xtrabackup不小心没加rsync参数，逐个拷贝frm文件，锁定时间会更长，对业务影响较大。

我曾遇到过部署在虚拟机的实例有12000多张表，当时使用的xtrabackup，备份脚本中没加rsync参数，结果锁了十几分钟，而MEB就没有这样的问题。

MySQL8.0支持轻量级备份锁LOCKINSTANCEFORBACKUP，数据字典也重构了由InnoDB存储。若不创建非InnoDB表，MEB默认使用备份锁获取binlog日志一致性位置，并阻止DDL操作，但不影响DML操作。

只有InnoDB表，仅上备份锁

若有非InnoDB表，上全局锁

特性2：RedoLogArchiving

MEB能做到在线热备，备份时不影响数据库读写，这是利用了InnoDB事务日志，在备份期间持续监视redolog的变化，读取增量变化，写入到ibbackup_logfile，也就不需要上锁来保障备份一致性。(对非InnoDB的文件需要上读锁拷贝)

如果备份期间数据库写入负载特别大，而写入ibbackup_logfile速度较慢，redologsize也不大，很可能会出现ibbackup_logfile的写入速度跟不上redolog记录生成速度，redolog空间不够时需要覆写日志文件，那么来不及写入ibbackup_logfile的记录会丢失，导致备份失败。

MEB4.1对此做了优化，将redolog处理线程拆分成多线程分工合作，提高处理redolog的效率，降低了redolog覆写造成备份失败的概率，但redolog新增速度和ibbackup_logfile写入速度悬殊太大，问题依然会发生。

MySQL8.0.17支持了redologarchiving彻底解决了此问题，备份前设置innodb_redo_log_archive_dirs，指定redolog归档目录。MEB备份时自动开启日志归档，当checkpoint时会将旧记录归档到此目录，后续从归档文件中读取redo日志记录，避免了覆写可能导致的redo记录丢失。

注意：innodb_redo_log_archive_dirs不能在数据目录下，目录权限要求是700

特性3：PageTracking

PageTracking是为优化增量备份效率，减少不必要的数据页扫描。

增量备份当前有3种扫描模式：

page-track：利用LSN精确跟踪上次备份之后被修改页面，仅复制这些页面，效率最快。

optimistic：扫描上次备份之后被修改的InnoDB数据文件中，找出并拷贝修改的页面。依赖系统时间，使用存在。

full-scan：扫描所有InnoDB数据文件，找出并拷贝自上次备份之后修改的页面，效率最慢

1、利用page-track增量备份，需先安装备份组件

2、在全备前开启page-track

3、全备之后，做增量备份时指定若满足pagetracking条件，默认会使用page-track模式，否则会使用full-scan模式，也可以指定--incremental=page-track。

incremental-base有3种选择

last_backup：基于前一次备份做增备，前一次备份可能是增备，也可能是全备。这种方式全备之间可能会有多个增备，每次增量可能比较小，但恢复时需要逐个合并。

last_full_backup：基于前一次全备做增备。这种方式增备会越往后体积可能越大，但恢复时只需要合并最后一次增量备份。

dir：基于前一次的备份目录，前一次备份可能是增备，也可能是全备。

测试对比full-scan和page-track，在变更页小于总体50%的情况下，备份效率至少能有1倍的速度提升。

page-track模式磁盘读写均衡，说明读写的都是修改页面。

full-scan模式磁盘读写差别很大，说明读了很多未修改的页面。

xtrabackup恢复数据有多快

有时候我们需要获取文件的创建时间。

例如：我在研究《xtrabackup 原理图》的时候，想通过观察确认 xtrabackup_log 是最早创建并且是最晚保存的文件。我们就需要知道 xtrabackup_logfile 这个文件的创建时间戳和修改时间戳。

复习：Linux关于文件的三个时间戳

Linux 的文件系统保存有三个时间戳，利用 stat 指令查看文件信息可以获取。他们分别是 ATime、MTime 和 CTime

[root@192-168-199-198 backups]# stat 2.txt File: ‘2.txt’ Size: 16 Blocks: 8 IO Block: 4096 regular fileDevice: 821h/2081d Inode: 15 Links: 1Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)Access: 2019-07-23 12:12:14.276981038 +0800Modify: 2019-07-23 12:12:41.415980158 +0800Change: 2019-07-23 12:12:41.415980158 +0800 Birth: -

ATime ——文件的最近访问时间

只要读取文件，ATime 就会更新，对应的是 stat 命令获取的 Access 的值。

MTime ——文件的内容最近修改的时间

这里不要用vi修改文件内容，因为用vi修改文件内容有可能会引起Inode变更，也就是你观察的文件并不是之前的文件了！这个和vi的原理有关。

CTime ——文件属性最近修改的时间

也说明了，是否能获取文件的创建时间，和文件系统是否支持有关。

Linux 上获取文件创建时间的步骤

常用的 xfs 文件系统是否支持获取文件创建时间，还有如何获取，这个暂时不清楚，需读者查阅官方文档

xtrabackup恢复数据有多快

有时候我们需要获取文件的创建时间。

复习：Linux关于文件的三个时间戳

Linux 的文件系统保存有三个时间戳，利用 stat 指令查看文件信息可以获取。他们分别是 ATime、MTime 和 CTime

ATime ——文件的最近访问时间

只要读取文件，ATime 就会更新，对应的是 stat 命令获取的 Access 的值。

MTime ——文件的内容最近修改的时间

这里不要用vi修改文件内容，因为用vi修改文件内容有可能会引起Inode变更，也就是你观察的文件并不是之前的文件了！这个和vi的原理有关。

CTime ——文件属性最近修改的时间

也说明了，是否能获取文件的创建时间，和文件系统是否支持有关。

Linux 上获取文件创建时间的步骤

常用的 xfs 文件系统是否支持获取文件创建时间，还有如何获取，这个暂时不清楚，需读者查阅官方文档

如何有效地提高 MySQL 的备份和恢复速度

一加速备份

1、加了single-transaction参数备份时需要先flush table with read lock 这个过程中会有一个锁表的过程，如果有事务或语句正在执行，没有结束，那么备份进程会一直等待，并且阻塞别的事务，那么也会影响业务。所以要先确认备份的时候没有大的事务在运行。具体 single-transaction的加锁可以参考我的博客：mysqlmp备份时加single-transaction会不会加锁

2 、mysqlmp是单进程的，没有办法并行，但现在机器的瓶颈多是出现在IO方面，可以使用更了的IO设备加快速度

3 、mysqlmp时如果空间够的话，不要边压缩边备份

二加速恢复

1 关闭binlog:不写入Binlog会大大的加快数据导入的速度

2 innodb_flush_log_at_trx_commit=0

3 更好的配置

建议：

如果非要使用逻辑备份，可以考虑mysqlmper, mysqlpump(5.7)这两个工具去备份，这两个在备份的时候支持并行操作，mysqlmper还可以对单表进行恢复，在只需要恢复单表的情况下，恢复速度会大大加快

使用物理备份 xtrabackup (open source),MEB(oracle提供，收费)：他们的备份原理是基于mysql crash recover，备份速度是和逻辑备份的相差不太大。但是恢复速度却有很大的提升。

逻辑备份备出来的是sql语句文件，恢复时需要一条一条的执行sql,所以恢复很慢。

而物理备份和还原的速度相当于直接copy文件，所以恢复的时候性能有很大的提升

并且这两个软件还支持并行，效果更好。

逻辑备份最大的优点是备份好的文件经压缩后占用空间较小，最大缺点恢复太慢

物理备份可以很快的恢复，但是备份好的文件压缩后占用空间比逻辑备份要大。

Lotus Notes打开某人数据库时提示:不能打开该数据库，因为要对他进行一致性检查.

一般出现一致性检查是由于多人同时修改了数据库内的文件造成的。

光重启是没用的。

先停掉服务器，把data目录下的数据库文件拷贝一份，删除原有的，然后启动服务器。

把拷贝得到的文件放回原目录并签名。追问按照操作尝试过一次,但是还是不行,发现拷贝出来的那份文件已经损坏.我想其实主要问题就是原来那个.nsf的数据库文件坏了,新建一个的话能正常操作,但是原来的文件拿不出来.