轮换 mysql keyring 主密钥本身不中断业务，前提是不在轮换过程中停服务、删旧密钥或误配组件；需区分密钥轮换（更新 keystore 内 root key）与密钥迁移（更换 keystore 类型）。
轮换 MySQL keyring 主密钥本身不中断业务——只要不是在轮换过程中同时停掉服务、删旧密钥或误配组件。关键在于区分「密钥轮换」和「密钥迁移」：前者是更新已有 keystore 中的主密钥（比如重生成 root key），后者是把密钥从一个 keystore 搬到另一个（如 file → AWS KMS）。本文只讲前者。
keyring 主密钥轮换 ≠ 删除或替换整个 keystore
MySQL 的 keyring 主密钥（root key）用于加密其他数据密钥（data keys），它本身由 keystore 插件管理。轮换操作本质是生成新 root key、用它重新加密所有 data keys，再安全丢弃旧 root key。整个过程不涉及服务重启，也不影响正在使用的加密表空间或 redo/undo 加密。
-
ALTER INSTANCE ROTATE INNODB MASTER KEY是唯一官方支持的在线轮换命令，仅适用于 InnoDB 表空间加密场景，且要求 keyring 已启用 - 该命令不触发 MySQL 重启，但会短暂阻塞新加密操作（如
CREATE TABLE ... ENCRYPTION='Y'），已存在的加密表读写完全不受影响 - 执行后，旧 root key 不会立即销毁——它仍保留在 keystore 中，直到所有被它加密的 data keys 都完成重加密；这个过程是后台异步完成的，无需人工干预
- 如果你用的是
keyring_file，轮换后keyring_file_data文件内容会更新，但文件权限和路径不能变，否则下次启动会报Keyring file not found
哪些 keyring 插件真正支持在线主密钥轮换
不是所有 keyring 插件都实现 ROTATE INNODB MASTER KEY。目前只有以下插件明确支持且经生产验证：
-
keyring_file：社区版默认，支持完整轮换流程，但需确保keyring_file_data可写且磁盘不满 -
keyring_okv（Oracle Key Vault）：支持，但依赖 OKV 服务端配置，轮换实际发生在 OKV 端 -
keyring_aws_kms和keyring_hashicorp：不支持 MySQL 层面的ROTATE INNODB MASTER KEY；它们的“轮换”需在 KMS/HCP 侧操作，MySQL 仅自动使用新 CMK 解密/加密，前提是插件配置中启用了auto_rotate或类似机制 -
keyring_encrypted_file：不支持；该插件无主密钥概念，其加密密钥固定绑定于启动时提供的密码
执行前必须检查的三项配置
漏掉任意一项都会导致轮换失败或静默降级为无效操作：
- 确认
keyring_component或keyring_plugin已正确加载并处于 ACTIVE 状态：SELECT * FROM performance_schema.keyring_component_status;或SHOW PLUGINS LIKE 'keyring%'; - 确保
innodb_encrypt_tables=ON且至少有一个加密表存在（否则ROTATE INNODB MASTER KEY会成功返回但无实质动作） - 检查
keyring_file_data文件所在目录磁盘剩余空间 ≥ 2× 当前文件大小（重写过程需要临时空间）；若空间不足，命令返回成功但实际未更新密钥，日志里只有一行Failed to write keyring file，极易被忽略
轮换后验证是否真正生效
别只看命令返回 OK。真正生效的标志是 data keys 被重加密，且旧 root key 进入待清理状态：
- 查询
INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION，观察ROTATION_STATUS列：从PENDING变为ROTATING再变为ROTATED，表示完成 - 检查错误日志是否有
InnoDB: Rotated master key for tablespace类似记录；没有不代表失败，但有则说明正在推进 - 用
mysql_keyring工具（非 mysql_migrate_keyring）导出当前 root key ID：mysql_keyring --component-dir=/usr/lib/mysql/plugin --list-keys，对比轮换前后输出的 key ID 是否变化 - 注意：
keyring_file不提供删除旧 root key 的接口——它靠内部引用计数自动清理，只要没 active 的 data key 引用旧 key，下次 MySQL 重启时才会真正擦除
最常被忽略的一点：轮换主密钥后，备份恢复流程必须同步更新——如果备份时用的是旧 root key 加密的 ibd 文件，恢复到新实例时，必须确保该实例的 keyring 中仍保留旧 root key（哪怕只是临时放着），否则会报 Tablespace is encrypted but keyring plugin is not loaded 或更隐蔽的 Invalid keyring data。这不是 bug，是设计使然。
