升级
Alauda Data Services Relational Database E1 v4.3.0 中移除 PXC MySQL-PXC 已弃用，并且从 Alauda Data Services Relational Database E1 v4.3.0 开始移除。现有 PXC 实例将继续运行，但不再由 MySQL operator 管理。如果您有 PXC 实例，必须先将其迁移到 MySQL-MGR，然后再升级到 MySQL Operator v4.3.0 或更高版本。
- 迁移指南：将 MySQL-PXC 迁移到 MySQL-MGR，其中提供了涵盖 schema 兼容性、字符集、用户和权限的完整分步说明。
Alauda Data Services Relational Database E1-MGR 将根据配置的升级策略执行升级：
- 自动：检测到新组件版本后立即触发自动升级。
- 手动：启动升级流程前需要手动批准。
MySQL-MGR 有三种升级类型：
- 补丁版本升级 — 在同一 MySQL 主版本内（例如 8.0.x 或 8.4.x）进行升级，以获取修复和改进。请参阅补丁版本升级。
- MySQL 主版本升级（8.0 → 8.4） — 将现有的 8.0 集群原地升级到 8.4。请参阅下文。
- MySQL-PXC 到 MySQL-MGR 的迁移 — 如果仍在运行 PXC 实例，则必须在将 operator 升级到 v4.3.0 或更高版本之前完成迁移。请参阅下方的检查清单以及将 MySQL-PXC 迁移到 MySQL-MGR。
目录
MySQL 主版本升级（8.0 → 8.4）MySQL-PXC 升级前检查清单PXC 升级场景场景 1：不存在 PXC 实例场景 2：存在 PXC 实例 — 升级前迁移场景 3：存在 PXC 实例 — 先升级 operator，之后再迁移场景 4：混合集群（部分为 PXC，部分为 MGR）PXC 应急响应计划升级后 PXC pod 未运行检测到 PXC 数据不一致升级窗口期间 PXC 到 MGR 的迁移失败回滚注意事项MySQL 主版本升级（8.0 → 8.4）
从 v4.4.0 开始，您可以将现有的 MySQL 8.0 MGR 集群原地升级到 MySQL 8.4，无需重建集群或迁移数据。operator 会逐个成员执行滚动升级，保留数据和 Group Replication 成员关系，自动升级 InnoDB Cluster 元数据，并通过 MySQL Router 确保集群持续提供流量服务。
这是一次主版本升级，不可逆 — 请规划维护窗口并先进行备份。
有关前置条件和完整的分步操作步骤，请参阅将 MySQL 8.0 升级到 8.4。
MySQL-PXC 升级前检查清单
如果您的平台上有 MySQL-PXC 实例，请在升级到 MySQL Operator v4.3.0 或更高版本之前完成以下操作：
1. 识别所有 PXC 实例
在每个集群上运行以下命令，列出所有 PXC 实例：
如果未找到 PXC 实例，则跳过其余步骤。
2. 评估迁移紧迫性
3. 执行迁移前检查
迁移前，请对每个 PXC 实例运行兼容性分析：
- Schema 兼容性：检测目标 MySQL 版本（8.0 或 8.4）中的保留关键字、ZEROFILL 列以及无效的日期默认值。
- 字符集分析：识别未使用
utf8mb4的表。 - GTID 验证：确保
@@gtid_mode = ON和@@enforce_gtid_consistency = ON。
有关详细说明，请参阅将 MySQL-PXC 迁移到 MySQL-MGR（第 1 步和第 2 步）。
4. 创建目标 MGR 实例
在开始 operator 升级之前创建 MySQL-MGR 实例作为迁移目标。按照实例创建指南进行操作，并配置以下关键设置：
- MySQL 版本：
8.0或8.4。在 operator v4.4.0 及更高版本上，新实例建议使用8.4；只有在需要先匹配源版本并稍后升级到 8.4 时，才选择8.0（请参阅将 MySQL 8.0 升级到 8.4）。 - 存储：源 PXC 数据库大小的 2 到 3 倍
- 资源分配：不低于源 PXC
5. 执行完整备份
在迁移每个 PXC 实例之前，执行完整逻辑备份（mysqldump）。验证备份是否可以还原。有关详细说明，请参阅将 MySQL-PXC 迁移到 MySQL-MGR。
6. 迁移数据
使用 mysqldump 逻辑备份和还原执行迁移。有关分步说明，请参阅将 MySQL-PXC 迁移到 MySQL-MGR。
7. 验证迁移
迁移后，验证以下内容：
- MGR 实例中存在所有用户数据库。
- 应用连接指向新的 MGR 端点。
- 数据完整性检查通过（行数、校验和）。
8. 停用 PXC 实例
迁移和验证成功后，删除 PXC 自定义资源：
如果不再需要 PVC，请将其清理：
PXC 升级场景
升级到 MySQL Operator v4.3.0 或更高版本时，适用以下场景：
场景 1：不存在 PXC 实例
无需执行其他操作。按照标准 MySQL operator 升级流程继续操作。
场景 2：存在 PXC 实例 — 升级前迁移
如果集群中存在 PXC 实例，则必须在升级 MySQL operator 之前将其迁移到 MySQL-MGR。迁移完成并验证通过后，即可继续执行标准升级流程。
操作步骤：
- 识别所有 PXC 实例：
kubectl get perconaxtradbcluster -A - 按照 将 MySQL-PXC 迁移到 MySQL-MGR 指南迁移每个实例。
- 验证应用连接到新的 MGR 端点。
- 停用 PXC 实例。
- 继续升级 MySQL operator。
场景 3：存在 PXC 实例 — 先升级 operator，之后再迁移
仅当无法在维护窗口之前完成迁移时，才建议采用此方法。operator 升级完成后，PXC 实例将立即变为不受管理状态。它们将继续运行，但不会再接收 operator 更新、备份或故障转移支持。
如果必须先升级 operator：
- 按照标准操作步骤升级 MySQL operator。
- 升级后，PXC 实例仍会运行，但处于不受管理状态。
- 在升级后尽快规划并执行 PXC 到 MGR 的迁移。
- 在不受管理期间密切监控 PXC 实例是否出现任何问题。
场景 4：混合集群（部分为 PXC，部分为 MGR）
同时包含 PXC 和 MGR 实例的集群可以升级，但 operator 升级后，只有 MGR 实例会继续处于受管理状态。对于每个 PXC 实例，请选择场景 2（先迁移）或场景 3（先升级，之后再迁移）。
PXC 应急响应计划
如果 PXC 实例在不受管理状态下，于 operator 升级期间或升级后出现问题，请使用以下操作步骤：
升级后 PXC pod 未运行
PXC 实例不再由 operator 管理，因此不会执行自动恢复。
- 检查 pod 状态：
- 手动重启 PXC pod：
- 验证恢复情况：
- 如果 pod 未恢复，请检查 PVC 状态和日志。对于持续存在的问题，请联系技术支持。
检测到 PXC 数据不一致
如果怀疑存在数据不一致：
- 立即停止向受影响的 PXC 实例写入数据，以防止进一步分歧。
- 确定升级前最后一个已知正常的备份。
- 评估恢复选项：
- 如果存在近期备份且可接受该数据丢失时间窗口，请从备份恢复。
- 如果无法接受数据丢失，请联系技术支持寻求帮助。
- 恢复后，优先完成 PXC 到 MGR 的迁移，以恢复受管理状态。
升级窗口期间 PXC 到 MGR 的迁移失败
如果无法在维护窗口内完成迁移：
- 如果应用已经切换，将应用连接回滚到原始 PXC 端点。
- 验证 PXC 仍可正常运行：
kubectl get perconaxtradbcluster -n <namespace> - 将后续迁移推迟到计划中的维护窗口。
- 记录此次失败，以供事后分析。
删除 PXC 自定义资源将删除所有关联的 pod 和数据。停用源 PXC 实例前，请务必验证目标 MGR 实例上的数据完整性。
回滚注意事项
升级后，MySQL operator 无法回滚到以前的版本。如果发生严重问题：
- PXC 实例会继续运行（它们不受 operator 升级本身的影响，只会失去 operator 管理）。
- MySQL-MGR 实例会继续正常运行。
- 联系技术支持评估问题并确定后续步骤。