mysql如何备份加密的表空间_mysql加密表恢复注意事项

加密表空间备份必须启用 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 + 手动 copy keyring_file_data + 确保目标端 keyring 插件版本兼容
• 不要尝试用 ALTER TABLE …… DISCARD TABLESPACE + 拷贝 + IMPORT TABLESPACE 恢复加密表——InnoDB 不校验密钥一致性，导入后首次访问才崩溃
• Percona XtraBackup 恢复时，必须用 --keyring-file-data 显式指定密钥文件路径，不能依赖配置文件中的相对路径

加密表空间的备份与恢复，核心不在“能不能做”，而在“密钥生命周期是否全程可控”。最容易被忽略的是：密钥文件修改时间、MySQL 启动顺序、插件加载时机这三者之间毫秒级的依赖关系——差一次 reload 或一次配置遗漏，恢复就卡在第一行 SELECT 上。