mysql 8.0启用keyring_encrypted_file tde后，逻辑备份（如mysqldump）无法还原加密状态，必须通过物理备份同时保留加密数据文件、密钥文件及独立保管的主密钥（如master.key），否则恢复失败且数据永久不可访问。
MySQL 8.0 启用 TDE（如 keyring_encrypted_file）后，直接用 mysqldump 或逻辑导出无法还原加密状态——它只导出明文 SQL，不带密钥、不保留表空间加密属性。备份必须同时捕获加密数据文件 + 密钥环文件 + 主密钥（如果使用 keyring_encrypted_file），否则恢复即失败。
备份时必须包含 keyring_encrypted_file 的密钥文件和主密钥
keyring_encrypted_file 不像 keyring_file 那样把密钥明文存盘，而是用一个独立的主密钥（master key）加密整个密钥文件。这个主密钥默认不存于 MySQL 实例内，需由管理员单独保管（例如写入 HSM、Vault 或离线加密存储）。若丢失主密钥，keyring_encrypted_file 中所有密钥不可解密，整个加密表空间将永久无法访问。
- 密钥文件路径由
keyring_encrypted_file_data变量指定（不是keyring_file_data），例如/var/lib/mysql-keyring/encrypted_keyring - 主密钥通常以二进制形式存在，文件名无固定约定，但常见命名如
master.key或kek.bin；它**不会**被 MySQL 自动创建或记录位置，必须在启用插件前就明确生成并保存 - 执行备份前，先确认主密钥是否已安全归档：
ls -l /path/to/master.key，并验证其权限（应仅限 root 或 mysql 用户可读）
物理备份是唯一能保留加密状态的方式
逻辑备份（mysqldump、mydumper）输出的是 DDL+DML，不包含 .ibd 文件头中的加密标识位，也无法重建 ENCRYPTION='Y' 属性。恢复后表仍是未加密的，且原密钥环对新实例无效。
- 必须使用物理备份工具：企业版推荐
mysqlbackup（MEB），它识别keyring_encrypted_file并自动包含密钥文件路径到备份集 - 社区版只能用文件系统级拷贝（
rsync/tar），但必须严格满足：停库 or 使用--single-transaction+--flush-logs+ 确保innodb_fast_shutdown=0，否则可能备份到不一致的加密页 - 无论哪种方式，备份包中必须显式包含：
keyring_encrypted_file_data指向的文件 + 主密钥文件 + 所有.ibd、ibdata1、ib_logfile*、undo_*、doublewrite等已启用加密的文件
恢复时顺序错误会导致 ER_KEYRING_ACCESS_DENIED 或启动失败
MySQL 启动时加载 keyring_encrypted_file 插件，会立即尝试用主密钥解密密钥文件。若顺序错乱，服务根本起不来。
- 先还原主密钥文件到安全路径（如
/etc/mysql/master.key），设置权限：chown root:root /etc/mysql/master.key && chmod 600 /etc/mysql/master.key - 再还原密钥文件（
keyring_encrypted_file_data路径）及数据文件 - 修改配置文件，确保
keyring_encrypted_file_data和主密钥路径（通过keyring_encrypted_file_password或外部脚本注入）都正确；注意：该插件**不支持**在配置文件里直接写主密钥明文，需通过环境变量或启动参数传入（如mysqld --keyring-encrypted-file-password-file=/etc/mysql/master.key） - 最后启动 mysqld；若报错
Plugin 'keyring_encrypted_file' init function returned error，大概率是主密钥损坏或路径不可读
最易被忽略的一点：keyring_encrypted_file 的主密钥一旦设定，就不能靠 MySQL 自身轮换或导出——它完全脱离数据库生命周期。每次部署新实例、迁移密钥环、甚至重装系统，都必须确保主密钥与密钥文件成对出现，且字节级一致。没有它，加密就是单向锁。
