冷备份必须停掉mysqld进程，否则文件状态不一致导致InnoDB启动失败；需确认进程彻底退出、完整拷贝datadir和my.cnf、恢复时清空目标目录并修正权限。
说到MySQL冷备份，一个核心原则必须牢记：必须停掉mysqld进程。如果服务还在运行，直接拷贝出来的数据文件，大概率是无法启动的——这可不是什么运气问题，而是InnoDB引擎文件状态不一致导致的必然失败。
停服务前必须确认 mysqld 已彻底退出
很多人习惯性地执行一句systemctl stop mysql就以为万事大吉，殊不知残留的后台进程会悄无声息地破坏数据一致性。要确认服务是否真的“停稳了”，得看这几处：
- 先用
ps aux | grep mysqld仔细检查，看看是否还有mysqld或其守护进程mysqld_safe在后台运行。 - 执行
systemctl is-active mysql，只有当返回值是inactive时，才算真正停止。 - 别忘了检查
/var/lib/mysql/mysqld.pid这个文件是否存在。如果它还在，往往意味着进程没有干净退出。 - 一旦发现残留进程，需要强制结束：
kill -9 $(cat /var/lib/mysql/mysqld.pid)，然后手动删除那个pid文件。
拷贝时只认 datadir 和 my.cnf，其他日志/插件目录不是必须
冷备份的核心目标，是确保InnoDB引擎在恢复时能够正确重放日志并加载数据。因此，不是把整个MySQL安装目录打包带走，而是要精准拷贝关键部分：
- 必须拷贝的：整个数据目录（默认是
/var/lib/mysql）下的所有内容，包括那些隐藏的关键文件，比如.ibd、ibdata1、ib_logfile*，以及mysql/、performance_schema/等系统数据库目录。 - 必须拷贝的：主配置文件，通常是
/etc/my.cnf，也可能是/etc/mysql/mysqld.conf.d/mysqld.cnf。这里面定义的innodb_log_file_size、innodb_page_size等参数至关重要，错一个都可能导致启动直接报错。 - 可以忽略的：像
/var/log/mysql（错误日志可以丢弃重建）、/var/run/mysqld（存放socket和pid的临时目录）、以及/usr/lib/mysql/plugin/（插件SO文件，如果漏了，恢复后SHOW PLUGINS会显示DISABLED，但可以后续单独同步）。
解压后权限和文件完整性比压缩命令本身更关键
即便你用了tar -czf这样可靠的压缩命令，恢复失败十有八九也卡在了解压之后的步骤上：
- 目标目录必须先清空：在恢复前，务必执行
rm -rf /var/lib/mysql/*，将目标数据目录彻底清空。切忌直接覆盖解压，否则旧的ib_logfile*日志文件与新配置的大小不匹配，会直接报错：InnoDB: Error: log file ./ib_logfile0 is of different size。 - 权限修正要及时：解压完成后，立刻执行
chown -R mysql:mysql /var/lib/mysql。如果漏掉这一步，mysqld进程可能因为无权访问文件而静默退出，或者抛出Can‘t open the mysql.plugin table这类权限错误。 - 文件数量要核对：一个简单的完整性校验方法是，对比恢复后目录的文件数和解压前备份包内的文件数。可以用
find /var/lib/mysql -type f | wc -l和tar -tzf backup.tar.gz | wc -l来比对。
恢复后启动失败，先盯住错误日志里的三个关键词
如果恢复后启动MySQL失败了，先别急着反复重启。直接打开错误日志（通常是/var/log/mysql/error.log或mysqld.err），重点排查这几个关键词：
- 看到
InnoDB: Database page corruption on disk？这通常意味着在停止服务前，脏页没有完全刷盘，或者在拷贝过程中间出现了磁盘空间不足等问题。 - 遇到
Table 'mysql.plugin' doesn't exist？大概率是文件权限没改对，或者mysql/系统数据库目录下的文件在拷贝时被遗漏了。 - 提示
keyring_file_datanot found？这说明源数据库开启了表加密（innodb_encrypt_tables=ON），但迁移时忘了把对应的密钥文件一并拷贝过去。
说到底，冷备份操作看似简单，真正的难点在于“停得干净、拷得完整、解得干净、权得正确”。这四步环环相扣，任何一步出了岔子，都可能让你卡在最后启动的那一关。
