Alauda Database Service for MySQL-MGR
  • 简体中文

    • 升级

    WARNING

    Alauda Database Service for MySQL v4.3.0 中移除 PXC MySQL-PXC 已弃用，并且从 Alauda Database Service for MySQL v4.3.0 开始已移除。现有的 PXC 实例将继续运行，但不再由 MySQL operator 管理。如果你有 PXC 实例，必须在升级到 MySQL Operator v4.3.0 或更高版本之前将其迁移到 MySQL-MGR。

    Alauda Database Service for MySQL-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 实例：

    kubectl get perconaxtradbcluster -A

    如果未找到 PXC 实例，则跳过其余步骤。

    2. 评估迁移紧迫性

    场景需要执行的操作
    升级到 MySQL Operator 4.2.xPXC 仍受管理。请在未来升级到 4.3+ 之前规划迁移。
    升级到 MySQL Operator 4.3.0+在 operator 升级后，PXC 会立即变为未受管理状态。必须在升级前完成迁移。

    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 自定义资源：

    kubectl delete perconaxtradbcluster <pxc-instance-name> -n <namespace>

    如果不再需要，请清理 PVC：

    kubectl delete pvc -l app.kubernetes.io/instance=<pxc-instance-name> -n <namespace>

    PXC 升级场景

    以下场景适用于升级到 MySQL Operator v4.3.0 或更高版本 时：

    场景 1：没有 PXC 实例

    无需额外操作。继续执行标准的 MySQL operator 升级。

    场景 2：存在 PXC 实例 — 在升级前先迁移

    如果集群中存在 PXC 实例，则必须在升级 MySQL operator 之前将其迁移到 MySQL-MGR。迁移完成并验证后，即可继续执行标准升级。

    步骤：

    1. 识别所有 PXC 实例：kubectl get perconaxtradbcluster -A
    2. 针对每个实例，按照 将 MySQL-PXC 迁移到 MySQL-MGR 指南执行。
    3. 验证原生应用已连接到新的 MGR 端点。
    4. 下线 PXC 实例。
    5. 继续执行 MySQL operator 升级。

    场景 3：存在 PXC 实例 — 先升级 operator，后迁移

    WARNING

    仅当无法在维护窗口之前完成迁移时，才建议采用此方法。operator 升级后，PXC 实例会立即变为未受管理状态。它们将继续运行，但不会再接收 operator 更新、备份或故障转移支持。

    如果必须先升级 operator：

    1. 按照标准操作步骤升级 MySQL operator。
    2. 升级完成后，PXC 实例仍会继续运行，但处于未受管理状态。
    3. 尽快规划并执行 PXC 到 MGR 的迁移。
    4. 在未受管理期间，密切监控 PXC 实例的任何问题。

    场景 4：混合集群（部分 PXC，部分 MGR）

    同时包含 PXC 和 MGR 实例的集群可以升级，但在 operator 升级后，只有 MGR 实例会继续受管理。对于每个 PXC 实例，请选择场景 2（先迁移）或场景 3（先升级，后迁移）之一。

    PXC 紧急响应方案

    如果 PXC 实例在 operator 升级期间或升级后处于未受管理状态时出现问题，请使用以下操作：

    升级后 PXC pod 未运行

    由于 PXC 实例不再由 operator 管理，因此不会发生自动恢复。

    1. 检查 pod 状态： 
      kubectl get pod -n <namespace> | grep <pxc-instance-name>
kubectl describe pod <pxc-pod-name> -n <namespace>
    2. 手动重启 PXC pod： 
      kubectl delete pod <pxc-pod-name> -n <namespace>
    3. 验证恢复情况： 
      kubectl get pod -n <namespace>  # Wait for pod to reach Running state
    4. 如果 pod 未恢复，请检查 PVC 状态和日志。对于持续性问题，请联系技术支持。

    检测到 PXC 数据不一致

    如果怀疑存在数据不一致：

    1. 立即停止写入到受影响的 PXC 实例，以防止进一步分歧。
    2. 确定升级前最后一个已知正常的备份。
    3. 评估恢复方案：
      • 如果有最近的备份且可接受数据丢失窗口，则从备份恢复。
      • 如果无法接受数据丢失，请联系技术支持寻求帮助。
    4. 恢复后，优先完成 PXC 到 MGR 的迁移，以恢复受管理状态。

    升级窗口内 PXC 到 MGR 迁移失败

    如果无法在维护窗口内完成迁移：

    1. 如果原生应用已经切换，则将应用连接回滚到原始 PXC 端点。
    2. 确认 PXC 仍在正常运行：kubectl get perconaxtradbcluster -n <namespace>
    3. 将后续迁移推迟到计划好的维护窗口。
    4. 记录此次失败，以便进行事后分析。
    重要：在迁移完成并验证之前，不要删除 PXC CR

    删除 PXC 自定义资源将删除所有相关的 pod 和数据。在下线源 PXC 实例之前，务必先验证目标 MGR 实例上的数据完整性。

    回滚考虑

    MySQL operator 无法在升级后回滚到之前的版本。如果发生严重问题：

    • PXC 实例会继续运行（它们不会受到 operator 升级本身的影响，只会因为失去 operator 管理而受到影响）。
    • MySQL-MGR 实例将继续正常运行。
    • 请联系技术支持评估问题并确定后续步骤。