大家好我是老K。分享一个比较特别的实战记录代号“荒岛求生”。事情的起因是部门在做一次模拟故障演练把一台跑着核心订单库的“客机”人为“击落”然后在“无人荒岛”一台完全隔离的备份机上靠仅存的备份文件和数据归档把业务重新“养活”。这次演练让我意识到许多团队平时的备份策略在真正极端故障面前根本撑不住。本文就结合这个“荒岛求生”项目完整拆解一套从备份策略、故障模拟到恢复验证的闭环方案。无论是后端开发、DBA 还是运维同学这套思路都可以直接复用。文章不涉及高深理论全部是能落地、能实操的命令和配置。先说清楚本文的重点不是讲 MySQL 复制而是讲“飞机失事后如何在荒岛上靠备份活下来”。也就是在极端灾难场景下如何利用全量备份、增量备份、binlog二进制日志以及一套严谨的恢复流程把数据库从“幸存”变成“恢复”最终恢复对外服务。整套内容用到的技术栈都是常规的开源组件。1. 背景与核心概念什么是“荒岛求生”式容灾1.1 从飞机失事到系统崩溃“客机遭遇恶劣天气意外失事幸存者流落至偏僻无人荒岛”——这是项目标题也是我们对一次容灾演练的比喻。客机一台运行中的生产数据库服务器承载订单核心业务。恶劣天气一次突发的磁盘损坏或人为误操作。失事服务器不可用数据库文件损坏服务中断。幸存者灾前留下的全量备份、增量备份、binlog 归档。无人荒岛一台独立的、与生产环境隔离的备用服务器。求生通过备份文件在备用服务器上重建数据库恢复数据和服务。“荒岛求生”项目的核心目标不是研究如何保证飞机不失事而是研究失事之后如何用幸存下来的碎片重建一座可居住的家园。映射到技术上就是“容灾恢复”Disaster Recovery重点关注 RPO恢复点目标和 RTO恢复时间目标。1.2 RPO 与 RTO两个决定生死的关键指标在容灾领域有两个绕不开的指标RPORecovery Point Objective恢复点目标允许丢失多少数据。比如 RPO1 小时意味着灾难发生后最多允许丢失 1 小时内的数据。RTORecovery Time Objective恢复时间目标允许中断多长时间。比如 RTO4 小时意味着从故障发生到服务恢复必须在 4 小时内完成。在“荒岛求生”项目中我们的 RPO 目标是 15 分钟以内RTO 目标是 1 小时以内。这意味着备份策略至少要能恢复到最后一次 binlog 归档时间点15 分钟内。恢复操作流程必须清晰、自动化不能靠人肉敲命令慢慢试。1.3 备份的三种常见形态要理解恢复先要理解备份。常见的备份形态有三种备份类型说明恢复速度数据完整性全量备份备份整个数据库的所有数据文件慢完整增量备份备份自上次备份以来发生变化的数据快依赖全量备份归档日志binlog记录所有数据变更操作快可精确到某个时间点在“荒岛求生”方案中我们采用的策略是每天凌晨 2 点进行一次全量备份mysqldump或xtrabackup。每 15 分钟进行一次 binlog 归档。把全量备份和 binlog 归档同步到“荒岛服务器”异机存储。这样即使生产服务器彻底损坏我们也可以通过“全量备份 binlog 重放”的方式把数据恢复到最近 15 分钟内的状态。2. 环境准备与版本说明为了模拟真实场景我准备了两台虚拟机分别代表“客机”生产服务器和“荒岛”灾备服务器。测试环境信息如下角色操作系统IP 地址软件版本生产服务器客机CentOS 7.9192.168.10.10MySQL 8.0.32灾备服务器荒岛CentOS 7.9192.168.10.20MySQL 8.0.32由于 MySQL 8.0 与 5.7 在备份和恢复命令上略有差异本文以 MySQL 8.0 为例如果你的环境是 5.7也基本适用但需要注意caching_sha2_password认证插件的差异。另外生产服务器还需要安装xtrabackup工具。xtrabackup是由 Percona 提供的开源备份工具相比mysqldump它支持物理备份备份速度快并且能在备份过程中不锁表非常适合生产环境。安装xtrabackup生产服务器执行# 安装 Percona 仓库 yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm # 查看可用的 xtrabackup 版本 yum list | grep xtrabackup # 安装 xtrabackup 8.0适配 MySQL 8.0 yum install -y percona-xtrabackup-80如果你不想额外安装 xtrabackup也可以使用mysqldump做逻辑备份。两者的区别在于mysqldump导出 SQL 语句恢复时需要重新执行速度较慢适合数据量不大的场景。xtrabackup物理复制数据文件恢复时几乎可以直接使用速度快适合数据量大的场景。本文以xtrabackup为主讲解因为它在“荒岛求生”这种极端场景下恢复效率更高。3. 备份策略与核心原理“荒岛求生”的第一步不是想怎么恢复而是想怎么在“飞机失事前”留存足够的“幸存者”。这里的“幸存者”就是备份。备份策略设计得好恢复过程才能游刃有余。3.1 全量备份为荒岛准备“基础物资”全量备份思路如下每天凌晨 2 点使用xtrabackup对生产数据库做一次全量物理备份并将备份文件压缩后传送到灾备服务器。生产服务器定时任务配置crontab -e# 每天凌晨 2 点执行全量备份脚本 0 2 * * * /root/scripts/full_backup.sh /var/log/full_backup.log 21/root/scripts/full_backup.sh脚本内容#!/bin/bash # 定义备份目录和备份文件名 BACKUP_DIR/data/backup/full DATE$(date %Y%m%d_%H%M%S) BACKUP_NAMEfull_backup_${DATE} # 创建备份目录 mkdir -p ${BACKUP_DIR}/${BACKUP_NAME} # 使用 xtrabackup 执行全量备份 xtrabackup --backup \ --target-dir${BACKUP_DIR}/${BACKUP_NAME} \ --userroot \ --passwordYourPassword \ --host127.0.0.1 \ --port3306 # 备份完成后将备份目录压缩并传送至灾备服务器 tar -czf /data/backup/${BACKUP_NAME}.tar.gz -C ${BACKUP_DIR} ${BACKUP_NAME} # 使用 scp 传送到灾备服务器需要提前配置 SSH 免密登录 scp /data/backup/${BACKUP_NAME}.tar.gz root192.168.10.20:/data/backup/full/ # 删除本机 7 天前的备份节约磁盘空间 find ${BACKUP_DIR} -type d -mtime 7 -exec rm -rf {} \; find /data/backup -name *.tar.gz -mtime 7 -exec rm -rf {} \; echo 备份完成: ${BACKUP_NAME}注意事项xtrabackup --backup在备份过程中不会阻塞业务读写这是它相比mysqldump的核心优势。备份文件传送到灾备服务器后生产服务器的本地备份可以按保留周期清理但灾备服务器上的备份至少保留 7 天以上便于追溯。如果内网带宽有限可以先用gzip压缩再传输或者使用rsync增量同步。3.2 binlog 归档记录“幸存者”的每一句遗言全量备份只能恢复到最后一次备份的时间点。如果凌晨 2 点备份上午 10 点数据库崩溃那么 2 点到 10 点之间新增的数据就全部丢失。为了把这些“遗言”保存下来我们需要开启 binlog并定期归档。检查生产服务器 binlog 是否开启MySQL 命令行SHOW VARIABLES LIKE log_bin;如果没有开启需要在/etc/my.cnf中添加以下配置并重启 MySQL[mysqld] server-id1 log-binmysql-bin binlog_formatROW expire_logs_days7 max_binlog_size256M参数解释server-idMySQL 复制必须设置即使在单机场景也建议设置避免后期需要搭建主从时遗漏。log-bin开启 binlog文件名前缀为mysql-bin。binlog_formatROW行级日志记录每一行数据的变化恢复时更精确。expire_logs_days7binlog 自动清理时间保留 7 天。max_binlog_size单个 binlog 文件的最大大小超过后自动滚动。binlog 实时生成我们还需要一个定时任务把 binlog 文件同步到灾备服务器。因为 binlog 可能每几分钟就产生一个所以可以使用rsync做实时同步。灾备服务器定时同步任务crontab -e# 每 5 分钟同步一次生产服务器的 binlog 到灾备服务器 */5 * * * * /root/scripts/sync_binlog.sh /var/log/sync_binlog.log 21/root/scripts/sync_binlog.sh脚本内容#!/bin/bash # 定义源目录和目标目录 SRC_DIRroot192.168.10.10:/data/mysql/data/ DST_DIR/data/backup/binlog/ # 使用 rsync 增量同步不删除远端文件 rsync -avz --progress ${SRC_DIR} ${DST_DIR}注意事项rsync同步的是 MySQL 数据目录其中包含 binlog 文件。我们在同步时要特别注意不要同步mysql-bin.index这种索引文件时出错可以在 rsync 命令中排除不过为了简化演示这里直接同步整个目录。如果 binlog 文件比较大建议开启 MySQL 的sync_binlog1确保每次事务提交后都刷盘避免数据库异常断电时丢失 binlog。灾备服务器的磁盘容量需要提前规划至少保留 7 天以上的 binlog 容量。3.3 备份恢复的核心原理prepare 与重放在“荒岛求生”项目中恢复过程分为两个关键动作prepare准备xtrabackup备份出来的文件不是直接可用的因为备份过程中可能有正在执行的事务数据文件处于一个“不一致”的状态。我们需要用xtrabackup --prepare把备份文件恢复到一致状态。replay重放把全量备份之后产生的 binlog 按顺序重放到目标数据库让数据恢复到故障前的最新状态。这里必须强调一下xtrabackup --prepare不等于把数据恢复到一致可用状态。它只是把备份文件中的事务日志redo log应用到数据文件中使得数据文件在物理上是一致的。而 binlog 重放则是把逻辑变更SQL 操作再执行一遍让数据在逻辑上跟上最新的业务状态。所以“荒岛求生”的完整恢复链路是全量备份 prepare → 恢复数据文件 → 启动 MySQL → 重放 binlog 至故障前时间点 → 验证数据完整 → 切换服务4. 完整实战模拟“客机失事”并在“荒岛”上恢复下面进入核心实战。我们将按照“制造事故 → 准备荒岛 → 恢复数据 → 验证服务”的顺序完整走一遍。4.1 制造事故让“客机”坠落为了模拟真实故障我在生产服务器上做以下操作创建一个测试库flight并写入初始数据。模拟一次误删除操作。直接关闭 MySQL并删除部分数据文件模拟磁盘损坏。生产服务器操作MySQL:-- 创建测试库 CREATE DATABASE IF NOT EXISTS flight; USE flight; -- 创建订单表 CREATE TABLE orders ( id int NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL, passenger_name varchar(64) NOT NULL, amount decimal(10,2) NOT NULL, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB; -- 插入初始数据 INSERT INTO orders (order_no, passenger_name, amount) VALUES (FL20250101, 张三, 1999.00), (FL20250102, 李四, 2599.00), (FL20250103, 王五, 3299.00);确认数据已经写入SELECT * FROM flight.orders;接下来模拟 2 个小时后业务继续运行插入一批新数据INSERT INTO orders (order_no, passenger_name, amount) VALUES (FL20250104, 赵六, 3999.00), (FL20250105, 孙七, 1599.00);最后模拟“恶劣天气”——误操作-- 模拟误操作删除了部分订单数据 DELETE FROM flight.orders WHERE id 2;此时生产库中应该只有 4 条数据id 1、3、4、5id2 的数据已经被删除。这个被删除的数据能否找回来就看我们的备份和 binlog 是否完整了。最后关闭 MySQL模拟数据库物理损坏# 停止 MySQL 服务 systemctl stop mysqld # 模拟磁盘损坏清空数据目录 rm -rf /data/mysql/data/* # 查看数据目录是否为空 ls -la /data/mysql/data/到这里“客机”已经失事“幸存者”只有灾备服务器上的全量备份和 binlog 归档。4.2 准备“荒岛”检查灾备服务器物资登录灾备服务器192.168.10.20检查是否有可用的备份文件。# 查看全量备份目录 ls -la /data/backup/full/ # 查看 binlog 归档目录 ls -la /data/backup/binlog/预期输出类似drwxr-xr-x 3 root root 4096 Nov 10 02:00 full_backup_20250110_020000 -rw-r--r-- 1 root root 238M Nov 10 02:00 full_backup_20250110_020000.tar.gz -rw-r----- 1 root root 256M Nov 10 02:05 mysql-bin.000001 -rw-r----- 1 root root 256M Nov 10 02:20 mysql-bin.000002 -rw-r----- 1 root root 256M Nov 10 02:35 mysql-bin.000003 ...如果灾备服务器上已经有最新到 10:15 左右的 binlog说明物资齐全可以开始“求生”。4.3 解压并 prepare 全量备份我们把全量备份恢复到灾备服务器的 MySQL 数据目录中。需要注意的是恢复操作会覆盖灾备服务器上已有的 MySQL 数据所以确认灾备服务器上没有重要数据后再操作。灾备服务器执行# 解压全量备份 tar -xzf /data/backup/full/full_backup_20250110_020000.tar.gz -C /data/backup/full/ # 进入备份目录 cd /data/backup/full/full_backup_20250110_020000/ # 查看备份内容 ls -la然后执行prepare操作# 使用 xtrabackup 准备备份 xtrabackup --prepare --target-dir/data/backup/full/full_backup_20250110_020000/prepare过程中xtrabackup会把 redo log 中的事务应用到数据文件回滚未提交的事务最终得到一个一致性快照。如果一切顺利日志结尾会出现completed OK!。然后把 prepare 好的数据文件复制到 MySQL 的数据目录# 清空目标数据目录 rm -rf /data/mysql/data/* # 复制备份文件到数据目录 cp -r /data/backup/full/full_backup_20250110_020000/* /data/mysql/data/ # 修改属主为 mysql 用户 chown -R mysql:mysql /data/mysql/data/4.4 启动 MySQL 并重放 binlog现在灾备服务器上已经有一份凌晨 2 点的完整数据。但业务数据已经更新到 10 点以后的版本我们需要把 binlog 中从备份结束时间点到故障前时间点的所有操作重放一遍。首先找到备份结束时对应的 binlog 位置。查看备份目录中的xtrabackup_binlog_info文件cat /data/backup/full/full_backup_20250110_020000/xtrabackup_binlog_info输出类似mysql-bin.000003 2731这表示备份结束时binlog 已经写到mysql-bin.000003位置 2731。也就是说从这个位置之后产生的 binlog 都需要重放。启动 MySQL 服务systemctl start mysqld然后使用mysqlbinlog重放 binlog。注意需要从mysql-bin.000003的位置 2731 开始一直到最后一个 binlog 文件。# 切换到 binlog 归档目录 cd /data/backup/binlog/ # 重放 binlog示例命令需要按实际文件名调整 mysqlbinlog \ --start-position2731 \ --stop-datetime2025-01-10 10:30:00 \ mysql-bin.000003 mysql-bin.000004 mysql-bin.000005 ... | mysql -uroot -p实际执行时你需要列出从mysql-bin.000003到故障前最后一个 binlog 的所有文件。为了简化操作可以用循环脚本#!/bin/bash # 定义 MySQL 账号密码 MYSQL_USERroot MYSQL_PASSYourPassword # 定义开始位置 START_POS2731 # 切换目录 cd /data/backup/binlog/ # 遍历所有 binlog 文件从 start-position 开始重放 for binlog_file in mysql-bin.000003 mysql-bin.000004 mysql-bin.000005; do if [ $binlog_file mysql-bin.000003 ]; then mysqlbinlog --start-position${START_POS} ${binlog_file} | mysql -u${MYSQL_USER} -p${MYSQL_PASS} else mysqlbinlog ${binlog_file} | mysql -u${MYSQL_USER} -p${MYSQL_PASS} fi done注意重放 binlog 时如果 binlog 中存在DROP、DELETE等误操作这些操作也会被重放。所以如果灾难原因是误删除数据而我们需要找回被删除的数据就不能盲目重放整个 binlog而是应该使用mysqlbinlog的--stop-position参数在误操作语句之前停止。例如假设误删除的DELETE FROM flight.orders WHERE id 2;发生在 binlog 位置 5000那么重放时应该在位置 5000 之前停止避免把删除操作也执行一遍。这种情况下的恢复方式比较特殊我们会在第 5 节“常见问题与排查思路”中单独讲解。4.5 验证恢复结果重放完 binlog 后登录 MySQL 验证数据。USE flight; SELECT * FROM orders;预期输出-------------------------------------------------------------- | id | order_no | passenger_name | amount | create_time | -------------------------------------------------------------- | 1 | FL20250101 | 张三 | 1999.00 | 2025-01-10 02:00:10 | | 3 | FL20250103 | 王五 | 3299.00 | 2025-01-10 02:00:10 | | 4 | FL20250104 | 赵六 | 3999.00 | 2025-01-10 10:15:20 | | 5 | FL20250105 | 孙七 | 1599.00 | 2025-01-10 10:16:05 | --------------------------------------------------------------这时候你会发现id2 的数据仍然没有恢复。这是因为如果我们把 10:15 之后的 binlog 全量重放那么误删除的DELETE语句也会被执行数据自然就没了。想要把 id2 的数据恢复回来我们需要在重放 binlog 时跳过那条DELETE语句。4.6 “闪回”恢复跳过误操作语句严格来说MySQL 本身没有 Oracle 那样的闪回查询功能。但是我们可以通过 binlog 手动过滤掉误操作语句再重放。这就是“基于 binlog 的闪回恢复”思路。步骤如下查看 binlog 中DELETE FROM flight.orders WHERE id 2的操作位置。在恢复时从mysql-bin.000003的位置 2731 开始一直重放到DELETE操作之前的位置。对于后续的 binlog只重放与flight.orders相关的操作跳过误操作本身。查询 binlog 内容mysqlbinlog --base64-outputDECODE-ROWS -v /data/backup/binlog/mysql-bin.000005 | grep -A 20 DELETE FROM \flight\.\orders\输出类似### DELETE FROM flight.orders ### WHERE ### 12 ### 2FL20250102 ### 3李四 ### 42599.00 ### 52025-01-10 02:00:10记下这条DELETE操作所在的 binlog 文件和 position。然后重新恢复使用--stop-position参数在该位置之前停止。例如如果DELETE操作在mysql-bin.000005的位置 4000那么重放 binlog 的命令调整如下mysqlbinlog \ --start-position2731 \ --stop-position4000 \ mysql-bin.000003 mysql-bin.000004 mysql-bin.000005 | mysql -uroot -p这样就可以跳过误删除操作恢复出 id2 的数据。5. 常见问题与排查思路“荒岛求生”演练中难免遇到各种“岛上疾病”。下面整理几个高频问题及解决方案方便读者在实战中排查。问题现象常见原因解决思路xtrabackup --prepare报错The source data directory was not processed correctly备份文件被篡改或版本不匹配确认备份文件完整确认 xtrabackup 版本与 MySQL 版本一致恢复后 MySQL 启动失败日志中提示Table mysql.innodb_table_stats doesnt exist数据目录权限异常或备份不完整重新 prepare检查/data/mysql/data目录属主是否为 mysqlbinlog 重放后数据与生产不一致重放位置错误或遗漏了部分 binlog重新确认xtrabackup_binlog_info中的起始位置核对 binlog 文件编号连续性误删除操作被重放数据丢失恢复时没有跳过误操作语句使用mysqlbinlog的--stop-position在误操作之前停止或者手工过滤 SQLbinlog 文件损坏无法重放磁盘坏道或传输过程损坏使用mysqlbinlog --force强制执行跳过损坏部分同时检查 rsync 同步是否正常灾备服务器磁盘空间不足binlog 归档过多或备份文件过大增加磁盘容量调整 binlog 保留时间压缩归档文件5.1 为什么prepare后启动 MySQL 还是失败在“荒岛求生”中这算是一个比较隐蔽的坑。如果你使用xtrabackup备份恢复时忘记prepare或者prepare时使用的版本和备份时不一致MySQL 启动时就会报错。排查步骤查看 MySQL 错误日志tail -100 /var/log/mysqld.log检查备份目录中是否存在xtrabackup_info和xtrabackup_binlog_info文件。如果不存在说明备份不完整。如果报错与 redo log 有关可以尝试删除数据目录下的#innodb_redo目录MySQL 8.0或ib_logfile*文件MySQL 5.7然后重新启动。但这是一种“绕过”方式只在恢复测试环境时使用生产环境不推荐。5.2 binlog 重放速度慢RTO 无法达标怎么办有些团队的 binlog 量非常大重放可能需要几个小时。如果 RTO 要求 1 小时就需要考虑并行恢复策略。MySQL 5.7 以上版本支持mysqlbinlog --rewrite-db和并行复制但用mysqlbinlog全量重放时是单线程的速度有限。优化思路有两个启用 MySQL 的并行复制能力把 binlog 恢复到一个临时实例然后通过主从复制的方式让从库追平数据再把流量切过去。这种方式比逐一重放 SQL 更快。使用并发重放工具例如pt-table-checksum和pt-table-sync等 Percona Toolkit 工具可以辅助数据校验和修复但重放效率提升有限。对于绝大多数中大型项目更推荐方案 1在灾备服务器上先恢复全量备份然后搭建一个临时从库从生产服务器的 binlog 追数据。这样恢复到故障点的时间可能只需要几十分钟RTO 也能显著降低。5.3 如何验证恢复后的数据是否完整“荒岛求生”最后一步不是恢复完就结束而是要验证数据可用性。推荐做以下几步检查表数量、行数是否与预期一致。抽样查询关键业务表确认最近时间点的数据存在。执行一些常用查询验证索引和存储过程是否正常。启动应用进行冒烟测试确保业务链路打通。如果要比较精确地校验数据可以通过pt-table-checksum工具在生产库和恢复库之间做数据一致性校验。不过需要注意的是在极端故障场景下生产库可能已经不可用所以这种校验更多用于“恢复演练”场景。6. 最佳实践与工程建议“荒岛求生”项目演练结束除了得到一套恢复流程我总结了几点工程建议希望对大家有实际帮助。6.1 备份文件也要“演练”很多团队的备份任务是自动化的但恢复演练却是“一年一次”甚至“从不演练”。这样会导致备份文件有问题也发现不了。最佳实践是至少每季度做一次完整的恢复演练并且每次演练都要记录 RPO 和 RTO看是否达标。6.2 备份文件与生产环境物理隔离在“荒岛求生”中灾备服务器与生产服务器是不同网络、不同机房。实际生产中备份文件不能只存在生产服务器本地否则生产服务器磁盘损坏备份也跟着丢了。务必将备份文件同步到异地、或对象存储如阿里云 OSS、腾讯云 COS中。6.3 定期检查 binlog 连续性binlog 文件中间如果缺少某一段整个恢复链路就会中断。因此建议监控 binlog 同步任务的告警。例如如果某个 binlog 文件在灾备端缺失要能及时通知到值班人员。6.4 恢复脚本需要版本化不能靠“临时敲命令”把备份、同步、恢复脚本放到 Git 仓库统一管理并在脚本中加上详细注释。这样即使负责的同事离职新接手的人也能快速上手。6.5 建立“恢复手册”恢复操作涉及多台服务器、多个命令如果全靠脑子记出错概率非常高。建议团队维护一份“容灾恢复手册”记录以下内容备份服务器地址和账号加密存储。备份文件目录结构。恢复操作详细步骤。每个关键步骤的预期结果。回滚方案恢复失败时如何回到原有状态。6.6 权限控制与审计容灾备份数据往往是最敏感的数据。备份文件的读取权限、传输通道、灾备服务器的访问权限都需要遵循最小权限原则。建议使用专门的备份账号禁止使用最高权限账号执行备份。备份文件传输使用 SSH 或加密通道。所有备份和恢复操作记录审计日志便于追踪。7. 总结与后续学习通过“荒岛求生”这个项目我们完整走了一遍“备份—故障—恢复”的容灾闭环核心收获如下理解了 RPO 和 RTO 的概念以及两者对业务的影响。掌握了xtrabackup全量备份、binlog 归档的基本方法。学会了从全量备份 binlog 重放的方式恢复数据库。学会了通过--stop-position跳过误操作语句找回被删除的数据。了解了容灾恢复中常见问题的排查思路。接下来如果你想把容灾能力再提升一个台阶可以重点学习以下内容MySQL 主从复制异步复制、半同步复制。MHAMaster High Availability或 Orchestrator 高可用方案。MySQL Group Replication组复制。基于分布式存储的备份方案如备份到 Ceph、MinIO。在实际项目中最需要优先关注的仍然是“备份数据的完整性”和“恢复流程的自动化”。不要等到灾难真的发生了才发现备份文件不可用。如果这篇文章能帮你少踩几个坑欢迎收藏备用也欢迎在评论区分享你在容灾恢复中遇到的“奇葩”问题。我是老K下期再见。