mysqldump对加密表空间完全无效，因其仅导出逻辑SQL，不读取.ibd文件及加密标识，不备份密钥环或主密钥，还原后数据未加密且无法解密。
不能用 mysqldump，必须用 mysqlbackup（MEB）做物理备份，且密钥文件和主密钥必须同步归档，否则还原后数据永久不可读。
为什么 mysqldump 对加密表空间完全无效
mysqldump 只读取 MySQL Server 层的逻辑结果，它不接触 .ibd 文件，也就看不到文件头里的加密标识位、无法识别 ENCRYPTION = 'Y' 属性。导出的 SQL 是明文 DDL+DML，还原后表空间是未加密的，原密钥环对新实例也无效。更严重的是：它压根不备份密钥环文件或主密钥，你根本没法让 InnoDB 解密已还原的加密页。
- 执行
SELECT NAME, ENCRYPTION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ENCRYPTION = 'Y'能查出哪些表空间被加密，但mysqldump对这个结果视而不见 - 即使设置了
innodb_encrypt_tables=ON，mysqldump也不会自动启用加密上下文 - 还原后启动 MySQL 时不会报错，但访问加密表会直接触发
Operating system error number 13或静默返回空结果
mysqlbackup（MEB）备份加密表空间的硬性条件
MySQL Enterprise Backup 是唯一被官方支持的方案，社区版没有等效替代——XtraBackup 在 8.0 中虽能复制 .ibd，但它不理解 keyring_encrypted_file 的主密钥绑定机制，也无法保证密钥环与数据页的原子一致性。
- MEB 版本必须与 MySQL Server 主版本严格一致（例如 MySQL 8.0.33 → MEB 8.0.33），否则备份时会跳过加密表空间元数据
- 命令中必须显式加
--use-tts参数，否则 MEB 可能忽略表空间传输所需的加密上下文描述 - 运行 MEB 的 OS 用户必须对
keyring_encrypted_file_data指向的密钥文件有读写权限（通常是/var/lib/mysql-keyring/encrypted_keyring） - MEB 会自动把主密钥（如
master.key）加密后存入备份集的backup_metadata中，但前提是启动前你已通过master_key_path正确配置并验证过该文件存在且可读
还原时最容易失败的三个顺序问题
MySQL 启动时加载 keyring_encrypted_file 插件，会在初始化阶段立即尝试用主密钥解密密钥环文件。任何路径、权限或顺序错误都会导致服务卡在启动环节，报 ER_KEYRING_ACCESS_DENIED 或直接退出。
- 先还原主密钥文件（如
/etc/mysql/master.key），再设权限：chown root:root /etc/mysql/master.key && chmod 600 /etc/mysql/master.key - 再还原 MEB 备份包里的
keyring/目录（含encrypted_keyring）到原keyring_encrypted_file_data路径 - 最后才执行
copy-back和apply-log；如果跳过apply-log，InnoDB 会因 redo 日志未合并而拒绝挂载加密 undo 表空间（8.0.16+ 才支持加密 undo） - 检查 my.cnf 是否仍含
early-plugin-load=keyring_encrypted_file.so和keyring_encrypted_file_data配置，路径必须与还原后位置完全一致
keyring_encrypted_file 的主密钥是单点故障
这个文件不是 MySQL 自动生成的，也不记录在任何系统表里。它由管理员独立生成并保管，一旦丢失，encrypted_keyring 里所有密钥都无法解密，对应的所有加密表空间将永久不可访问——连字节级恢复都救不回来。
所以每次启用 keyring_encrypted_file 前，必须手动执行一次安全归档：cp /path/to/master.key /safe/location/master.key.$(date +%F)，并验证 ls -l /safe/location/ 输出权限为 -rw-------。别指望备份脚本能自动捕获它，MEB 也不负责猜你把主密钥放哪了。
