我见过很多DBA和运维朋友一备份MySQL就下意识敲mysqldump等数据量上了500GB备份时间从半小时变成五六个小时恢复更是遥遥无期这时候才开始着急找方案。其实在MySQL 8.0时代最该优先考虑的备份工具就是Percona XtraBackup 8.0。它是物理备份工具直接拷贝数据文件并跟踪redo log变化备份速度和恢复速度比mysqldump这种逻辑备份快一个量级而且支持在线热备不影响业务读写。这篇教程我不打算只甩几条命令而是把XtraBackup 8.0的版本选择逻辑、三种安装方式、安装后的验证方法、第一次备份恢复实操以及我踩过的坑全部整理出来。不管你是刚接手数据库的新人还是被线上备份搞得焦头烂额的老手照着这篇文章走一遍至少能少走两三天弯路。1. 工具选型XtraBackup 8.0到底解决什么问题1.1 物理备份与逻辑备份的原理差异先说清楚为什么大家都在推XtraBackup。mysqldump是逻辑备份它把表结构、数据记录一条条查出来再拼成SQL语句恢复的时候要一条条执行数据量一大CPU和IO全耗在解析和插入上。而XtraBackup是物理备份它直接调用InnoDB的机制把数据文件按页拷贝出来同时后台持续追踪redo log拷贝结束后再做一次apply保证备份集是一个一致性快照。简单类比一下mysqldump像把一仓库的货一件件登记造册再重新入库XtraBackup则是把整个仓库连货带货架一起搬走速度当然不是一个级别。在实际生产里1TB的MySQL实例用mysqldump全量备份可能要跑上一整天恢复又要大半天而XtraBackup全量备份通常在1小时级别恢复更是直接拷贝文件半小时内基本能搞定。更关键的是XtraBackup 8.0支持在线备份备份期间业务正常读写不会像文件系统快照需要短暂的锁表或停顿。1.2 8.0不是7.x的升级版而是严格对应的版本很多新人有一个误区以为XtraBackup 8.0比2.4版本新所以能备份所有MySQL版本。事实完全相反Percona对版本对应关系卡得非常死XtraBackup版本对应MySQL版本支持的主要特性XtraBackup 2.4MySQL 5.6 / 5.7旧版redo log结构适用于5.7及以前XtraBackup 8.0MySQL 8.0.x新版redo log结构支持8.0的数据字典XtraBackup 8.4MySQL 8.4/9.x对应新LTS版本目前还在快速迭代也就是说如果你的数据库是MySQL 8.0就必须用XtraBackup 8.0系列拿2.4版本去跑会直接报错提示redo log版本不兼容。强行使用不仅备份失败还可能让你误以为数据损坏。反过来如果数据库还是5.7也别急着上8.0老老实实用2.4否则工具根本不认识数据文件结构。这一条请刻在脑子里选型错误是后续所有安装问题的第一根源。2. 安装前必须确认的三件事2.1 确认你的MySQL版本与内核结构安装XtraBackup之前先确认目标数据库的准确版本mysql -u root -p -e SELECT VERSION();假设输出是8.0.34那就锁定XtraBackup 8.0.x。再确认一下数据库的glibc环境、操作系统位数尤其要注意的是Percona二进制包有glibc2.17和glibc2.28等不同编译版本后面我会详细说怎么选。2.2 确认操作系统与glibc版本这一步特别容易被忽略实际踩坑概率极高。XtraBackup是用C编译的二进制程序对glibc版本有硬性要求。你可以用下面命令查看系统glibc版本ldd --version我见过太多CentOS 7机器默认glibc是2.17结果下载了针对glibc2.28编译的XtraBackup包一运行就报GLIBC_2.28 not found整个安装直接卡死。所以先看清楚系统发行版和glibc版本再决定用哪种仓库或哪个tar包顺序千万别反。2.3 三种安装方式怎么选XtraBackup 8.0主流的安装方式有三种各有利弊我给出一个基于实际经验的选择建议Yum仓库CentOS/RHEL官方仓库托管依赖安装最省心适合能访问外网的生产机。APT仓库Ubuntu/Debian同上适合Debian系依赖自动处理。二进制tar包解压离线环境适合内网、无外网或等保要求严格的机器也是我现在最常用的方式因为镜像源经常不稳定而tar包可以提前下载好拷进去就能用。如果环境允许我建议优先走官方仓库因为它会自动处理libev、qpress、perl-DBD-MySQL等依赖。但如果你在金融、政企类项目待过就知道很多数据库服务器根本不能上外网仓库方式直接失效这时候tar包才是救命稻草。两种方式我都会详细讲。3. 实操三种安装方式完整走一遍3.1 CentOS/RHEL用Percona官方Yum仓库安装CentOS 7/8、RockyLinux、AlmaLinux这类系统先装Percona官方yum源配置包yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm装完之后仓库默认状态不一定是开启的要手动启用XtraBackup 8.0对应的软件仓库percona-release enable-only tools release这里解释一下enable-only的意思。Percona仓库里有release、tools、ps-80等多个子仓库如果不加enable-only可能会把Percona Server相关的包也暴露出来容易误装。enable-only tools release的意思是只启用tools和release范围正好覆盖XtraBackup 8.0。然后刷新缓存并安装yum clean all yum makecache yum install -y percona-xtrabackup-80安装完成后查看版本xtrabackup --version正常情况下会输出类似xtrabackup version 8.0.35-30 based on MySQL server 8.0.35 Linux (x86_64)的信息。看到这行字说明你已经成功了一大半。3.2 Ubuntu/Debian用Percona官方APT仓库安装Ubuntu或Debian的流程类似但要先装Percona的apt源配置包。注意lsb_release -sc会自动识别系统代号比如Ubuntu 22.04是jammy20.04是focal不需要手写wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb然后同样启用仓库并更新percona-release enable-only tools release apt update搜索一下包名确认存在apt-cache search percona-xtrabackup-80最后安装apt install -y percona-xtrabackup-80在纯内网Ubuntu环境如果没法用wget拉取deb包可以在一台能上网的同版本机器上先下载好percona-release_latest_all.deb和percona-xtrabackup-80的deb文件再拷贝到离线机器上用dpkg -i加apt -f install的方式补齐依赖。这个方法我实际验证过多次可行。3.3 离线环境二进制tar包安装重点离线环境是很多运维朋友真正需要的地方这里我多写一些细节。去Percona官网的Percona XtraBackup 8.0下载页面选择Linux - Generic分类会看到类似这样的文件名percona-xtrabackup-8.0.35-30-linux-x86_64.glibc2.17.tar.gzpercona-xtrabackup-8.0.35-30-linux-x86_64.glibc2.28.tar.gz关键就在glibc版本那个后缀。CentOS 7或老版本Ubuntu 18.04选glibc2.17CentOS 8/9、Ubuntu 20.04/22.04选glibc2.28一般没问题。如果不确定就用刚才提到的ldd --version查一下。下载后上传到服务器的/opt目录解压cd /opt tar -xzf percona-xtrabackup-8.0.35-30-linux-x86_64.glibc2.17.tar.gz为了便于后续脚本引用我习惯做一个软链把版本号目录映射成无版本目录ln -s /opt/percona-xtrabackup-8.0.35-30-linux-x86_64.glibc2.17 /opt/xtrabackup8再把bin目录加入PATHecho export PATH/opt/xtrabackup8/bin:$PATH /etc/profile.d/xtrabackup.sh source /etc/profile.d/xtrabackup.sh这样做的目的很简单将来升级XtraBackup时只需改软链指向新目录不需要改业务脚本里的命令路径。这个习惯帮我省过不少事。tar包方式还有一个好处它把可执行文件和库文件都打包在一起解压后即可运行。但要注意它仍然依赖操作系统层面的少数动态库比如libev.so.4和libgcrypt.so。如果运行时报缺库用yum或apt安装对应依赖包即可# CentOS/RHEL yum install -y libev rsync perl-DBD-MySQL qpress # Ubuntu/Debian apt install -y libev4 rsync percona-qpressqpress是一个高速压缩工具XtraBackup在压缩备份时会调用它建议一并装好。4. 安装验证与第一次备份恢复4.1 版本输出解读不管用哪种方式安装装完第一件事就是验证版本。执行xtrabackup --version我这里有一份真实的输出参考xtrabackup version 8.0.35-30 based on MySQL server 8.0.35 Linux (x86_64) (revision id: 32c0d33)从这个输出里你能确认三件事工具版本、对应的MySQL基础版本、系统架构。如果输出的版本号是8.0但基于的MySQL server版本是5.7那说明装错包了要立刻卸掉重装。如果命令找不到先检查PATH是否包含bin目录。同时可以用which xtrabackup xbcrypt --version xbstream --versionxbcrypt和xbstream是配套工具。xbstream用于处理流式备份xbcrypt用于加密备份它们和xtrabackup在同一个安装包里。4.2 建备份用户并跑通备份流程XtraBackup连接到MySQL并不强制用root但需要足够的权限。推荐单独建一个备份账号最小权限原则CREATE USER backup_userlocalhost IDENTIFIED BY your_password; GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO backup_userlocalhost; GRANT SELECT ON performance_schema.log_status TO backup_userlocalhost; FLUSH PRIVILEGES;BACKUP_ADMINMySQL 8.0里做在线备份需要的权限。PROCESS允许XtraBackup查看线程信息。RELOAD允许FLUSH TABLES WITH READ LOCK等操作。LOCK TABLES备份带非InnoDB表时需要锁表。REPLICATION CLIENT读取binlog坐标。权限建好后先建好备份目录mkdir -p /data/backups/$(date %Y%m%d)然后执行第一个全量备份xtrabackup --backup \ --target-dir/data/backups/20250120 \ --userbackup_user \ --passwordyour_password \ --host127.0.0.1 \ --port3306 \ --parallel4 \ --compress解释几个关键参数--backup进入备份模式对InnoDB而言是热备份。--target-dir备份输出目录注意目录必须不存在或为空。--parallel4开启4个并行线程针对大实例能显著提速。具体数值一般按CPU核数的一半到三分之二设置。--compress边备份边压缩适合磁盘紧张或远程传输场景。压缩依赖qpress所以之前提到要装。执行完成后观察日志最后几行正常会出现类似completed OK!的提示。有这句话才算备份成功。4.3 prepare和copy-back彻底确认安装没问题备份完成后备份集处于“运行时不一致”的状态不能直接用。必须先做prepare前滚回滚操作xtrabackup --prepare --target-dir/data/backups/20250120prepare过程会应用备份期间收集到的redo log把数据文件恢复到一致状态。对于增量备份prepare需要分多步按--incremental-basedir顺序合并。全量备份的话一条命令搞定。在把备份集恢复到目标实例之前最好先做一次考验xtrabackup --copy-back --target-dir/data/backups/20250120copy-back会把备份集里的文件复制回MySQL数据目录。这里有两个前提数据目录必须为空并且启动MySQL的OS用户要有写权限。如果使用的是类似/var/lib/mysql的目录要先确保属主和属组正确chown -R mysql:mysql /var/lib/mysql systemctl start mysqld以前我犯过一个低级错误prepare之后直接cp -r把文件覆盖到数据目录结果忽略了文件属主全变成了rootMySQL起不来。后来统一用--copy-back解决它会在复制后提示你确认属主。如果备份集是压缩格式要记得在copy-back前先解压。XtraBackup支持--decompress参数必须在prepare之后、copy-back之前执行xtrabackup --decompress --target-dir/data/backups/20250120 xtrabackup --prepare --target-dir/data/backups/20250120 xtrabackup --copy-back --target-dir/data/backups/20250120注意顺序先解压再prepare如果先prepare再decompressredo log的apply会出问题这一步顺序非常重要。5. 常见问题与排查实录5.1 GLIBC_2.28 not found这是离线二进制方式最常遇到的报错。执行xtrabackup时直接给一句./xtrabackup: /lib64/libc.so.6: version GLIBC_2.28 not found原因很简单系统glibc版本低于工具编译时要求的版本。CentOS 7默认glibc是2.17去升级系统glibc是风险极大的操作很可能把整个系统搞坏。正确解法是重新下载对应glibc2.17编译的版本或者改用官方yum仓库安装仓库会选择合适的构建版本。5.2 libev.so.4: cannot open shared object file另一种典型的动态库缺失问题。通常是因为机器上有Percona的yum仓库但没自动装上libev。解决办法yum install -y libev注意CentOS 8以上默认源里可能没有libev需要epel源yum install -y epel-release yum install -y libev5.3 Target directory exists and is not empty执行--backup时报这个错一般有两个原因一是上次备份的中间文件没清理二是指定的目录已经被占用。XtraBackup很谨慎目标目录非空就不干活防止覆盖。处理方式# 确认目录内容确实不需要后 rm -rf /data/backups/20250120在某些有审计要求的项目里不建议直接rm而是把旧备份目录移到归档区然后重新创建空目录。而且我建议备份脚本里加一个自动清理策略比如保留最近7天因为一旦磁盘被备份集占满MySQL比备份失败更让人头疼。5.4 MySQL连接失败Authentication plugin caching_sha2_passwordMySQL 8.0默认创建用户时用的是caching_sha2_password插件XtraBackup在某种情况下可能连不上尤其是通过IP非SSL方式连接时。日志里会出现Failed to connect to MySQL server: Authentication plugin caching_sha2_password cannot be loaded:解决方案有两个方向给备份用户指定mysql_native_password插件CREATE USER backup_userlocalhost IDENTIFIED WITH mysql_native_password BY your_password;或者保持默认插件但连接时加上SSL参数xtrabackup --backup --ssl-modeREQUIRED ...我个人推荐用第二种因为MySQL 8.0官方已经在逐步淘汰native_password新项目没必要为了一个备份工具改变认证策略。5.5 备份目录空间不足导致备份失败这个报错出现时日志通常一大片但不一定显眼No space left on deviceXtraBackup备份时的临时文件、undo日志都写在target-dir下空间计算千万别只按数据文件大小来要考虑压缩率、redo log增长和并行拷贝的临时文件。一般建议备份目录预留至少数据文件大小的1.5倍。如果你开启了--compress压力会小一些但也别卡得太紧。5.6 prepare后MySQL启动报错还有一种常见情况prepare完成后把数据目录整体copy到新机器MySQL启动时报[ERROR] InnoDB: ... Table mysql.engine_cost doesnt exist这个大概率是拷贝backup目录时漏掉了隐藏文件或权限不对。XtraBackup备份集里有些点开头的文件比如.ram文件拷贝时如果用了不带-a的cp命令很容易漏掉。用copy-back或者cp -a来拷贝就没有这个问题。6. 关于安装和备份最后分享几点经验网上安装教程一搜一大把但真正到了生产环境我建议你在操作前先做一次预演搭一台和线上同版本的MySQL实例在线下把整个备份恢复流程完整跑通。我以前接手过一个项目线上MySQL 8.0.28CentOS 7.9我直接在预发布环境验证了XtraBackup 8.0.35的备份和恢复确认没问题才去生产装。结果生产环境一次通过没有任何坑。这个习惯帮我避免了很多风险。另外强烈建议把备份命令写成脚本统一用环境变量管理用户密码不要直接明文写进crontab。脚本里加一个简单的失败告警比如备份日志里没有completed OK!就触发报警效果比每天人工看日志好太多。最后想提醒所有做运维和DBA的朋友工具安装只是万里长征第一步定期做恢复演练才是真正保命的手段。我见过太多团队备份脚本跑了几年都正常真到故障要恢复时才发现备份集是坏的。XtraBackup 8.0装好之后没事就在测试机上演练几次恢复把恢复时间也统计出来等你真正遇到故障时心里才有底。
我见过很多DBA和运维朋友一备份MySQL就下意识敲mysqldump等数据量上了500GB备份时间从半小时变成五六个小时恢复更是遥遥无期这时候才开始着急找方案。其实在MySQL 8.0时代最该优先考虑的备份工具就是Percona XtraBackup 8.0。它是物理备份工具直接拷贝数据文件并跟踪redo log变化备份速度和恢复速度比mysqldump这种逻辑备份快一个量级而且支持在线热备不影响业务读写。这篇教程我不打算只甩几条命令而是把XtraBackup 8.0的版本选择逻辑、三种安装方式、安装后的验证方法、第一次备份恢复实操以及我踩过的坑全部整理出来。不管你是刚接手数据库的新人还是被线上备份搞得焦头烂额的老手照着这篇文章走一遍至少能少走两三天弯路。1. 工具选型XtraBackup 8.0到底解决什么问题1.1 物理备份与逻辑备份的原理差异先说清楚为什么大家都在推XtraBackup。mysqldump是逻辑备份它把表结构、数据记录一条条查出来再拼成SQL语句恢复的时候要一条条执行数据量一大CPU和IO全耗在解析和插入上。而XtraBackup是物理备份它直接调用InnoDB的机制把数据文件按页拷贝出来同时后台持续追踪redo log拷贝结束后再做一次apply保证备份集是一个一致性快照。简单类比一下mysqldump像把一仓库的货一件件登记造册再重新入库XtraBackup则是把整个仓库连货带货架一起搬走速度当然不是一个级别。在实际生产里1TB的MySQL实例用mysqldump全量备份可能要跑上一整天恢复又要大半天而XtraBackup全量备份通常在1小时级别恢复更是直接拷贝文件半小时内基本能搞定。更关键的是XtraBackup 8.0支持在线备份备份期间业务正常读写不会像文件系统快照需要短暂的锁表或停顿。1.2 8.0不是7.x的升级版而是严格对应的版本很多新人有一个误区以为XtraBackup 8.0比2.4版本新所以能备份所有MySQL版本。事实完全相反Percona对版本对应关系卡得非常死XtraBackup版本对应MySQL版本支持的主要特性XtraBackup 2.4MySQL 5.6 / 5.7旧版redo log结构适用于5.7及以前XtraBackup 8.0MySQL 8.0.x新版redo log结构支持8.0的数据字典XtraBackup 8.4MySQL 8.4/9.x对应新LTS版本目前还在快速迭代也就是说如果你的数据库是MySQL 8.0就必须用XtraBackup 8.0系列拿2.4版本去跑会直接报错提示redo log版本不兼容。强行使用不仅备份失败还可能让你误以为数据损坏。反过来如果数据库还是5.7也别急着上8.0老老实实用2.4否则工具根本不认识数据文件结构。这一条请刻在脑子里选型错误是后续所有安装问题的第一根源。2. 安装前必须确认的三件事2.1 确认你的MySQL版本与内核结构安装XtraBackup之前先确认目标数据库的准确版本mysql -u root -p -e SELECT VERSION();假设输出是8.0.34那就锁定XtraBackup 8.0.x。再确认一下数据库的glibc环境、操作系统位数尤其要注意的是Percona二进制包有glibc2.17和glibc2.28等不同编译版本后面我会详细说怎么选。2.2 确认操作系统与glibc版本这一步特别容易被忽略实际踩坑概率极高。XtraBackup是用C编译的二进制程序对glibc版本有硬性要求。你可以用下面命令查看系统glibc版本ldd --version我见过太多CentOS 7机器默认glibc是2.17结果下载了针对glibc2.28编译的XtraBackup包一运行就报GLIBC_2.28 not found整个安装直接卡死。所以先看清楚系统发行版和glibc版本再决定用哪种仓库或哪个tar包顺序千万别反。2.3 三种安装方式怎么选XtraBackup 8.0主流的安装方式有三种各有利弊我给出一个基于实际经验的选择建议Yum仓库CentOS/RHEL官方仓库托管依赖安装最省心适合能访问外网的生产机。APT仓库Ubuntu/Debian同上适合Debian系依赖自动处理。二进制tar包解压离线环境适合内网、无外网或等保要求严格的机器也是我现在最常用的方式因为镜像源经常不稳定而tar包可以提前下载好拷进去就能用。如果环境允许我建议优先走官方仓库因为它会自动处理libev、qpress、perl-DBD-MySQL等依赖。但如果你在金融、政企类项目待过就知道很多数据库服务器根本不能上外网仓库方式直接失效这时候tar包才是救命稻草。两种方式我都会详细讲。3. 实操三种安装方式完整走一遍3.1 CentOS/RHEL用Percona官方Yum仓库安装CentOS 7/8、RockyLinux、AlmaLinux这类系统先装Percona官方yum源配置包yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm装完之后仓库默认状态不一定是开启的要手动启用XtraBackup 8.0对应的软件仓库percona-release enable-only tools release这里解释一下enable-only的意思。Percona仓库里有release、tools、ps-80等多个子仓库如果不加enable-only可能会把Percona Server相关的包也暴露出来容易误装。enable-only tools release的意思是只启用tools和release范围正好覆盖XtraBackup 8.0。然后刷新缓存并安装yum clean all yum makecache yum install -y percona-xtrabackup-80安装完成后查看版本xtrabackup --version正常情况下会输出类似xtrabackup version 8.0.35-30 based on MySQL server 8.0.35 Linux (x86_64)的信息。看到这行字说明你已经成功了一大半。3.2 Ubuntu/Debian用Percona官方APT仓库安装Ubuntu或Debian的流程类似但要先装Percona的apt源配置包。注意lsb_release -sc会自动识别系统代号比如Ubuntu 22.04是jammy20.04是focal不需要手写wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb然后同样启用仓库并更新percona-release enable-only tools release apt update搜索一下包名确认存在apt-cache search percona-xtrabackup-80最后安装apt install -y percona-xtrabackup-80在纯内网Ubuntu环境如果没法用wget拉取deb包可以在一台能上网的同版本机器上先下载好percona-release_latest_all.deb和percona-xtrabackup-80的deb文件再拷贝到离线机器上用dpkg -i加apt -f install的方式补齐依赖。这个方法我实际验证过多次可行。3.3 离线环境二进制tar包安装重点离线环境是很多运维朋友真正需要的地方这里我多写一些细节。去Percona官网的Percona XtraBackup 8.0下载页面选择Linux - Generic分类会看到类似这样的文件名percona-xtrabackup-8.0.35-30-linux-x86_64.glibc2.17.tar.gzpercona-xtrabackup-8.0.35-30-linux-x86_64.glibc2.28.tar.gz关键就在glibc版本那个后缀。CentOS 7或老版本Ubuntu 18.04选glibc2.17CentOS 8/9、Ubuntu 20.04/22.04选glibc2.28一般没问题。如果不确定就用刚才提到的ldd --version查一下。下载后上传到服务器的/opt目录解压cd /opt tar -xzf percona-xtrabackup-8.0.35-30-linux-x86_64.glibc2.17.tar.gz为了便于后续脚本引用我习惯做一个软链把版本号目录映射成无版本目录ln -s /opt/percona-xtrabackup-8.0.35-30-linux-x86_64.glibc2.17 /opt/xtrabackup8再把bin目录加入PATHecho export PATH/opt/xtrabackup8/bin:$PATH /etc/profile.d/xtrabackup.sh source /etc/profile.d/xtrabackup.sh这样做的目的很简单将来升级XtraBackup时只需改软链指向新目录不需要改业务脚本里的命令路径。这个习惯帮我省过不少事。tar包方式还有一个好处它把可执行文件和库文件都打包在一起解压后即可运行。但要注意它仍然依赖操作系统层面的少数动态库比如libev.so.4和libgcrypt.so。如果运行时报缺库用yum或apt安装对应依赖包即可# CentOS/RHEL yum install -y libev rsync perl-DBD-MySQL qpress # Ubuntu/Debian apt install -y libev4 rsync percona-qpressqpress是一个高速压缩工具XtraBackup在压缩备份时会调用它建议一并装好。4. 安装验证与第一次备份恢复4.1 版本输出解读不管用哪种方式安装装完第一件事就是验证版本。执行xtrabackup --version我这里有一份真实的输出参考xtrabackup version 8.0.35-30 based on MySQL server 8.0.35 Linux (x86_64) (revision id: 32c0d33)从这个输出里你能确认三件事工具版本、对应的MySQL基础版本、系统架构。如果输出的版本号是8.0但基于的MySQL server版本是5.7那说明装错包了要立刻卸掉重装。如果命令找不到先检查PATH是否包含bin目录。同时可以用which xtrabackup xbcrypt --version xbstream --versionxbcrypt和xbstream是配套工具。xbstream用于处理流式备份xbcrypt用于加密备份它们和xtrabackup在同一个安装包里。4.2 建备份用户并跑通备份流程XtraBackup连接到MySQL并不强制用root但需要足够的权限。推荐单独建一个备份账号最小权限原则CREATE USER backup_userlocalhost IDENTIFIED BY your_password; GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO backup_userlocalhost; GRANT SELECT ON performance_schema.log_status TO backup_userlocalhost; FLUSH PRIVILEGES;BACKUP_ADMINMySQL 8.0里做在线备份需要的权限。PROCESS允许XtraBackup查看线程信息。RELOAD允许FLUSH TABLES WITH READ LOCK等操作。LOCK TABLES备份带非InnoDB表时需要锁表。REPLICATION CLIENT读取binlog坐标。权限建好后先建好备份目录mkdir -p /data/backups/$(date %Y%m%d)然后执行第一个全量备份xtrabackup --backup \ --target-dir/data/backups/20250120 \ --userbackup_user \ --passwordyour_password \ --host127.0.0.1 \ --port3306 \ --parallel4 \ --compress解释几个关键参数--backup进入备份模式对InnoDB而言是热备份。--target-dir备份输出目录注意目录必须不存在或为空。--parallel4开启4个并行线程针对大实例能显著提速。具体数值一般按CPU核数的一半到三分之二设置。--compress边备份边压缩适合磁盘紧张或远程传输场景。压缩依赖qpress所以之前提到要装。执行完成后观察日志最后几行正常会出现类似completed OK!的提示。有这句话才算备份成功。4.3 prepare和copy-back彻底确认安装没问题备份完成后备份集处于“运行时不一致”的状态不能直接用。必须先做prepare前滚回滚操作xtrabackup --prepare --target-dir/data/backups/20250120prepare过程会应用备份期间收集到的redo log把数据文件恢复到一致状态。对于增量备份prepare需要分多步按--incremental-basedir顺序合并。全量备份的话一条命令搞定。在把备份集恢复到目标实例之前最好先做一次考验xtrabackup --copy-back --target-dir/data/backups/20250120copy-back会把备份集里的文件复制回MySQL数据目录。这里有两个前提数据目录必须为空并且启动MySQL的OS用户要有写权限。如果使用的是类似/var/lib/mysql的目录要先确保属主和属组正确chown -R mysql:mysql /var/lib/mysql systemctl start mysqld以前我犯过一个低级错误prepare之后直接cp -r把文件覆盖到数据目录结果忽略了文件属主全变成了rootMySQL起不来。后来统一用--copy-back解决它会在复制后提示你确认属主。如果备份集是压缩格式要记得在copy-back前先解压。XtraBackup支持--decompress参数必须在prepare之后、copy-back之前执行xtrabackup --decompress --target-dir/data/backups/20250120 xtrabackup --prepare --target-dir/data/backups/20250120 xtrabackup --copy-back --target-dir/data/backups/20250120注意顺序先解压再prepare如果先prepare再decompressredo log的apply会出问题这一步顺序非常重要。5. 常见问题与排查实录5.1 GLIBC_2.28 not found这是离线二进制方式最常遇到的报错。执行xtrabackup时直接给一句./xtrabackup: /lib64/libc.so.6: version GLIBC_2.28 not found原因很简单系统glibc版本低于工具编译时要求的版本。CentOS 7默认glibc是2.17去升级系统glibc是风险极大的操作很可能把整个系统搞坏。正确解法是重新下载对应glibc2.17编译的版本或者改用官方yum仓库安装仓库会选择合适的构建版本。5.2 libev.so.4: cannot open shared object file另一种典型的动态库缺失问题。通常是因为机器上有Percona的yum仓库但没自动装上libev。解决办法yum install -y libev注意CentOS 8以上默认源里可能没有libev需要epel源yum install -y epel-release yum install -y libev5.3 Target directory exists and is not empty执行--backup时报这个错一般有两个原因一是上次备份的中间文件没清理二是指定的目录已经被占用。XtraBackup很谨慎目标目录非空就不干活防止覆盖。处理方式# 确认目录内容确实不需要后 rm -rf /data/backups/20250120在某些有审计要求的项目里不建议直接rm而是把旧备份目录移到归档区然后重新创建空目录。而且我建议备份脚本里加一个自动清理策略比如保留最近7天因为一旦磁盘被备份集占满MySQL比备份失败更让人头疼。5.4 MySQL连接失败Authentication plugin caching_sha2_passwordMySQL 8.0默认创建用户时用的是caching_sha2_password插件XtraBackup在某种情况下可能连不上尤其是通过IP非SSL方式连接时。日志里会出现Failed to connect to MySQL server: Authentication plugin caching_sha2_password cannot be loaded:解决方案有两个方向给备份用户指定mysql_native_password插件CREATE USER backup_userlocalhost IDENTIFIED WITH mysql_native_password BY your_password;或者保持默认插件但连接时加上SSL参数xtrabackup --backup --ssl-modeREQUIRED ...我个人推荐用第二种因为MySQL 8.0官方已经在逐步淘汰native_password新项目没必要为了一个备份工具改变认证策略。5.5 备份目录空间不足导致备份失败这个报错出现时日志通常一大片但不一定显眼No space left on deviceXtraBackup备份时的临时文件、undo日志都写在target-dir下空间计算千万别只按数据文件大小来要考虑压缩率、redo log增长和并行拷贝的临时文件。一般建议备份目录预留至少数据文件大小的1.5倍。如果你开启了--compress压力会小一些但也别卡得太紧。5.6 prepare后MySQL启动报错还有一种常见情况prepare完成后把数据目录整体copy到新机器MySQL启动时报[ERROR] InnoDB: ... Table mysql.engine_cost doesnt exist这个大概率是拷贝backup目录时漏掉了隐藏文件或权限不对。XtraBackup备份集里有些点开头的文件比如.ram文件拷贝时如果用了不带-a的cp命令很容易漏掉。用copy-back或者cp -a来拷贝就没有这个问题。6. 关于安装和备份最后分享几点经验网上安装教程一搜一大把但真正到了生产环境我建议你在操作前先做一次预演搭一台和线上同版本的MySQL实例在线下把整个备份恢复流程完整跑通。我以前接手过一个项目线上MySQL 8.0.28CentOS 7.9我直接在预发布环境验证了XtraBackup 8.0.35的备份和恢复确认没问题才去生产装。结果生产环境一次通过没有任何坑。这个习惯帮我避免了很多风险。另外强烈建议把备份命令写成脚本统一用环境变量管理用户密码不要直接明文写进crontab。脚本里加一个简单的失败告警比如备份日志里没有completed OK!就触发报警效果比每天人工看日志好太多。最后想提醒所有做运维和DBA的朋友工具安装只是万里长征第一步定期做恢复演练才是真正保命的手段。我见过太多团队备份脚本跑了几年都正常真到故障要恢复时才发现备份集是坏的。XtraBackup 8.0装好之后没事就在测试机上演练几次恢复把恢复时间也统计出来等你真正遇到故障时心里才有底。
