当前位置:   article > 正文

基于Percona XtraBackup 实现MySQL数据库全备&增量备份与恢复

percona

概述

今天主要分享下如何用XtraBackup来实现全备&增量备份与恢复。
参考官方手册: https://www.percona.com/doc/percona-xtrabackup/2.4/index.html

一、Percona Xtrabackup概述

Percona XtraBackup是世界上唯一一款开源的免费MySQL热备份软件,可以为InnoDB和XtraDB数据库执行非阻塞备份。
使用Percona XtraBackup,可以获得以下好处:

  • 快速可靠地完成备份
  • 备份期间不间断的事务处理
  • 节省磁盘空间和网络带宽
  • 自动备份验证
  • 由于恢复时间更快,正常运行时间更长
    Percona XtraBackup对所有版本的Percona Server for MySQL和MySQL进行MySQL热备份。它执行流式、压缩和增量MySQL备份。

注意:
随着Percona XtraBackup 8.0的推出,Percona XtraBackup 2.4将继续支持MySQL和Percona Server 5.6和5.7数据库。由于新的MySQL重做日志和数据字典格式,Percona XtraBackup 8.0.x版本将只与MySQL8.0.x和即将推出的用于MySQL8.0.x的Percona服务器兼容。

1、支持的存储引擎

Percona XtraBackup可以与MySQL和Percona Server for MySQL协同工作。它支持InnoDB、XtraDB和MyRocks存储引擎的完全无阻塞备份。此外,它还可以通过在备份结束时短暂暂停写入操作来备份以下存储引擎:MyISAM、Merge和Archive,包括分区表、触发器和数据库选项。
注意:

  • MyRocks存储引擎的支持在版本8.0.6中添加。
  • Percona XtraBackup 8.0不支持TokuDB存储引擎。

2、MySQL备份工具特性比较

在这里插入图片描述
说明:
1)复制非InnoDB数据时,InnoDB表仍然被锁定。
2)Percona Server for MySQL支持快速增量备份,支持XtraDB更改页面跟踪。
3)Percona XtraBackup支持对任何备份进行加密。MySQL企业备份只支持对单个文件备份进行加密。
4)Percona XtraBackup根据每秒IO操作数执行限制。MySQL企业备份支持操作之间的可配置睡眠时间。
5)Percona XtraBackup跳过辅助索引页,并在准备压缩备份时重新创建它们。MySQL Enterprise Backup跳过未使用的页并重新插入到准备阶段。
6)Percona XtraBackup甚至可以从完整备份中导出单个表,无论InnoDB版本如何。MySQL Enterprise Backup仅在执行部分备份时使用InnoDB 5.6可移植表空间。
7)备份锁是用Percona Server for MySQL中的读锁刷新表的轻量级替代方法。Percona XtraBackup使用它们自动复制非InnoDB数据,以避免阻塞修改InnoDB表的DML查询。

3、Percona XtraBackup有什么特点?

在不暂停数据库的情况下创建热的InnoDB备份
对MySQL进行增量备份
将压缩的MySQL备份流式传输到另一台服务器
在MySQL服务器之间在线移动表
轻松创建新的MySQL复制从属服务器
在不向服务器添加负载的情况下备份MySQL

二、xtrabackup备份过程解析

1、检查与连接的准备阶段

执行备份命令之后,备份开始,XtraBackup工具尝试去连接MySQL服务器,连接成功之后,执行MySQL版本检查,版本检查完毕。使用给定的用户、密码、端口、socket文件连接使用5.7.22版本的MySQL服务器。

2、持续拷贝redo log

这部分内容并没有在备份的输出日志里体现,推测通过开启general log可以看到,也不一定,也许要通过源码才能看到。
修正:我的测试备份环境是一个静止的数据库,在备份时,既没有发生写操作,也没有发生读操作。所以没有看到一直在做"输出看到大量log scanned up to (xxx),对应就是持续扫描redo log"

3、拷贝ibdata1和ibd文件

xtrabackup进程开始执行一系列工作
1、调用系统函数posix_fadvise(),该函数是用来清理缓存的,不太理解此处使用的意图?
2、进入到/data/mysql/mysql3306/data目录下面
3、把打开文件请求限制调整为65535
4、使用以下InnoDB配置:

innodb_data_home_dir = .
#innodb数据存放在当前目录
innodb_data_file_path = ibdata1:100M:autoextend
#innodb共享表空间文件为1个,初始大小为100M,类型为自动扩展
innodb_log_group_home_dir = ./
#innodb日志文件存放在当前目录
innodb_log_files_in_group = 3
#innodb日志文件个数为3个
innodb_log_file_size = 104857600
#innodb日志文件大小为100M
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

5、使用O_DIRECT标志,目的为绕过缓冲区高速缓存,直接把数据传递到文件或设备,实际就是无需缓存来拷贝数据
6、默认使用单线程进行备份
7、日志扫描到2643241字节的位置
8、形成一个表表空间的列表
9、为mysql/plugin分配表空间为2,旧的最大值是0
10、把ibdata1文件拷贝到备份目录下面,直到完成
11、把ibd文件拷贝到备份目录下面,直到所有的ibd文件拷贝完成

4、备份非事务表的准备阶段

innobackupex进程开始执行一系列工作
1、扫描日志文件到2643241,这是已经写入redo的LSN
2、执行FLUSH TABLES,关闭所有打开的表,使用NO_WRITE_TO_BINLOG选项,也就是该语句不会被记录到binlog里面
3、执行FTWRL,使用全局读锁来锁定整个实例

5、备份非事务表

开始拷贝非innodb引擎表和文件,包括所有的.frm文件等,直到所有的都拷贝完成
修正:
.frm文件:保存了每个表的元数据,包括表结构的定义等;
.ibd文件:InnoDB引擎开启了独立表空间(my.ini中配置innodb_file_per_table = 1)产生的存放该表的数据和索引的文件。

6、整个备份完成后的后续工作

1、开始写xtrabackup_binlog_info文件,此处推测,获取执行过的GTID值和位点信息的语句在general log里面有记录
2、执行引擎的日志刷新,也就是把日志刷新到磁盘
3、最后的检查点是2643232字节的位置,也就是数据持久化到的LSN
4、停止拷贝线程
5、扫描日志文件到2643241
6、执行UNLOCK TABLES,释放全局读锁
7、开始拷贝ib_buffer_pool,直到拷贝完成,这是一堆数字,不知道做什么用处,了解的童鞋给我科普下,谢谢。
修正:拷贝缓冲池里的数据,以备恢复后,可以快速加载和预热访问量最高的数据。
8、打印出备份结束的位点和执行过的GTID值
9、写backup-my.cnf文件
10、写xtrabckup_info
11、LSN从2643232到2643241的事务日志拷贝完成
12、打印备份成功的标志,completed OK!

三、实验–xtrabackup全备

1、事前准备

1.1、建用户及授权

The database user needs the following privileges on the tables/databases to be backed up:

  • RELOAD and LOCK TABLES (unless the --no-lock option is specified) in order to FLUSH TABLES WITH READ LOCK and FLUSH ENGINE LOGS prior to start copying the files, and LOCK TABLES FOR BACKUP and LOCK BINLOG FOR BACKUPrequire this privilege when Backup Locks are used,
  • REPLICATION CLIENT in order to obtain the binary log position,
  • CREATE TABLESPACE in order to import tables (see Restoring Individual Tables),
  • PROCESS in order to run SHOW ENGINE INNODB STATUS (which is mandatory), and optionally to see all threads which are running on the server (see Improved FLUSH TABLES WITH READ LOCK handling),
  • SUPER in order to start/stop the slave threads in a replication environment, use XtraDB Changed Page Tracking for Incremental Backups and for Improved FLUSH TABLES WITH READ LOCK handling,
  • CREATE privilege in order to create the PERCONA_SCHEMA.xtrabackup_history database and table,
  • INSERT privilege in order to add history records to the PERCONA_SCHEMA.xtrabackup_history table,
  • SELECT privilege in order to use innobackupex --incremental-history-name or innobackupex --incremental-history-uuid in order for the feature to look up the innodb_to_lsn values in thePERCONA_SCHEMA.xtrabackup_history table.
CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'bkpuser@1234';
GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT,super ON *.* TO 'bkpuser'@'localhost';
FLUSH PRIVILEGES;
  • 1
  • 2
  • 3

1.2、准备测试数据

CREATE DATABASE TEST;
USE TEST;
CREATE TABLE t(id int primary key, name varchar(16),insert_date datetime);
INSERT INTO t VALUES(1,'full1',now()),(2,'full2',now()),(3,'full3',now()),(4,'full4',now()),(5,'full5',now());
  • 1
  • 2
  • 3
  • 4

1.3、创建备份目录

mkdir -p /data/backup/   
  • 1

2、全备

xtrabackup --user=bkpuser --password="bkpuser@1234" --backup --target-dir=/data/backup/
  • 1

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

备份目录下面的各项文件说明
1)xtrabackup_checkpoints —— 备份类型(如完全或增量)、备份状态(如是否已经为prepared状态)和LSN(日志序列号)范围信息;
2)每个InnoDB页(通常为16k大小)都会包含一个日志序列号,即LSN。LSN是整个数据库系统的系统版本号,每个页面相关的LSN能够表明此页面最近是如何发生改变的。
3)xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。
4)xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position
5)xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件;
6)backup-my.cnf —— 备份命令用到的配置选项信息;

3、Preparing a backup

The xtrabackup --prepare step makes the files perfectly consistent at a single instant in time, so you can run InnoDB on them.
You can run the prepare operation on any machine; it does not need to be on the originating server or the server to which you intend to restore. You can copy the backup to a utility server and prepare it there.

xtrabackup --prepare --target-dir=/data/backup
  • 1

在这里插入图片描述
在这里插入图片描述

4、Restoring a Backup

For convenience xtrabackup binary has an xtrabackup --copy-back option, which will copy the backup to the server’s datadir:

--停止目的端数据库
systemctl stop mysqld
--删除数据文件内容
cp -rf /fsl_data/datafile/ /fsl_data/datafile_bak
rm -rf /fsl_data/datafile/*
--恢复数据库
xtrabackup --copy-back --target-dir=/data/backup
--授权
chown -R mysql:mysql datafile
chmod -R 755 datafile
systemctl restart mysqld
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

在这里插入图片描述
在这里插入图片描述

5、重启后校验

systemctl restart mysqld
  • 1

在这里插入图片描述

四、实验–xtrabackup增备

1、基于全备的增备

1.1、插入测试数据

use test;
INSERT INTO t VALUES(6,'incr_1',now()),(7,'incr_2',now());
  • 1
  • 2

1.2、创建目录

mkdir -p /data/backup_incr
  • 1

1.3、基于全备的增备

Now that you have a full backup, you can make an incremental backup based on it. Use the following command

开始第一次增备,只要全备和多个增备的LSN号连续,那么就可以逐个进行恢复。可以再备份目录xtrabackup_checkpoints文件中看到,其中全备的from_lsn=0,增备的from_lsn应该等于上一个增备或者全备的to_lsn

xtrabackup --user=bkpuser --password="bkpuser@1234" --backup --target-dir=/data/backup_incr \
    --incremental-basedir=/data/backup/
  • 1
  • 2

说明:–incremental-basedir是上次全备或者增备出来的文件夹。当第一次增备的时候,一般填上次全备,第二次增备的时候,如果–incremental-basedir填上次全备,那么本次增备就会包含上次全备到现在变化的内容,相当于oracle依次做1级,2级,3级。。。增备如果–incremental-basedir填第一次增备的目录,那么该次增备只包含第一次增备到现在的变化,文件会更小,相当于oracle rman里面每次都做1级增备。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

2、基于增备的增备

2.1、插入数据

use test;
INSERT INTO t VALUES(8,'incr_incr1',now()),(9,'incr_incr2',now());
  • 1
  • 2

2.2、创建目录

mkdir -p /backup/backup_incr2
  • 1

2.3、基于增备的增备

xtrabackup --user=bkpuser --password="bkpuser@1234" --backup --target-dir=/data/backup_incr2 \
    --incremental-basedir=/data/backup_incr
  • 1
  • 2

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

3、prepare

这里依然要做prepare,而且是做两次prepare,第一次是把全备给prepare,不过这次和上次不一样,这次要加入–apply-log-only参数,因为在每个备份过程中,都会碰到一些事务进来执行,而备份结束时可能有些事务并没有执行完毕,所以在默认prepare中这些事务就会被回滚(rollback),而加入了–apply-log-only就不会回滚这些事务,而是等待prepare下次增备。第二次prepare就是准备第一次增备的目录,这个prepare目的就是把第一次增备期间发生的变化写入到全备的目录中去,然后第一次增备的目录就没有用处了,因为我们最终拷贝表空间文件是把增备目录拷贝过去。无论多少个增备,最后prepare的那个增备是不能加–apply-log-only参数的,因为最后一次增备还没有完成的事务就要彻底回滚来保证一致性。

3.1、prepare全备

xtrabackup --prepare --apply-log-only --target-dir=/data/backup
  • 1

3.2、prepare第一次增备

xtrabackup --prepare --apply-log-only --target-dir=/data/backup --incremental-dir=/data/backup_incr
  • 1

3.3、prepare第二次增备

xtrabackup --prepare --target-dir=/data/backup --incremental-dir=/data/backup_incr2
  • 1

在这里插入图片描述

4、Restoring a Backup

For convenience xtrabackup binary has an xtrabackup --copy-back option, which will copy the backup to the server’s datadir:

--停止目的端数据库
systemctl stop mysqld
--删除数据文件内容
cp -rf /fsl_data/datafile/ /fsl_data/datafile_bak
rm -rf /fsl_data/datafile/*
--恢复数据库
xtrabackup --copy-back --target-dir=/data/backup
--授权
chown -R mysql:mysql datafile
chmod -R 755 datafile
systemctl restart mysqld
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

在这里插入图片描述
在这里插入图片描述

5、重启后校验

systemctl restart mysqld
  • 1

在这里插入图片描述

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/2023面试高手/article/detail/522313
推荐阅读
相关标签
  

闽ICP备14008679号