ALTER INSTANCE ROTATE INNODB MASTER KEY 是唯一安全轮转方式，必须由 InnoDB 内核原子执行：生成新主密钥→重加密所有表空间密钥→保留旧密钥解密历史数据，全程不中断服务，且依赖已加载并可写的 keyring 插件。
ALTER INSTANCE ROTATE INNODB MASTER KEY 是唯一安全轮转方式
MySQL 8.0 不支持手动替换或编辑 keyring 文件里的主密钥，直接改文件会破坏密钥链完整性，导致所有加密表空间无法访问。必须用内置命令触发原子级轮转：ALTER INSTANCE ROTATE INNODB MASTER KEY。该操作由 InnoDB 内核控制：生成新 master key → 用它重加密所有表空间密钥 → 保留旧 master key 用于解密历史数据 → 整个过程不中断服务。
轮转前必须确认 keyring 插件已加载且可写
如果 keyring_file 或 component_keyring_encrypted_file 未在启动时加载（比如漏配 early-plugin-load），执行 ALTER INSTANCE ROTATE INNODB MASTER KEY 会报错 ERROR 3182 (HY000): Cannot encrypt a table when the keyring plugin is not installed，即使表已是加密状态也一样。此外，keyring_file_data 或 keyring_encrypted_file_data 指向的路径必须对 mysql 用户可写，否则轮转中途失败，密钥文件可能处于半更新状态。
- 检查插件状态：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'keyring%'; - 验证路径权限：
ls -l /var/lib/mysql-keyring/（确保属主是mysql:mysql） - 若用
component_keyring_encrypted_file，还需确认主密钥（如master.key）仍安全存在且未被误删
轮转后必须立即备份新密钥文件和主密钥
轮转本身不自动备份任何东西。新生成的 master key 已写入密钥文件（如 /var/lib/mysql-keyring/keyring 或 /var/lib/mysql-keyring/encrypted_keyring），但如果你用的是 keyring_encrypted_file，这个文件仍需用独立的主密钥（master.key）解密——而那个 master.key 并未改变，也不受轮转影响。容易忽略的关键点是：轮转不等于密钥文件备份。你仍需手动归档：
- 密钥文件本身（
keyring_file_data或keyring_encrypted_file_data指向的文件） - 若启用
keyring_encrypted_file，原始master.key必须保持离线、只读、权限为600，且不能和数据库同机存储 - 物理备份包中必须包含这两类文件，逻辑备份（
mysqldump）完全无效
不要混淆 master key 轮转与 AWS/KMS 密钥轮换
ALTER INSTANCE ROTATE INNODB MASTER KEY 只影响 MySQL 实例本地的 master key，和外部密钥管理服务无关。如果你用的是 keyring_aws，它另有两套函数：keyring_aws_rotate_cmk()（轮换 AWS KMS 的 CMK）和 keyring_aws_rotate_keys()（用新 CMK 重加密 keyring 中已存的密钥）。这两个函数必须显式调用，且需要 SUPER 权限；它们不会被 ALTER INSTANCE 命令触发，也不会互相替代。
真正容易出事的地方在于：轮转了 MySQL 的 master key，却忘了同步调用 keyring_aws_rotate_keys()，结果新表空间密钥用新 CMK 加密了，但旧密钥还卡在老 CMK 下——恢复时部分表能打开，部分报 ER_KEYRING_ACCESS_DENIED，排查极耗时间。
