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

    • 升级

    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-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 保留关键字、ZEROFILL 列、无效的日期默认值。
    • 字符集分析：识别未使用 utf8mb4 的表。
    • GTID 验证：确保 @@gtid_mode = ON 且 @@enforce_gtid_consistency = ON。

    有关详细说明，请参阅 将 MySQL-PXC 迁移到 MySQL-MGR（步骤 1 和步骤 2）。

    4. 创建目标 MGR 实例

    在开始 operator 升级之前，创建 MySQL-MGR 8.0 实例作为迁移目标。请参考 实例创建指南，并使用以下关键设置：

    • MySQL Version: 8.0
    • Storage: 源 PXC 数据库大小的 2-3 倍
    • Resource allocation: 与源 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，后迁移

    仅当无法在维护窗口之前完成迁移时，才建议采用此方式。PXC 实例将在 operator 升级后立即变为未受管理状态。它们会继续运行，但不会再获得 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>  # 等待 pod 进入 Running 状态
    4. 如果 pod 无法恢复，请检查 PVC 状态和日志。对于持续存在的问题，请联系技术支持。

    检测到 PXC 数据不一致

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

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

    升级窗口期间 PXC 到 MGR 迁移失败

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

    1. 如果应用已切换，请将应用连接回滚到原始 PXC 端点。
    2. 验证 PXC 仍可正常运行：kubectl get perconaxtradbcluster -n <namespace>
    3. 将后续迁移推迟到计划好的维护窗口。
    4. 记录故障，供事后分析。

    :::warning 关键：在迁移完成并验证之前，不要删除 PXC CR 删除 PXC 自定义资源将删除所有关联的 pod 和数据。在下线源 PXC 实例之前，务必先验证目标 MGR 实例上的数据完整性。

    回滚注意事项

    MySQL operator 在升级后不能回滚到先前版本。如果发生严重问题：

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