MySQL5.7备份恢复工具—Xtrabackup实战

一、基础知识

1、mysql逻辑备份与物理备份的区别

MySQL 备份通常分为两种类型:逻辑备份和物理备份。这两种备份方法各有优缺点,适用于不同的场景。

逻辑备份:

逻辑备份是从数据库中导出数据和结构的 SQL 语句。这种备份通常使用 mysqldump 工具来完成。逻辑备份的主要优点是它具有较高的可移植性,可以在不同架构和版本的 MySQL 服务器上还原。但是,逻辑备份可能需要更长的时间来完成,特别是在处理大型数据库时。

逻辑备份的主要特点:

  1. 生成的备份文件是文本文件,包含 SQL 语句。
  2. 备份和恢复速度相对较慢。
  3. 可移植性好,可以在不同版本和架构的 MySQL 服务器上使用。
  4. 可以选择性地备份和恢复特定的数据库、表或记录。

物理备份:

物理备份是直接复制数据库的数据文件、索引文件和日志文件。这种备份方法通常使用文件系统快照或第三方工具(如 Percona XtraBackup)来完成。物理备份的主要优点是它通常更快,因为它不需要转换数据。然而,物理备份可能不如逻辑备份可移植,因为它依赖于特定的文件系统和操作系统。

物理备份的主要特点:

  1. 生成的备份文件是二进制文件,包含数据库的实际数据文件、索引文件和日志文件。
  2. 备份和恢复速度相对较快。
  3. 可移植性较差,通常只能在相同版本和架构的 MySQL 服务器上使用。
  4. 通常需要停止数据库或在读锁模式下进行备份,以确保数据的一致性。

总之,逻辑备份和物理备份有各自的优缺点,根据不同的应用场景和需求来选择合适的备份方法。

今天我们分享的主角就是大名鼎鼎的mysql物理备份神器-Percona XtraBackup

二、Percona XtraBackup的安装

1、环境描述

  • 操作系统版本:CENTOS 7.9
  • MYSQL数据库版本:5.7
  • 数据库实例端口:3307

2、安装过程

(1)安装yum源

yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm

(2)安装XtraBackup 2.4版本的percona-xtrabackup

安装mysql对应版本的xtrabackup,不同服务器安装不同的版本

  • mysql 5.1 – xtrabackup2.0
  • mysql5.6 –xtrabackup 2.2
  • mysql5.7 –xtrabackup2.4
yum install -y percona-xtrabackup-24.x86_64

(3)常用参数说明

--defaults-file
同xtrabackup的--defaults-file参数
 
--apply-log
在备份目录下,通过应用名称为xtrabackup_logfile的交易日志文件来准备备份。同时,创建新的交易日志。
 
--copy-back
做数据恢复时将备份数据文件拷贝到MySQL服务器的datadir ;
 
--remote-host=HOSTNAME
通过ssh将备份数据存储到进程服务器上;
 
--stream=[tar]
备 份文件输出格式, tar时使用tar4ibd , 该文件可在XtarBackup binary文件中获得.如果备份时有指定--stream=tar, 则tar4ibd文件所处目录一定要在$PATH中(因为使用的是tar4ibd去压缩, 在XtraBackup的binary包中可获得该文件)。
在 使用参数stream=tar备份的时候,你的xtrabackup_logfile可能会临时放在/tmp目录下,如果你备份的时候并发写入较大的话 xtrabackup_logfile可能会很大(5G+),很可能会撑满你的/tmp目录,可以通过参数--tmpdir指定目录来解决这个问题。
 
--tmpdir=DIRECTORY
当有指定--remote-host or --stream时, 事务日志临时存储的目录, 默认采用MySQL配置文件中所指定的临时目录tmpdir
 
--redo-only --apply-log组,
强制备份日志时只redo ,跳过rollback。这在做多个增量备份合并时非常必要。
 
--use-memory=#
指定数据库恢复时使用的内存大小,需要搭配--apply-log参数
 
--throttle=IOS
同xtrabackup的--throttle参数
 
--sleep=是给ibbackup使用的,指定每备份1M数据,过程停止拷贝多少毫秒,也是为了在备份时尽量减小对正常业务的影响,具体可以查看ibbackup的手册 ;
 
--compress[=LEVEL]
对备份数据迚行压缩,仅支持ibbackup,xtrabackup还没有实现;
 
--include=REGEXP
对 xtrabackup参数--tables的封装,也支持ibbackup。备份包含的库表,例如:--include="test.*",意思是要备份 test库中所有的表。如果需要全备份,则省略这个参数;如果需要备份test库下的2个表:test1和test2,则写 成:--include="test.test1|test.test2"。也可以使用通配符,如:--include="test.test*"。
 
--databases=LIST
列出需要备份的databases,如果没有指定该参数,所有包含MyISAM和InnoDB表的database都会被备份;
 
--uncompress
解压备份的数据文件,支持ibbackup,xtrabackup还没有实现该功能;
 
--slave-info,
当备份一个作为复制环境的服务器时,这个参数会自动将CHANGE MASTER语句写到备份中,在恢复备份后,不必执行CHANGE MASTER语句。
 
--socket=SOCKET
指定mysql.sock所在位置,以便备份进程登录mysql.
 
--compact
创建一个不包含第二索引(除了主键之外的索引)的备份
 
--incremental-basedir
以上一次全量或增量备份的路径,作为增量备份的基础。指定这个参数的同时,应该同样指定--incremental参数
 
--incremental
创建增量备份,当指定这个参数的时候,应该指定--incremental-lsn或--incremental-basedir参数,否则将会备份到--incremental-basedir路径
 
--incremental-dir=DIRECTORY
指定增量备份的目录,需要搭配--incremental参数。
 
--no-timestamp
这个参数会让xtrabackup在备份的时候不创建带有时间格式的子文件夹。当指定了这个参数,备份会直接创建在指定的备份目录下。
--tables-file=FILE
 
这个参数会接受一个字符串,这个字符串指定了一个文件,这个文件包含了要备份的表名,格式如database.table,一行一个。
 
--use-memory=# -apply-log 调节内存使用 
 
 --parallel=  多线程拷贝数据文件,使用该参数要考虑线上的数据库的压力的问题,如果线程开启较多,会对硬盘产生交大的压力。

三、 备份与恢复过程

备份目录:/backup/mysql

1、全量备份与恢复

全量备份

innobackupex --defaults-file=/etc/my3307.cnf --host=localhost --port=3307 -S /tmp/mysql.sock --user=root --password='Rootasdf2023' --no-timestamp /backup/mysql/full_`date +%Y-%m-%d_%H-%M-%S_%w`

全量恢复

1、删库并停止数据库。

service mysqld stop

2、备份myql数据目录。

cp -rpf /data/3307/data /data/3307/data_bak

3、日志包含了redo以及undo的操作,应用过程类似与mysql hang机后的recovery操作,完成后备份处于一致性状态。

innobackupex --apply-log  /backup/mysql/full_2023-05-10_14-08-36_3

4、拷贝备份数据至my.cnf文件规定的位置。

innobackupex --defaults-file=/etc/my3307.cnf --copy-back --rsync /backup/mysql/full_2023-05-10_14-08-36_3

5、更改mysql数据目录的权限为mysql。

chown -R mysql:mysql /data/3307/data

6、启动数据库,至此数据恢复完成

/etc/init.d/mysql3307 start

2、增量备份与恢复

(1)增量备份原理

增量备份有两种方法:

方法一:针对全量的basedir做增量。

总是针对全量的basedir做增量,这个方式恢复起来就特别简单了,只需要将最后一次的增量备份合并到全量备份里,就可以恢复了。

第一种方法示例图: 总是将1月1日的全备作为basedir,所以FROM_LSN号总是5000。

方法二:总是针对上一次增量,做增量备份。

总是针对上一次的增量,做增量备份。这个方式的恢复,就要逐一合并了。总是把上一次(最近一次)的备份作为basedir

方法二示意图:

下面介绍的方法是针对第二种的。

(2)增量恢复实验过程

先来一次全备,两次增备

#全备
innobackupex --defaults-file=/etc/my3307.cnf --host=localhost --port=3307 -S /tmp/mysql.sock --user=root --password='Rootasdf2023' --no-timestamp /backup/mysql/full_`date +%Y-%m-%d_%H-%M-%S_%w`

#第一次增备
innobackupex --defaults-file=/etc/my3307.cnf --host=localhost --port=3307 -S /tmp/mysql.sock --user=root --password='Rootasdf2023' --no-timestamp --incremental-basedir=/backup/mysql/full_2023-05-10_14-08-36_3 --incremental /backup/mysql/incr_`date +%Y-%m-%d_%H-%M-%S_%w`

#第二次增备
innobackupex --defaults-file=/etc/my3307.cnf --host=localhost --port=3307 -S /tmp/mysql.sock --user=root --password='Rootasdf2023' --no-timestamp --incremental-basedir=/backup/mysql/incr_2023-05-10_14-11-28_3 --incremental /backup/mysql/incr_`date +%Y-%m-%d_%H-%M-%S_%w`

#备份文件查看

[root@mysqlserver mysql]# ls -l /backup/mysql/
total 4
drwxr-x--- 7 root root 4096 May 10 14:15 full_2023-05-10_14-08-36_3
drwxr-x--- 7 root root  318 May 10 14:11 incr_2023-05-10_14-11-28_3
drwxr-x--- 7 root root  318 May 10 14:14 incr_2023-05-10_14-13-17_3
[root@mysqlserver mysql]#

prepare准备过程

这就是增量备份最麻烦的地方,因为总共做了三次备份,所以先做三次prepare

对全备做prepare:

innobackupex --apply-log --redo-only /backup/mysql/full_2023-05-10_14-08-36_3

对第一次增量prepare:

innobackupex --apply-log --redo-only /backup/mysql/full_2023-05-10_14-08-36_3  --incremental-dir=/backup/mysql/incr_2023-05-10_14-11-28_3

对第二次增量prepare

注意,第二次的增备是最后一次,所以不需要加上–redo-only参数:

innobackupex --apply-log  /backup/mysql/full_2023-05-10_14-08-36_3  --incremental-dir=/backup/mysql/incr_2023-05-10_14-13-17_3

最后一步将两次增量备份和全量做一次合并。

innobackupex --apply-log  /backup/mysql/full_2023-05-10_14-08-36_3

3、恢复数据

(1) 停止mysql服务。

/etc/init.d/mysql3307 stop

(2)模拟删除库(删除之前先备份一下目录 )。

rm -rf /data/3307/data

(3)恢复数据。

innobackupex --defaults-file=/etc/my3307.cnf --copy-back --rsync /backup/mysql/full_2023-05-10_14-08-36_3

(4)修改权限。

chown -R mysql:mysql /data/3307/data

(5)启动数据库,验证相关数据。

/etc/init.d/mysql3307 start

四、常见问题汇总

问题1:

恢复时报Xtrabackup –copy-back fail Can’t create/write to file ‘./undo_001’。

解决方法:

/etc/my.cnf配置文件中注释掉如下代码:

#innodb_undo_directory=.

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/241733.html<

(0)
管理的头像管理
上一篇2025-04-24 11:34
下一篇 2025-04-24 11:35

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注