暂无图片
暂无图片
2
暂无图片
暂无图片
暂无图片
首页 / Xtrabackup物理备份与还原

Xtrabackup物理备份与还原

原创 谭磊Terry 恩墨学院 2022-06-01
5400

一、xtrabackup简介

Xtrabackup是一个对InnoDB做数据备份的工具，支持在线热备份（备份时不影响数据读写），是商业备份工具InnoDB Hotbackup的一个很好的替代品。

它能对InnoDB和XtraDB存储引擎的数据库非阻塞地备份（对于MyISAM的备份同样需要加表锁）。

Innobackupex完整备份后生成几个重要文件：

1、xtrabackup特点

  1. 能够对InnoDB实现热备，无需暂停数据库
  2. 能够对MySQL进行增量备份
  3. 对MySQL备份能够实现流式压缩并传输给其他服务器，–stream参数实现
  4. MySQL服务运行时能够在MySQL 服务器之间进行表的迁移
  5. 能够很容易创建一个MySQL从服务器
  6. 备份MySQL时不会增加服务器负担
  7. 自动备份校验
  8. 还原速度快
  9. XtraBackup能够带InnoDB引擎创建的表实现热备，对MyISAM引擎实现温备

 

2、xtrabackup备份原理

在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件。事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时，InnoDB会检查数据文件和事务日志，并执行两个步骤：它应用（前滚）已经提交的事务日志到数据文件，并将修改过但没有提交的数据进行回滚操作。

使用xtrabackup进行还原，需要xtrabackup进行”备份”和”准备”：先将文件全部复制过来，再根据事务日志对部分操作进行回滚，如下描述：

xtrabackup的备份过程。Xtrabackup在启动时会记住log sequence number（LSN），并且复制所有的数据文件。复制过程需要一些时间，所以这期间如果数据文件有改动，那么将会使数据库处于一个不同的时间点。所以，xtrabackup会运行一个后台进程，用于监视事务日志，并从事务日志复制最新的修改。Xtrabackup持续地做这个操作，这些数据改动会写入xtrabackup_logfile文件。xtrabackup自启动开始，就不停的将事务日志中每个数据文件的修改都记录下来。

接下来是准备（prepare）过程。在这个过程中，xtrabackup使用之前复制的事务日志，对各个数据文件执行灾难恢复（就像mysql刚启动时要做的一样）。当这个过程结束后，数据库就可以做恢复还原了。

详细过程

1. 调用xtrabackup对innodb表空间文件（这一瞬间的映像Time1）备份，而在这个innodb表备份期间数据库是不加锁的，外部可以继续往库里增减数据（这才能叫热备份）。而在Time1和Time2这两个时间点之间的改动由一个线程不断地扫innodb log获得(ChangeSet1)，一旦发现redo中有新的日志写入，立刻将日志记入后台日志文件xtrabackup_log中
2. 锁所有库。
3. 以直接拷贝的方式备份frm,MYD,MYI,MRG,TRG,TRN,opt格式的文件。
4. 步骤3中的数据备份完毕时(Time2)，停止扫innodb log的线程，把ChangeSet1的数据拷贝到备份中。
5. 解锁所有库。
6. 终止挂起，备份完毕。

3、Xtrabackup 不备份 binlog 怎么保证一致性

  • 备份时全局锁阶段做的操作
2020-08-17T09:58:36.167905+08:00         2116 Query     FLUSH TABLES WITH READ LOCK
2020-08-17T09:58:36.490928+08:00         2116 Query     SHOW VARIABLES
2020-08-17T09:58:36.498670+08:00         2116 Query     SHOW SLAVE STATUS
2020-08-17T09:58:36.499435+08:00         2116 Query     SHOW MASTER STATUS
2020-08-17T09:58:36.499747+08:00         2116 Query     SHOW VARIABLES
2020-08-17T09:58:36.503341+08:00         2116 Query     FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
2020-08-17T09:58:36.704273+08:00         2116 Query     UNLOCK TABLES
  • 这里最主要是要保证两点：
    • 非事务数据之间一致性；
    • 数据和 binlog 位点的一致性。
  • 其中 FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS，是防止 innodb_flush_log_at_trx_commit 不等于 1 ，redo log没有刷到磁盘。而 SHOW MASTER STATUS 则是为了获取 binlog 位点。

crash recovery 过程要保证“数据和binlog的一致”，因为 crash 后不能出现事务重做提交而 binlog 没记录的情况，这样会导致从库丢失数据。那备份需要考虑的是什么？有两点：

  • 备份恢复后，再基于 binlog 做精确恢复时，--start-position 的位置是正确的，不会重放、漏掉事物；
  • 备份恢复后，作为从库向主库复制数据时，复制起始位置是正确的，不会重放、漏掉事物。

首先我们得知道事务二阶段提交过程中的3个队列 flush、sync、commit 都有排他锁，一个大事务 commit 可能需要几秒钟，那么此时执行 FTWRL 是会被阻塞的，commit 结束后才能取得全局锁，取得全局锁后，执行 commit 会被阻塞：

这保证了 xtrabackup 备份的 redo log 中只有两种事务：已经完成提交的，和还没开始提交的（未执行 commit 的事务可能被后台线程刷盘），不会出现 prepare 状态的事务。另外还有一个知识点：GTID 的生成和写 binlog 缓存是在二阶段提交的 binlog flush 阶段做的。结合起来则说明：FTWRL 后 执行 show master status 获取 binlog 位点，只有完成提交的事务才会在其中，所以这保证了 binlog 位点和 binlog 的一致。

所以在 xtrabackup 的恢复过程，不需要处理 prepare 状态的事务，也就不需要再验证该事务是否在 binlog 中了。

二、软件下载安装

## 下载地址
https://www.percona.com/downloads/XtraBackup/LATEST/

## 下载xtrabackup
wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.14/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.14-1.el7.x86_64.rpm

## 下载libev依赖包
wget https://mirrors.aliyun.com/epel/7/x86_64/Packages/l/libev-4.15-3.el7.x86_64.rpm

## 下载qpress依赖包
## http://www.quicklz.com/
http://www.quicklz.com/qpress-11-linux-x64.tar


## 软件安装
rpm -ivh libev-4.15-7.el7.x86_64.rpm
rpm -ivh percona-xtrabackup-24-2.4.14-1.el7.x86_64.rpm

## 软件验证
innobackupex --version

三、参数说明

1.权限需求

mysql> CREATE USER 'backup'@'localhost' IDENTIFIED BY 'backup';
mysql> GRANT SELECT, INSERT, RELOAD, PROCESS, SUPER, LOCK TABLES, REPLICATION CLIENT, EVENT, CREATE TABLESPACE ON *.* TO 'backup'@'localhost'

mysql> CREATE USER 'backup'@'127.0.0.1' IDENTIFIED BY 'backup';
mysql> GRANT SELECT, INSERT, RELOAD, PROCESS, SUPER, LOCK TABLES, REPLICATION CLIENT, EVENT, CREATE TABLESPACE ON *.* TO 'backup'@'127.0.0.1'

2.备份常用参数

--host/--user/--password/--port
--slave-info
--parallel
--no-timestamp
--compress/--compress-threads
--throttle
--stream
--tmpdir
--extra-lsndir
--kill-long-queries-timeout
--kill-long-query-type
--ftwrl-wait-timeout
--ftwrl-wait-threshold
--ftwrl-wait-query-type
--safe-slave-backup-timeout
--safe-slave-backup
--databases="bak.bak bak1.bak1"

3.恢复常用参数

--use-memory
--apply-log
--redo-only
--parallel
--decompress
--remove-original
--incremental-dir
 

四、备份恢复操作演示

1、全量备份

tar -xvf percona-xtrabackup-2.4.7-Linux-x86_64.tar.gz
cd /app/packages/percona-xtrabackup-2.4.7-Linux-x86_64/bin
innobackupex --defaults-file=/xfjrdb/conf/xfjrdb.cnf  --user=xxx --password=xxx --socket=/xfjrdb/xfjrdb.sock --no-timestamp --slave-info --parallel=4 /databack/xfjrdb/20181128/full

8.0备份方式
/usr/bin/xtrabackup --defaults-file=/xfjrdb/xfjrdb.cnf --host=localhost --user=root --password=123456 --port=3307 --socket=/xfjrdb/xfjrdb10.sock --backup --target-dir=/data/backup

备份到远程服务器上

nohup &
innobackupex --defaults-file=/xfjrdb/conf/xfjrdb.cnf --user=root --password=xxxx --socket=/xfjrdb/xfjrdb187.sock --no-timestamp --slave-info --parallel=4 --stream=tar /xfjrdb/tmpdata |ssh root@100.64.201.40 \ "cat -> /databack/channeldb.tar" >/tmp/xtrabackup.log 2>&1

使用xbstream备份

nohup &
innobackupex --defaults-file=/xfjrdb/xfjrdb.cnf --user=root --password=xxxx --socket=/xfjrdb/xfjrdb187.sock --no-timestamp --slave-info --parallel=4 /databack/xfjrdb --tmpdir=/databack/xfjrdb  --stream=xbstream|gzip >  /databack/xfjrdb/channeldb.tar.gz

使用tar备份

  • 使用--stream=tar备份，压缩、解压、已经压缩后的大小都优于-stream=xbstream,推荐使用--stream=tar方式压缩,解压时还可以配合tar
nohup &
innobackupex --defaults-file=/xfjrdb/conf/xfjrdb.cnf --user=root --password=xxxx --socket=/xfjrdb/xfjrdb187.sock --no-timestamp --slave-info --parallel=4 --tmpdir=/databack/xfjrdb  --stream=tar|gzip > /databack/xfjrdb/channeldb.tar.gz 

nohup &
innobackupex --defaults-file=/xfjrdb/conf/xfjrdb.cnf --user=root --password=xxxx --socket=/xfjrdb/xfjrdb187.sock --no-timestamp --slave-info --parallel=4 --stream=tar ./| cat -> /databack/xfjrdb/channeldb.tar.gz

2、备份还原

  • 合并redo至数据文件
--apply-log 的作用是将 redo log 中的数据页变更日志应用到数据库文件中
--redo-only 的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态，即
innobackupex --apply-log --redo-only /databack/xfjrdb/20181128/full/ 

service xfjrdb stop

清空redo日志、undo日志、共享表空间、数据库目录、binlog、relaylog
rm -rf /xfjrdb/data/{innodb_log,innodb_ts,xfjrdata,undolog,binlog,relaylog}/*
  • 还原备份至数据目录,并拷贝undolog 到MySQL的数据目录,再修改权限，最后重启数据库
1.nohup scp -r /databack/sunfidb/xxx root@100.64.101.172:/databack/sunfidb

2.输入密码

3.按Ctrl+z挂起当前进程,jobs -l 查看进程

4.使用命令bg( bg %n )让挂起的进程继续后台运行，fg %n 将编号为n的任务转前台运行

5.执行
innobackupex --defaults-file=/xfjrdb/conf/xfjrdb.cnf  --copy-back /databack/xfjrdb/20181128/full
chown -R mysql:mysql /xfjrdb/data;chown -R mysql:mysql /app/mysql
  • 启动mysqld。注意：如果克隆从库，由于数据是从其他从库备份的，复制配置信息都会被一并备份，直接启动该实例会自动启动复制线程，所以这里需要加上--skip-slave-start选项
克隆从库还原
mysqld_safe --defaults-file=/xfjrdb/conf/xfjrdb.cnf  --user=mysql --skip-slave-start &

克隆主库还原
service xfjrdb start

mysql_upgrade --defaults-file=/xfjrdb/xfjrdb.cnf --user=root -p   #因为31是老版本，恢复后，导入的系统表是5.7.14的，需要手动升级
service xfjrdb restart 
# 不重启就flush privileges

注意：遇到Can't create/write to file './ib_logfile0',需要把my.cnf中innodb_log_group_home_dir参数删掉
 

  • 新建从库设置gtid_purged
reset master;
reset slave all;
cd /databack/xfjrdb/20181128/full 然后cat xtrabackup_binlog_info，找到相关gtid信息
set global gtid_purged="xxx";

  • 注意：

    • xtrabackup_binlog_pos_innodb 是redo中获取的最后一个提交的事务的位置，也就是写innodb binlog的位置xtrabackup_binlog_info 是show master status中得到的位置，一般以这个为准
    • 如果复制结构中，任意两台服务器uuid重复的话(比如直接冷备份时，auto.conf中的内容是一致的)，在启动复制功能的时候会报错。这时可以删除auto.conf文件再重启mysqld

  • 主从复制

CHANGE MASTER TO MASTER_HOST='192.168.10.81',MASTER_USER='replic',MASTER_PASSWORD='replic_33', master_port=3307,master_auto_position=1;

coremysql
MASTER_USER='repluser',MASTER_PASSWORD='cy58@it', master_port=3306;

或者

CHANGE MASTER TO MASTER_HOST='100.64.101.31',MASTER_USER='replic',MASTER_PASSWORD='replic_33', master_port=3307,MASTER_LOG_FILE='master2-bin.001',MASTER_LOG_POS=41;

 

五、需注意点

  • 主库中的非事务引擎表，在执行备份期间不能发生数据写入，否则会破坏备份数据的一致性，导致后续在从库启动复制时报错。针对该问题的解决：若使用的是 mysqldump ，则可以通过去掉 --single-transaction 选项，使得备份全程加锁， XtraBackup 工具不存在该问题。
  • 在执行数据备份期间，不能对表结构执行变更，否则可能导致备份数据缺失或者文件拷贝过程中报错而终止。针对该问题的解决方法是：若使用的是 mysqldump，可以通过规范来规避或者去除 --single-transaction 选项，使得备份全程加锁；若使用的是 XtraBackup 工具，则只能从规范上进行规避，无法全程加锁。
  • xtrabackup_binlog_info
    • Xtrabackup 2.4 备份生成的 xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，但是备份恢复后 show master status 显示的 GTID 是不准确的
    • Xtrabackup 8.0 在备份只有 Innodb 表的实例时， xtrabackup_binlog_info 文件记录的 GTID 信息不一定是准确的，但是备份恢复后 show master status 显示的 GTID 是准确的
    • Xtrabackup 8.0 在备份有非 Innodb 表的实例时， xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，备份恢复后 show master status 显示的 GTID 是准确的
墨力计划mysqlxtrabackup
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论