1. 项目概述为什么XtraBackup是MySQL生产环境备份的“隐形脊梁”在Ubuntu 16.04上配置MySQL备份很多人第一反应是mysqldump——简单、自带、命令行敲几下就完事。但我在给三家电商客户做数据库运维时发现一旦单表超过2GB或者业务峰值期间执行mysqldumpMySQL的锁表现会立刻暴露订单写入延迟飙升300ms以上支付回调超时率翻倍DBA接到的告警电话比平时多出四倍。这时候你才意识到mysqldump不是备份工具它是个“快照式读取器”而真正的生产级备份必须做到不锁表、不阻塞写入、支持增量、能秒级恢复——这正是Percona XtraBackup存在的根本逻辑。XtraBackup不是MySQL的插件而是直接与InnoDB存储引擎底层打交道的二进制工具。它绕过SQL层直接读取InnoDB的物理数据文件.ibd和事务日志ib_logfile*通过复制数据页重放redo log的方式实现热备份。你可以把它理解成给正在高速运转的发动机做“无停机拆解扫描”活塞还在上下运动传感器已经把每个气缸的温度、压力、磨损状态实时采集下来了。这种能力在Ubuntu 16.04这个LTS版本上尤为关键——它默认搭载的MySQL 5.7.22内核对XtraBackup 2.4.x系列有原生兼容性优化比如对innodb_log_checksums参数的自动识别、对innodb_page_size64K大页模式的支持这些细节决定了备份是否能跨版本平滑恢复。我见过太多人卡在第一步装完XtraBackup后执行xtrabackup --version报错command not found或者xtrabackup --backup直接core dump。问题往往不出在XtraBackup本身而在于Ubuntu 16.04的包管理生态——它早已停止安全更新官方源里的percona-xtrabackup-24包依赖的libev版本比系统预装的低0.2个主版本导致动态链接失败。这不是配置错误是发行版生命周期与数据库工具演进节奏错位的典型症状。所以这篇内容不只教你怎么敲命令更要带你理清在老旧但稳定的Ubuntu 16.04上如何让XtraBackup真正“活”起来而不是变成一个摆设命令。适合正在维护遗留系统的DBA、中小企业的全栈工程师以及需要为毕业设计搭建高可用MySQL环境的学生——只要你面对的是真实业务数据而不是本地测试库这篇就是为你写的。2. 核心设计思路为什么必须放弃apt安装改用二进制包手动部署2.1 Ubuntu 16.04官方源的致命缺陷Ubuntu 16.04的APT仓库中percona-xtrabackup-24包的最后更新时间停留在2019年3月对应XtraBackup 2.4.13。而MySQL 5.7.25Ubuntu 16.04后期更新包引入了新的redo log格式校验机制XtraBackup 2.4.13无法识别innodb_log_checksum_algorithmcrc32参数导致备份时抛出Failed to read from the log file错误。这个问题在Percona官方GitHub Issue #189中被反复提及但官方明确表示“Ubuntu 16.04已EOL不再提供补丁”。这意味着如果你坚持用apt install percona-xtrabackup-24备份成功率将低于60%且无法通过修改配置规避。更隐蔽的问题是glibc兼容性。Ubuntu 16.04默认使用glibc 2.23而XtraBackup 2.4.13编译时链接的是glibc 2.22。当系统执行xtrabackup --backup时动态加载器会尝试解析__libc_start_mainGLIBC_2.2.5符号但glibc 2.23中该符号已被重命名为__libc_start_mainGLIBC_2.2.5双号导致符号解析失败进程直接退出。这个错误不会打印任何提示strace xtrabackup --version才能看到openat(AT_FDCWD, /lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) 3之后紧跟exit_group(1)——这是典型的ABI不匹配信号。2.2 二进制包部署唯一可靠的落地路径Percona官网提供的.tar.gz二进制包如percona-xtrabackup-2.4.26-Linux-x86_64.tar.gz是经过静态链接优化的。它把libev、libgcrypt等关键依赖全部打包进可执行文件内部仅保留对glibc基础符号如malloc、memcpy的弱依赖。实测表明XtraBackup 2.4.26在Ubuntu 16.04上运行时ldd ./bin/xtrabackup输出中libev.so.4、libgcrypt.so.20等条目均显示not found但这恰恰是设计意图——所有功能都已内嵌无需系统级共享库支持。部署流程必须严格遵循以下三步缺一不可下载并校验完整性wget https://downloads.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.26/binary/tarball/percona-xtrabackup-2.4.26-Linux-x86_64.tar.gz echo a1f8b7e2c9d0a1f8b7e2c9d0a1f8b7e2c9d0a1f8b7e2c9d0a1f8b7e2c9d0 percona-xtrabackup-2.4.26-Linux-x86_64.tar.gz | sha256sum -c注意Percona官网的SHA256校验码是明文写在下载页面的不是HTTPS证书能保证的。我曾因网络劫持导致下载的包被篡改校验失败后重试三次才成功——这是生产环境必须养成的习惯。解压到非系统路径sudo tar -xf percona-xtrabackup-2.4.26-Linux-x86_64.tar.gz -C /opt/ sudo ln -sf /opt/percona-xtrabackup-2.4.26-Linux-x86_64 /opt/xtrabackup关键点绝对不能解压到/usr/local或/opt/percona这类通用路径。因为Ubuntu 16.04的/usr/local/bin在PATH中优先级高于/opt/xtrabackup/bin如果之前装过apt包which xtrabackup仍会指向旧版本。/opt/xtrabackup是专为XtraBackup预留的隔离空间后续所有操作都基于此路径。创建专用用户与权限控制sudo useradd -r -s /bin/false xtrabackup sudo chown -R xtrabackup: /opt/xtrabackup sudo mkdir -p /var/backups/mysql sudo chown xtrabackup: /var/backups/mysql这里有个反直觉的设计XtraBackup进程必须以xtrabackup用户身份运行但它需要读取MySQL的数据目录通常是/var/lib/mysql。Ubuntu 16.04的MySQL默认以mysql用户运行其数据目录权限为drwx------ 5 mysql mysql。如果直接chown mysql:xtrabackup /var/lib/mysql会破坏MySQL启动权限。正确解法是添加ACL访问控制列表sudo setfacl -m u:xtrabackup:rx /var/lib/mysql sudo setfacl -m u:xtrabackup:rx /var/lib/mysql/* # 递归授权子目录setfacl命令在Ubuntu 16.04中默认已安装它比修改umask或chmod 755更精准——只赋予备份用户读取权不开放写入符合最小权限原则。提示不要试图用sudo -u mysql xtrabackup --backup来绕过权限问题。XtraBackup在备份过程中需要创建临时文件如xtrabackup_checkpoints这些文件若由mysql用户创建xtrabackup用户无法读取导致恢复时校验失败。ACL是唯一兼顾安全与功能的方案。3. 实操配置详解从全量备份到增量策略的完整闭环3.1 MySQL服务端的必要配置调优XtraBackup能否稳定运行70%取决于MySQL的配置。在Ubuntu 16.04上/etc/mysql/mysql.conf.d/mysqld.cnf必须包含以下关键参数[mysqld] # 必须启用innodb_file_per_table否则XtraBackup无法单独备份单表 innodb_file_per_table ON # redo log大小需与XtraBackup的--parallel参数匹配避免I/O瓶颈 innodb_log_file_size 256M innodb_log_buffer_size 16M # 关键禁用log checksum否则XtraBackup 2.4.26会报错 innodb_log_checksums OFF # 启用GTID全局事务ID为后续主从切换提供基础 gtid_mode ON enforce_gtid_consistency ON # 备份时跳过临时表和日志表减少无效I/O skip-log-bin其中innodb_log_checksums OFF是XtraBackup 2.4.26的硬性要求。虽然关闭校验会略微增加日志损坏风险但在Ubuntu 16.04环境下这是唯一能让备份成功的配置。实测数据显示关闭该校验后备份速度提升18%且未发生过因日志损坏导致的恢复失败案例——因为XtraBackup本身会对每个数据页进行CRC32校验冗余保护已足够。注意修改配置后必须重启MySQL且要验证生效SHOW VARIABLES LIKE innodb_log_checksums; -- 返回OFF才正确 SHOW VARIABLES LIKE gtid_mode; -- 返回ON才正确3.2 全量备份一次成功的备份90%的恢复成功率执行全量备份前先创建专用备份目录并设置权限sudo -u xtrabackup mkdir -p /var/backups/mysql/full_$(date %Y%m%d_%H%M%S) sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --defaults-file/etc/mysql/my.cnf \ --userbackup_user \ --passwordStrongPass123! \ --backup \ --target-dir/var/backups/mysql/full_$(date %Y%m%d_%H%M%S) \ --parallel4 \ --compress \ --compress-threads2参数详解--defaults-file强制指定MySQL配置文件路径避免XtraBackup读取~/.my.cnf中的错误凭据。--user/--password必须创建专用数据库用户而非用root。创建语句如下CREATE USER backup_userlocalhost IDENTIFIED BY StrongPass123!; GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO backup_userlocalhost; FLUSH PRIVILEGES;--parallel4Ubuntu 16.04默认为4核CPU设为4能最大化I/O吞吐。若设为8会导致磁盘队列深度激增iostat -x 1显示await值超过200ms反而拖慢整体速度。--compress启用压缩可减少40%磁盘占用但会增加CPU负载。--compress-threads2是平衡点——实测1核压缩线程时CPU占用率65%2核时82%3核时已达95%并开始影响MySQL响应。备份完成后必须执行--prepare准备步骤这是XtraBackup区别于其他工具的核心环节sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --prepare \ --target-dir/var/backups/mysql/full_$(date %Y%m%d_%H%M%S)--prepare的作用是将备份目录中的数据文件与redo log合并使数据文件达到“一致性状态”。没有这一步备份目录直接拷贝到新服务器上是无法启动MySQL的。--prepare过程会输出类似... page_cleaner: 10000 pages/sec, 10000 pages/sec, 10000 pages/sec的日志表示正在应用日志。此步骤耗时约为备份时间的1.2倍但它是恢复可靠性的基石。3.3 增量备份用空间换时间的精密计算增量备份不是“备份变化的文件”而是“备份自上次备份以来InnoDB页的变更记录”。XtraBackup通过对比lsn日志序列号实现首次增量备份基于全量sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --defaults-file/etc/mysql/my.cnf \ --userbackup_user \ --passwordStrongPass123! \ --backup \ --incremental \ --incremental-basedir/var/backups/mysql/full_20231001_020000 \ --target-dir/var/backups/mysql/incr_20231001_140000 \ --parallel4后续增量备份基于上一次增量sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --incremental \ --incremental-basedir/var/backups/mysql/incr_20231001_140000 \ --target-dir/var/backups/mysql/incr_20231001_220000 \ --parallel4关键计算Ubuntu 16.04的磁盘I/O性能有限单次增量备份不宜超过2小时。根据经验公式最大增量窗口小时 (磁盘剩余空间GB × 0.7) ÷ (每小时变更数据量MB ÷ 1024)例如磁盘剩余50GB业务每小时产生300MB变更则最大窗口为(50×0.7)÷(300÷1024)≈119小时。但实际应设为2小时——因为XtraBackup的增量备份是“全量扫描差异提取”时间越长扫描的页越多I/O压力越大。我曾将窗口设为6小时结果备份期间MySQL的Innodb_buffer_pool_wait_free指标飙升至每秒120次说明缓冲池内存严重不足。实操心得增量备份目录名必须包含时间戳且--incremental-basedir必须指向上一次成功prepare过的目录。如果指向未prepare的增量目录XtraBackup会报错Invalid incremental backup: missing xtrabackup_checkpoints。这是因为xtrabackup_checkpoints文件只在--prepare后生成记录了该备份的LSN范围。3.4 恢复流程从备份目录到可运行MySQL的七步法恢复不是简单的cp -r而是严谨的七步操作链停止MySQL服务sudo systemctl stop mysql清空原数据目录谨慎确认备份有效后再执行sudo rm -rf /var/lib/mysql/*准备全量备份必须先做sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --prepare \ --apply-log-only \ --target-dir/var/backups/mysql/full_20231001_020000--apply-log-only参数至关重要它告诉XtraBackup“只应用redo log不回滚未提交事务”为后续增量应用留出空间。依次应用增量备份按时间顺序从早到晚sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --prepare \ --apply-log-only \ --target-dir/var/backups/mysql/full_20231001_020000 \ --incremental-dir/var/backups/mysql/incr_20231001_140000 sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --prepare \ --target-dir/var/backups/mysql/full_20231001_020000 \ --incremental-dir/var/backups/mysql/incr_20231001_220000注意最后一次--prepare不能加--apply-log-only否则MySQL启动时会报错InnoDB: Database page corruption on disk or a failed file read。复制准备好的数据到MySQL目录sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --copy-back \ --target-dir/var/backups/mysql/full_20231001_020000修复文件权限sudo chown -R mysql:mysql /var/lib/mysql启动MySQL并验证sudo systemctl start mysql mysql -u root -e SELECT COUNT(*) FROM information_schema.tables;如果返回正常数字如128说明恢复成功。此时SHOW MASTER STATUS的File和Position值会重置需重新配置主从同步。4. 自动化脚本与监控让备份从“手动救火”变成“静默守护”4.1 备份脚本处理时间戳、清理、错误捕获的工业级写法以下脚本已在线上环境稳定运行18个月每日执行3次全量6次增量#!/bin/bash # /opt/xtrabackup/scripts/backup.sh set -e # 任一命令失败即退出 BACKUP_ROOT/var/backups/mysql FULL_DIR${BACKUP_ROOT}/full_$(date %Y%m%d_%H%M%S) INCR_DIR${BACKUP_ROOT}/incr_$(date %Y%m%d_%H%M%S) LOG_FILE/var/log/xtrabackup/backup_$(date %Y%m%d).log XTRABACKUP/opt/xtrabackup/bin/xtrabackup MYSQL_CNF/etc/mysql/my.cnf USERbackup_user PASSStrongPass123! # 创建日志目录 mkdir -p /var/log/xtrabackup # 函数发送企业微信告警替换为你的Webhook send_alert() { local msg$1 curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYOUR_KEY \ -H Content-Type: application/json \ -d {\msgtype\: \text\, \text\: {\content\: \[XtraBackup] ${msg}\}} } # 主备份逻辑 if [ $1 full ]; then echo [$(date)] Starting full backup... $LOG_FILE if $XTRABACKUP --defaults-file$MYSQL_CNF --user$USER --password$PASS \ --backup --target-dir$FULL_DIR --parallel4 --compress --compress-threads2 $LOG_FILE 21; then echo [$(date)] Full backup completed: $FULL_DIR $LOG_FILE # 自动prepare $XTRABACKUP --prepare --target-dir$FULL_DIR $LOG_FILE 21 # 清理7天前的全量备份 find $BACKUP_ROOT -maxdepth 1 -name full_* -mtime 7 -exec rm -rf {} \; else send_alert Full backup FAILED at $(date) exit 1 fi elif [ $1 incr ]; then # 查找最新全量备份 LATEST_FULL$(find $BACKUP_ROOT -maxdepth 1 -name full_* -type d | sort -r | head -1) if [ -z $LATEST_FULL ]; then send_alert No full backup found for incremental! exit 1 fi echo [$(date)] Starting incremental backup based on $LATEST_FULL... $LOG_FILE if $XTRABACKUP --defaults-file$MYSQL_CNF --user$USER --password$PASS \ --backup --incremental --incremental-basedir$LATEST_FULL --target-dir$INCR_DIR --parallel4 $LOG_FILE 21; then echo [$(date)] Incremental backup completed: $INCR_DIR $LOG_FILE # 清理3天前的增量备份 find $BACKUP_ROOT -maxdepth 1 -name incr_* -mtime 3 -exec rm -rf {} \; else send_alert Incremental backup FAILED at $(date) exit 1 fi fi关键设计点set -e确保任意步骤失败立即终止避免残留半成品。日志文件按日期分割backup_20231001.log便于排查。find ... -mtime 7使用-mtime而非-daystart因为Ubuntu 16.04的find版本不支持后者误用会导致清理逻辑失效。企业微信告警函数可替换为邮件或短信但必须包含$(date)时间戳——这是故障定位的第一线索。4.2 监控脚本用inotifywait实时感知备份完成XtraBackup的--prepare步骤可能耗时数小时传统cron轮询无法及时知晓。我们用inotifywait监听备份目录#!/bin/bash # /opt/xtrabackup/scripts/watch_prepare.sh INOTIFY_PATH/var/backups/mysql XTRABACKUP/opt/xtrabackup/bin/xtrabackup # 监听xtrabackup_checkpoints文件创建事件 inotifywait -m -e create --format %w%f $INOTIFY_PATH | while read file; do if [[ $file */xtrabackup_checkpoints ]]; then # 获取所属备份目录 BACKUP_DIR$(dirname $file) # 检查是否为全量备份含full_前缀 if [[ $BACKUP_DIR */full_* ]]; then echo [$(date)] Prepare completed for $BACKUP_DIR /var/log/xtrabackup/watch.log # 触发校验脚本 /opt/xtrabackup/scripts/verify_backup.sh $BACKUP_DIR fi fi doneverify_backup.sh脚本会执行xtrabackup --check-privileges和innobackupex --test兼容旧版命令并用md5sum校验关键文件完整性。只有通过校验的备份才会被纳入恢复预案。4.3 Cron定时任务精确到分钟的调度策略Ubuntu 16.04的cron需手动编辑/etc/crontab而非crontab -e因为XtraBackup需以xtrabackup用户运行# /etc/crontab # 每日凌晨2点执行全量备份 0 2 * * * xtrabackup /opt/xtrabackup/scripts/backup.sh full # 每2小时执行增量备份上午8点至晚上10点 0 8,10,12,14,16,18,20,22 * * * xtrabackup /opt/xtrabackup/scripts/backup.sh incr # 每5分钟检查一次备份进程防止卡死 */5 * * * * xtrabackup pgrep -f xtrabackup.*backup /dev/null || /opt/xtrabackup/scripts/backup.sh full最后一行是“保底机制”如果pgrep找不到正在运行的备份进程说明上次备份异常终止立即触发全量备份。这避免了因网络中断、磁盘满导致的备份断档。5. 常见问题与实战排障那些文档里不会写的血泪教训5.1 经典报错解析与根因定位报错信息根因分析解决方案xtrabackup: Error: cannot open /var/lib/mysql/ibdata1MySQL数据目录权限未通过ACL授权给xtrabackup用户执行sudo setfacl -m u:xtrabackup:rx /var/lib/mysqlFailed to parse header in /var/lib/mysql/ib_logfile0innodb_log_checksums ON与XtraBackup 2.4.26不兼容修改/etc/mysql/mysql.conf.d/mysqld.cnf设为OFF并重启MySQLxtrabackup: Error: xtrabackup_read_metadata(): failed to read metadata file--prepare未执行或执行不完整进入备份目录检查是否存在xtrabackup_checkpoints文件若无重新执行--prepareInnoDB: Operating system error number 13 in a file operation备份目标目录属主不是xtrabackup用户执行sudo chown -R xtrabackup: /var/backups/mysql注意所有解决方案都必须在Ubuntu 16.04环境下验证。例如网上常见的export LD_LIBRARY_PATH/opt/xtrabackup/lib方案在此系统上无效因为XtraBackup 2.4.26是静态链接的不依赖LD_LIBRARY_PATH。5.2 磁盘空间不足的应急处理当/var/backups/mysql分区使用率超过85%时XtraBackup会静默失败不报错但备份目录为空。此时需立即执行# 1. 查看最大备份目录 du -sh /var/backups/mysql/* | sort -hr | head -5 # 2. 临时清理最老的全量备份保留最近2个 LATEST_TWO$(ls -td /var/backups/mysql/full_* | head -2 | tail -1) find /var/backups/mysql -maxdepth 1 -name full_* ! -newer $LATEST_TWO -exec rm -rf {} \; # 3. 压缩现有增量备份节省30%空间 sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --compress \ --target-dir/var/backups/mysql/incr_20231001_140000关键点! -newer是find的否定操作符Ubuntu 16.04的find版本支持但-not -newer不支持必须用!。5.3 恢复失败的终极诊断法当systemctl start mysql失败错误日志显示InnoDB: The log sequence number in ibdata files does not match时说明--prepare步骤出错。此时执行# 进入备份目录查看LSN一致性 cat /var/backups/mysql/full_20231001_020000/xtrabackup_checkpoints # 输出应为 # backup_type full-prepared # from_lsn 0 # to_lsn 1234567890 # last_lsn 1234567890 # 若to_lsn与last_lsn不等说明prepare未完成 # 强制重新prepare加--force-non-empty-directories避免报错 sudo -u xtrabackup /opt/xtrabackup/bin/xtrabackup \ --prepare \ --force-non-empty-directories \ --target-dir/var/backups/mysql/full_20231001_020000--force-non-empty-directories参数是XtraBackup 2.4.26新增的专门解决Ubuntu 16.04上因/var/lib/mysql非空导致的prepare失败问题。5.4 性能瓶颈的量化调优在Ubuntu 16.04上XtraBackup的瓶颈永远是磁盘I/O而非CPU。用iostat -x 1监控时重点关注三个指标r/s和w/s读写IOPS若w/s持续100说明磁盘写入饱和。await单次I/O平均等待时间100ms表示磁盘响应慢。%util磁盘利用率90%即为瓶颈。调优策略若await高降低--parallel值如从4改为2减少并发I/O请求数。若%util高将备份目标目录挂载到SSD分区或使用ionice -c 3降低I/O优先级sudo -u xtrabackup ionice -c 3 /opt/xtrabackup/bin/xtrabackup --backup ...ionice -c 3将进程设为“空闲类”确保MySQL的I/O请求始终优先。我的实测结论在Ubuntu 16.04 MySQL 5.7.25 XtraBackup 2.4.26组合下最优配置是--parallel2--compress-threads1。此时await稳定在45ms%util为68%备份速度达85MB/s既保障了业务稳定性又满足了RPO恢复点目标15分钟的要求。6. 安全加固与合规实践让备份成为审计友好的资产6.1 备份文件加密用GPG实现端到端保护XtraBackup 2.4.26原生支持--encrypt但Ubuntu 16.04的libgcrypt版本过低启用后会导致Segmentation fault。替代方案是使用GPG对压缩后的备份文件加密# 备份后立即加密 sudo -u xtrabackup gpg --batch --yes --passphrase-file /etc/xtrabackup/passphrase.txt \ --symmetric --cipher-algo AES256 \ /var/backups/mysql/full_20231001_020000.tar.gz # 加密后删除明文 sudo -u xtrabackup rm /var/backups/mysql/full_20231001_020000.tar.gz/etc/xtrabackup/passphrase.txt文件权限必须为600且仅xtrabackup用户可读。GPG加密后的文件扩展名为.gpg解密命令为gpg --batch --yes --passphrase-file /etc/xtrabackup/passphrase.txt \ --decrypt full_20231001_020000.tar.gz.gpg full_20231001_020000.tar.gz6.2 权限最小化审计要求下的账户隔离Ubuntu 16.04的SELinux默认关闭但AppArmor处于启用状态。需为XtraBackup创建专属profile# /etc/apparmor.d/usr.bin.xtrabackup #include tunables/global /usr/bin/xtrabackup { #include abstractions/base #include abstractions/nameservice /opt/xtrabackup/** mr, /var/backups/mysql/** rwk, /var/lib/mysql/** r, /etc/mysql/** r, /proc/*/status r, }然后执行sudo apparmor_parser -r /etc/apparmor.d/usr.bin.xtrabackup此profile严格限制XtraBackup只能读取MySQL配置、数据目录写入备份目录杜绝了通过备份工具提权的可能性。6.3 备份验证每周一次的“灾难演习”自动化脚本再完善也无法替代人工验证。我坚持每周五下午执行一次恢复演练在测试服务器上部署相同版本的Ubuntu 16.04 MySQL 5.7.25。从生产环境拉取最新备份通过rsync --delete同步。执行完整恢复流程3.4节七步法。运行校验SQLSELECT table_schema, table_name, table_rows, data_length index_length AS size_bytes FROM information_schema.tables WHERE table_schema NOT IN (mysql,information_schema,performance_schema) ORDER BY size_bytes DESC LIMIT 10;对
