密钥环文件是加密表空间的唯一密钥源，丢失即导致服务无法启动、数据永久不可访问；必须物理备份密钥文件、主密钥及所有加密数据文件，逻辑备份（如mysqldump）无法保留加密状态。
因为密钥环文件一旦丢失或损坏，加密的表空间将永久不可访问——MySQL启动时无法解密密钥，连服务都起不来，更别说读数据了。
keyring_file_data 指向的密钥文件是唯一密钥源
启用 keyring_file 插件后，所有表空间加密密钥（如 my_tde_key）都存于 keyring_file_data 指定的单个文件中（例如 /var/lib/mysql/keyring/keyring_file）。这个文件不是日志、不是缓存，是密钥的**唯一持久化载体**。删掉它，等于删掉所有加密表的“开门钥匙”。
常见错误现象：
- 误删该文件后重启 MySQL，报错
ER_KEYRING_ACCESS_DENIED或直接卡在启动阶段 - 用
mysqldump备份再恢复，表结构和数据看似正常，但原ENCRYPTION='Y'属性丢失，且新实例无法识别旧密钥
keyring_encrypted_file 的主密钥（master.key）必须离线保管
keyring_encrypted_file 不同于 keyring_file：它把密钥文件本身也加密了，依赖一个独立的主密钥（如 master.key）解密。这个主密钥不会被 MySQL 自动创建、不记录路径、不写入任何日志，管理员必须在启用插件前就生成并存到安全位置（如 HSM、Vault 或离线加密 U 盘）。
使用场景与风险：
- 物理备份时只拷了
keyring_encrypted_file_data指向的密钥文件，却漏了master.key→ 恢复后 MySQL 启动失败，报错Failed to decrypt keyring file - 主密钥权限设为 644 并放在
/tmp下 → 被其他用户或脚本误删/覆盖 - 用
openssl rand -base64 32 > master.key生成后未校验长度 → 实际是 44 字节（含换行），导致解密失败
逻辑备份（mysqldump/mydumper）完全无法替代密钥环备份
mysqldump 输出的是明文 SQL，不包含 .ibd 文件头里的加密标识位，也不导出密钥环内容。即使你 dump 出来再 source 回去，结果是：
- 表变成未加密状态（
ENCRYPTION='N'） - 原密钥环对新实例无效，
SELECT * FROM encrypted_table报错Tablespace is encrypted but no keyring plugin is loaded - 你根本没备份到任何密钥，只是备份了“看起来像加密表”的 DDL
所以别指望 mysqldump 能救加密表——它只适合做数据一致性校验，不是密钥环的备份手段。
物理备份必须显式包含密钥环 + 主密钥 + 加密数据文件
企业版用 mysqlbackup 可自动识别 keyring_encrypted_file 并打包密钥路径；社区版只能靠 rsync 或 tar，但必须手动确认三项全在备份包里：
-
keyring_file_data或keyring_encrypted_file_data指向的文件 - 主密钥文件（如
/etc/mysql/master.key），且权限为600、属主为root - 所有已加密的
.ibd、ibdata1、undo_*等文件（可通过SELECT SPACE, NAME, ENCRYPTION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ENCRYPTION = 'Y';查）
最容易被忽略的是：停库备份虽最安全，但业务不允许时，用 --single-transaction 必须配合 innodb_fast_shutdown=0，否则可能备份到未刷盘的加密页，恢复后出现页校验失败。
