加密表空间备份必须启用innodb_encryption_threads，否则密钥未刷新导致备份明文或恢复时报“Tablespace is encrypted but keyring plugin is not loaded”。
加密表空间备份必须启用 innodb_encryption_threads
MySQL 的 InnoDB 表空间加密（ENCRYPTION='Y'）不是“写完就自动加密存盘”那么简单。如果备份时后台线程没在工作，加密密钥可能未被正确加载或刷新，导致备份文件里数据页仍是明文或密钥状态不一致。现象是：用 mysqldump 备份后恢复，表能建、数据能查，但重启 MySQL 后报错 Tablespace is encrypted but keyring plugin is not loaded。
- 确认
keyring_file或keyring_okv插件已启用且配置路径可读写 - 设置
innodb_encryption_threads = 4（至少 1），否则加密页不会被主动刷新到磁盘 -
FLUSH TABLES WITH READ LOCK前，先执行SET GLOBAL innodb_encryption_rotate_key_age = 0强制密钥轮转完成 - 物理备份（如
xtrabackup）必须使用支持加密的版本（Percona XtraBackup ≥ 8.0.30），否则跳过加密页或报错Unsupported encryption type: 1
mysqldump 无法导出加密表的密钥信息
mysqldump 只导结构和数据，不导密钥、不导 INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION 中的 KEY_VERSION 和 ROTATION_STATUS。这意味着：即使你 dump 出来再 source 回去，新表默认是未加密的，除非显式加 ENCRYPTION='Y'，但密钥还是旧的——恢复后查 INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION 会发现 KEY_VERSION 是 0 或空。
- 导出前手动记录加密状态：
SELECT SPACE, NAME, ENCRYPTION_TYPE, KEY_VERSION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION WHERE NAME LIKE 'db_name/%'; - dump 时加
--skip-create-options，避免自动生成不含ENCRYPTION的建表语句 - 恢复后必须手工执行
ALTER TABLE t1 ENCRYPTION='Y'，且确保此时keyring已加载、密钥存在 - 不要依赖
SHOW CREATE TABLE输出判断是否加密——它不显示ENCRYPTION属性
恢复时 keyring 加载顺序决定成败
MySQL 启动时若 keyring 插件加载晚于 InnoDB 初始化，就会出现“表空间已加密但密钥不可用”，进而拒绝打开表、报错 Operating system error number 13 in a file operation（其实是权限/密钥双重失败）。这不是文件权限问题，而是密钥环根本没准备好。
- 在
my.cnf中把early-plugin-load=keyring_file.so放在 [mysqld] 段最顶部，早于plugin_load_add和所有存储引擎配置 -
keyring_file_data路径必须是绝对路径，且 MySQL 用户对该文件有读写权限（注意 SELinux/AppArmor 限制） - 恢复前检查：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'keyring%';必须返回ACTIVE - 如果用 systemd 启动，确认
ProtectHome=false和NoNewPrivileges=false，否则 keyring 文件可能被沙箱拦截
加密表空间不能跨 MySQL 版本直接拷贝
哪怕主版本号相同（如 8.0.28 → 8.0.33），InnoDB 加密格式也可能微调。直接复制 .ibd 文件过去，大概率触发 Encryption method mismatch 或静默损坏——表能打开，但 SELECT 报错 Got error -1 from storage engine。
- 跨实例迁移加密表，唯一安全方式是逻辑导出 + 密钥同步：
mysqldump+ 手动 copykeyring_file_data+ 确保目标端 keyring 插件版本兼容 - 不要尝试用
ALTER TABLE ... DISCARD TABLESPACE+ 拷贝 +IMPORT TABLESPACE恢复加密表——InnoDB 不校验密钥一致性，导入后首次访问才崩溃 - Percona XtraBackup 恢复时，必须用
--keyring-file-data显式指定密钥文件路径，不能依赖配置文件中的相对路径
加密表空间的备份与恢复，核心不在“能不能做”，而在“密钥生命周期是否全程可控”。最容易被忽略的是：密钥文件修改时间、MySQL 启动顺序、插件加载时机这三者之间毫秒级的依赖关系——差一次 reload 或一次配置遗漏，恢复就卡在第一行 SELECT 上。
