将 MySQL-PXC 迁移到 MySQL-MGR

本指南详细介绍如何在 Alauda Container Platform 上将 MySQL-PXC（Percona XtraDB Cluster）5.7 迁移到 MySQL Group Replication（MGR）8.0。

背景面临的挑战解决方案环境信息 PXC 与 MGR：主要差异常见使用场景前提条件重要限制开始使用 1. 获取 MySQL Root 密码 2. 确定 Pod 名称 3. 验证集群状态 4. kubectl Exec 最佳实践执行指南步骤 1：Schema 兼容性分析修复 Schema 问题步骤 2：字符集和排序规则分析转换为 utf8mb4 步骤 3：创建目标 MySQL-MGR 8.0 实例步骤 4：迁移数据、用户和权限步骤 5：验证迁移步骤 6：迁移后优化 1. 更新表统计信息 2. 检查碎片应用切换步骤 7：将应用切换到目标实例 1. 验证应用已停止 2. 更新应用连接字符串 3. 重启应用 4. 验证应用功能监控灾难恢复回滚计划常见问题和解决方案问题：GTID_PURGED 错误问题：字符集转换错误问题：DEFINER 权限错误问题：身份验证插件错误故障排除诊断命令最佳实践迁移前规划迁移期间迁移后参考大小与时间估算 mysqldump 标志参考有用的链接

背景

面临的挑战

MySQL 5.7 已于 2023 年 10 月达到生命周期终止（EOL），并且从 Alauda Data Services Relational Database E1 v4.3.0 开始，MySQL-PXC 已弃用并被移除。组织必须迁移到 MySQL 8.0，才能继续接收安全更新并利用新功能。

迁移生产数据库涉及复杂的考量：

与 MySQL 8.0 保留关键字的架构兼容性
字符集变更（utf8mb4）
身份验证插件更新
确保迁移期间的数据完整性

解决方案

本指南提供了将 MySQL-PXC 5.7 迁移到 MySQL-MGR 8.0 的完整且经过验证的操作说明：

经过验证的方法：在使用 Alauda Data Services Relational Database E1 的 ACP v4.0+ 上经过验证
完整的对象覆盖范围：迁移所有标准 MySQL 对象（表、视图、例程、触发器、事件、用户和授权）
架构兼容性：自动检查并修复 MySQL 8.0 兼容性问题
全面验证：跨 9 个对象类别进行验证
最低风险：提供详细的回滚操作步骤，并在每个步骤进行验证

环境信息

组件	版本
源端（PXC）	Percona XtraDB Cluster 5.7.44
目标端（MGR）	MySQL Group Replication 8.0.44
ACP 版本	v4.0 或更高版本
MySQL Operator	v4.0 或更高版本

PXC 与 MGR：主要差异

方面	PXC 5.7（源端）	MGR 8.0（目标端）
Pod 名称模式	`${NAME}-pxc-0`	`${NAME}-0`
容器指定符	不需要（默认为 mysql）	必需：`-c mysql`
主节点端点	`${NAME}-proxysql.${NS}.svc.cluster.local:3306`	`${NAME}-read-write.${NS}.svc.cluster.local:3306`
从节点端点	与主节点相同（由 ProxySQL 处理路由）	`${NAME}-read-only.${NS}.svc.cluster.local:3306`
复制类型	Galera（同步多主模式）	Group Replication（单主模式和异步从节点）
Secret 名称模式	`${NAME}`	`mgr-${NAME}-password`

WARNING

运行迁移命令前，请始终使用 kubectl get pod -n <namespace> 检查实际的 Pod 名称。

常见使用场景

场景	数据库大小	预计停机时间
小型数据库	< 10GB	15-30 分钟
中型数据库	10-50GB	30-60 分钟
大型数据库	50-200GB	1-2 小时
Schema 问题	任意大小	修复需额外 1-2 小时
字符集迁移	任意大小	需额外 30-60 分钟

前提条件

执行迁移前，请确保具备以下条件：

ACP v4.0 或更高版本，以及 MySQL Operator v4.0 或更高版本
一个运行正常的 MySQL-PXC 5.7 集群作为源端
已启用 GTID 模式（@@gtid_mode = ON、@@enforce_gtid_consistency = ON）
在迁移之前创建一个新的 MySQL-MGR 8.0 集群作为目标端
容量为源数据库大小 2-3 倍的存储空间
本地计算机能够连接到两个集群

重要限制

导出和导入期间必须停机，以确保数据一致性
建议的最大数据库大小：200GB（更大的数据库可能需要其他方案）
源集群必须启用 GTID
必须在迁移开始前创建目标集群
目标端的存储性能应达到或超过源端

开始使用

1. 获取 MySQL Root 密码

# For PXC 5.7 source
kubectl get secret <source-name> -n <source-namespace> -o jsonpath='{.data.root}' | base64 -d

# For MGR 8.0 target
kubectl get secret mgr-<target-name>-password -n <target-namespace> -o jsonpath='{.data.root}' | base64 -d

2. 确定 Pod 名称

# Check source PXC pods
kubectl get pod -n <source-namespace> | grep <source-name>
# Example output: source-pxc-0, source-pxc-1, source-pxc-2

# Check target MGR pods
kubectl get pod -n <target-namespace> | grep <target-name>
# Example output: target-0, target-1, target-2

3. 验证集群状态

# Check PXC source status
kubectl get mysql <source-name> -n <source-namespace>
# Expected: STATE = ready, PXCSTATE = ready

# Check MGR target status
kubectl get mysql <target-name> -n <target-namespace>
# Expected: All 3 members ready, STATUS = Running

4. kubectl Exec 最佳实践

对于 PXC 5.7（源端）：

# No container specifier needed for PXC
kubectl exec <source-name>-pxc-0 -n <namespace> -- \
  mysql -uroot -p<password> -e "SQL_HERE"

对于 MGR 8.0（目标端）：

# Always use -c mysql for MGR
kubectl exec <target-name>-0 -n <namespace> -c mysql -- \
  mysql -uroot -p<password> -e "SQL_HERE"

TIP

始终使用以下参数顺序：kubectl exec -n <namespace> <pod-name> -- <command>
在命令前使用 --（双连字符），以分隔 kubectl 选项和命令
避免将 heredoc（<<EOF）与 kubectl exec 配合使用 — 这通常会因 shell 引号问题而失败

执行指南

步骤 1：Schema 兼容性分析

在计划迁移一周前执行此分析。

运行以下命令以检测 Schema 兼容性问题：

# Check for reserved keyword columns
kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "
    SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
    FROM information_schema.COLUMNS
    WHERE LOWER(COLUMN_NAME) IN ('rank','groups','function','tables','indexes','procedure','file','process');
  "

# Check for ZEROFILL columns
kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "
    SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLUMN_TYPE
    FROM information_schema.COLUMNS
    WHERE COLUMN_TYPE LIKE '%ZEROFILL%';
  "

# Check for invalid date defaults
kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "
    SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLUMN_DEFAULT
    FROM information_schema.COLUMNS
    WHERE COLUMN_DEFAULT = '0000-00-00'
       OR COLUMN_DEFAULT = '0000-00-00 00:00:00';
  "

修复 Schema 问题

# Fix reserved keyword columns (example)
kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "
    USE db1;
    ALTER TABLE users CHANGE COLUMN rank user_rank INT;
  "

# Fix ZEROFILL columns
kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "
    USE db1;
    ALTER TABLE products MODIFY COLUMN price DECIMAL(10,2);
  "

步骤 2：字符集和排序规则分析

检查非 utf8mb4 表：

kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "
    SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION
    FROM information_schema.TABLES
    WHERE TABLE_SCHEMA NOT IN ('information_schema','mysql','performance_schema','sys')
      AND TABLE_COLLATION NOT LIKE 'utf8mb4%';
  "

转换为 utf8mb4

# Convert databases to utf8mb4
for db in ${DATABASES}; do
  kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
    mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "
      ALTER DATABASE ${db} CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
    "
done

# Convert tables to utf8mb4
for db in ${DATABASES}; do
  TABLES=$(kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
    mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -N -e "
      SELECT TABLE_NAME FROM information_schema.TABLES
      WHERE TABLE_SCHEMA = '${db}' AND TABLE_TYPE = 'BASE TABLE';
    ")

  for table in ${TABLES}; do
    echo "Converting ${db}.${table}..."
    kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
      mysql -uroot -p${SOURCE_MYSQL_PASSWORD} ${db} -e "
        ALTER TABLE ${table} CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
      "
  done
done

WARNING

对于包含较长 VARCHAR/TEXT 索引（>191 个字符）的表，可能需要调整索引长度：

ALTER TABLE users DROP INDEX idx_email;
ALTER TABLE users ADD UNIQUE INDEX idx_email (email(191));

步骤 3：创建目标 MySQL-MGR 8.0 实例

在数据迁移阶段即将开始前创建目标 MySQL-MGR 8.0 实例。

使用 Web 控制台：

选择 MySQL 版本 8.0
配置资源（由于 MySQL 8.0 的额外开销，建议内存比源集群增加 10-20%）
将存储大小设置为源数据库大小的 2-3 倍

使用命令行：

TARGET_NAME="mysql-8-target"
NAMESPACE="your-namespace"
STORAGE_SIZE="500Gi"

cat << EOF | kubectl -n $NAMESPACE apply -f -
apiVersion: middleware.alauda.io/v1
kind: Mysql
metadata:
  name: $TARGET_NAME
  namespace: $NAMESPACE
  labels:
    mysql/arch: mgr
spec:
  mgr:
    enableStorage: true
    image: {}
    members: 1
    monitor:
      enable: true
      exporter: {}
    resources:
      server:
        limits:
          cpu: "2"
          memory: 4Gi
        requests:
          cpu: "2"
          memory: 4Gi
    router:
      replicas: 1
      resources:
        limits:
          cpu: 500m
          memory: 512Mi
        requests:
          cpu: 500m
          memory: 512Mi
      svcRO:
        type: ClusterIP
      svcRW:
        type: ClusterIP
    strictSecurityModeEnabled: true
    upgradeOption: {}
    volumeClaimTemplate:
      metadata: {}
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: ${STORAGE_SIZE}
        storageClassName: dataservice-topolvmsc
      status: {}
  params:
    mysql: {}
    router:
      DEFAULT:
        max_total_connections: "200"
      logger:
        level: info
  upgradeOption:
    autoUpgrade: false
    crVersion: 4.2.0
  version: "8.0"
EOF

验证目标集群：

kubectl -n $NAMESPACE get mysql $TARGET_NAME -w
# Expected: STATE = Ready, MGRSTATE = ready

步骤 4：迁移数据、用户和权限

Warning

重要：停止应用写入

从此时起直到切换完成，应用必须保持停止状态（或严格设置为只读）。此步骤之后写入源数据库的任何数据都将丢失。

操作步骤：

停止应用写入：将应用副本数扩展为零：

kubectl scale deployment <app-name> --replicas=0 -n <app-namespace>

确定要迁移的数据库：

# List user databases (DO NOT include: information_schema, mysql, performance_schema, sys)
kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -N -e "
    SELECT SCHEMA_NAME FROM information_schema.SCHEMATA
    WHERE SCHEMA_NAME NOT IN ('information_schema','mysql','performance_schema','sys');
  "

导出和导入数据：

SOURCE_NAME="source"
SOURCE_NAMESPACE="your-namespace"
SOURCE_MYSQL_PASSWORD="source-root-password"

TARGET_NAME="mysql-8-target"
TARGET_NAMESPACE="your-namespace"
TARGET_MYSQL_PASSWORD="target-root-password"

DATABASES="db1 db2 db3"

for db in ${DATABASES}; do
  echo "Migrating database: ${db}..."

  # Export from PXC source
  kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
    mysqldump -uroot -p${SOURCE_MYSQL_PASSWORD} \
      --single-transaction \
      --quick \
      --lock-tables=false \
      --set-gtid-purged=ON \
      --routines \
      --events \
      --triggers \
      --databases ${db} \
    | grep -v "SET @@GLOBAL.GTID_PURGED" \
    | kubectl exec -i ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
      mysql -uroot -p${TARGET_MYSQL_PASSWORD}

  echo "Migrated: ${db}"
done

迁移用户和权限：

# List non-system users from PXC source
USERS=$(kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -N -e "
    SELECT CONCAT('''', User, '''@''', Host, '''')
    FROM mysql.user
    WHERE User NOT IN ('root','mysql.sys','mysql.session','mysql.infoschema',
                       'monitor','operator','clustercheck','xtrabackup','replication')
      AND User NOT LIKE 'mysql.%'
      AND Host != 'localhost';
  ")

# For each user, create user and apply grants on target
for user_host in ${USERS}; do
  echo "Migrating user: ${user_host}..."

  # Get CREATE USER statement (includes auth plugin and password hash)
  CREATEUSER=$(kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
    mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -N -e "SHOW CREATE USER ${user_host};")

  # Create user on target
  kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
    mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "${CREATEUSER};"

  # Get GRANT statements from source
  GRANTS=$(kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
    mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -N -e "SHOW GRANTS FOR ${user_host};")

  # Apply grants on target
  echo "${GRANTS}" | while read grant; do
    kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
      mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "${grant};"
  done
done

# Flush privileges on target
kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
  mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "FLUSH PRIVILEGES;"

TIP

在 MySQL 8.0 目标端上，SHOW CREATE USER 会保留原始身份验证插件和密码哈希，因此迁移后用户可以使用现有密码登录。如果需要切换到 mysql_native_password 以兼容客户端，请运行：

kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
  mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "
    ALTER USER ${user_host} IDENTIFIED WITH mysql_native_password BY '<password>';
  "

MySQL 8.4 目标端

在 MySQL 8.4 目标端上，mysql_native_password 插件默认未加载且无法启用，因此重新应用 5.7/8.0 的 SHOW CREATE USER 定义（使用 mysql_native_password）时会因 ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded 而失败。对于 8.4 目标端，请改用默认的 caching_sha2_password 插件重新创建每个用户，而不是保留原始哈希：

kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
  mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "
    CREATE USER ${user_host} IDENTIFIED BY '<password>';
  "
# then re-apply the user's GRANTs (collected above)

这要求知道或重置每个用户的密码 — mysql_native_password 哈希无法迁移到 caching_sha2_password。确保应用驱动程序/连接字符串支持 caching_sha2_password。

TIP

上述 mysqldump 流式传输方式不需要为转储文件预留磁盘空间。

步骤 5：验证迁移

TARGET_NAME="mysql-8-target"
TARGET_NAMESPACE="your-namespace"
TARGET_MYSQL_PASSWORD="target-root-password"
DATABASES="db1 db2 db3"

for db in ${DATABASES}; do
  echo "=== Verifying database: ${db} ==="

  # Compare table counts
  echo "Tables:"
  kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
    mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -N -e "SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = '${db}' AND TABLE_TYPE = 'BASE TABLE';"

  kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
    mysql -uroot -p${TARGET_MYSQL_PASSWORD} -N -e "SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = '${db}' AND TABLE_TYPE = 'BASE TABLE';"

  # Verify views execute correctly
  kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
    mysql -uroot -p${TARGET_MYSQL_PASSWORD} -N -e "
      SELECT TABLE_NAME FROM information_schema.VIEWS WHERE TABLE_SCHEMA = '${db}';
    " | while read view; do
      kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
        mysql -uroot -p${TARGET_MYSQL_PASSWORD} ${db} -e "SELECT 1 FROM ${view} LIMIT 1;" > /dev/null 2>&1 \
        && echo "✓ View ${view} OK" \
        || echo "✗ View ${view} FAILED"
    done
done

验证清单：

每个数据库中的表数量相同
每个表的行数相同
视图数量相同
所有视图均可成功执行
所有存储过程和函数均存在
所有触发器和事件均已迁移
所有用户账户均存在
所有授权均已迁移

步骤 6：迁移后优化

1. 更新表统计信息

for db in ${DATABASES}; do
  echo "Analyzing tables in ${db}..."
  TABLES=$(kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
    mysql -uroot -p${TARGET_MYSQL_PASSWORD} -N -e "
      SELECT TABLE_NAME FROM information_schema.TABLES
      WHERE TABLE_SCHEMA = '${db}' AND TABLE_TYPE = 'BASE TABLE';
    ")

  for table in ${TABLES}; do
    kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
      mysql -uroot -p${TARGET_MYSQL_PASSWORD} ${db} -e "ANALYZE TABLE ${table};" 2>&1 | grep -v "Table"
  done
done

2. 检查碎片

# Build properly-quoted comma-separated list
DB_LIST=$(echo $DATABASES | sed "s/ /','/g")
DB_LIST="'$DB_LIST'"

kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
  mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "
    SELECT TABLE_SCHEMA, TABLE_NAME,
           ROUND(DATA_FREE / 1024 / 1024, 2) AS 'Fragmentation (MB)'
    FROM information_schema.TABLES
    WHERE TABLE_SCHEMA IN ($DB_LIST)
      AND DATA_FREE > 0
    ORDER BY DATA_FREE DESC;
  "

如果发现严重碎片（>100MB），请重建表：

OPTIMIZE TABLE db1.orders;

应用切换

步骤 7：将应用切换到目标实例

1. 验证应用已停止

# Ensure application is scaled down
kubectl scale deployment <app-name> --replicas=0 -n <app-namespace>

# Verify no active connections on source
kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "SHOW PROCESSLIST;" | grep -v "Sleep"

2. 更新应用连接字符串

# Update ConfigMap or environment variables
kubectl patch configmap <app-config> -n <app-namespace> --type=json \
  -p='[{"op": "replace", "path": "/data/database-host", "value":"mysql-8-target-read-write.'${TARGET_NAMESPACE}'.svc.cluster.local"}]'

kubectl patch configmap <app-config> -n <app-namespace> --type=json \
  -p='[{"op": "replace", "path": "/data/database-port", "value":"3306"}]'

3. 重启应用

# Scale up application
kubectl scale deployment <app-name> --replicas=<original-replica-count> -n <app-namespace>

# Wait for pods to be ready
kubectl -n <app-namespace> rollout status deployment <app-name>

4. 验证应用功能

# Test database connectivity
kubectl exec <app-pod> -n <app-namespace> -- \
  mysql -h mysql-8-target-read-write.${TARGET_NAMESPACE}.svc.cluster.local \
    -uroot -p${TARGET_MYSQL_PASSWORD} -e "SELECT 1 AS test;"

# Check application logs for errors
kubectl logs -n <app-namespace> <app-pod> --tail=100 | grep -i error

监控

监控迁移后的实例 24-48 小时：

# Check MySQL 8.0 instance health
kubectl -n ${TARGET_NAMESPACE} get mysql ${TARGET_NAME} -w

# Monitor error logs
kubectl logs -n ${TARGET_NAMESPACE} ${TARGET_NAME}-0 -c mysql --tail=100 -f

灾难恢复

回滚计划

如果切换后发现严重问题：

# 1. Stop application
kubectl scale deployment <app-name> --replicas=0 -n <app-namespace>

# 2. Update connection string back to source
kubectl patch configmap <app-config> -n <app-namespace> --type=json \
  -p='[{"op": "replace", "path": "/data/database-host", "value":"'${SOURCE_NAME}'-proxysql.'${SOURCE_NAMESPACE}'.svc.cluster.local"}]'

# 3. Restart application
kubectl scale deployment <app-name> --replicas=<original-replica-count> -n <app-namespace>

# 4. Verify connectivity
kubectl exec <app-pod> -n <app-namespace> -- \
  mysql -h ${SOURCE_NAME}-proxysql.${SOURCE_NAMESPACE}.svc.cluster.local \
    -uroot -p${SOURCE_MYSQL_PASSWORD} -e "SELECT 1 AS test;"

WARNING

在确认迁移完成且回滚窗口已过之前，请勿删除 PXC 自定义资源。

常见问题和解决方案

问题：GTID_PURGED 错误

症状：

ERROR 3546 (HY000) at line XX: Cannot update GTID_PURGED with the Group Replication plugin running

解决方案：迁移操作步骤中已通过使用 grep -v "SET @@GLOBAL.GTID_PURGED" 进行过滤来处理

问题：字符集转换错误

症状：

ERROR 1366 (HY000): Incorrect string value

解决方案：

kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
  mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "
    ALTER DATABASE ${db} CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
  "

问题：DEFINER 权限错误

症状：

ERROR 1449 (HY000): The user specified as a definer ('user'@'host') does not exist

解决方案：

# Find all objects with missing definers
kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
  mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "
    SELECT DISTINCT DEFINER
    FROM information_schema.VIEWS
    WHERE TABLE_SCHEMA = '${db}';
  "

问题：身份验证插件错误

症状：

ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded

解决方案（MySQL 8.0 目标实例）：对于无法协商 caching_sha2_password 的旧客户端，将用户切换到 mysql_native_password：

kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
  mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "
    ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
    FLUSH PRIVILEGES;
  "

解决方案（MySQL 8.4 目标实例）：mysql_native_password 在 8.4 中不可用（ERROR 1524: Plugin 'mysql_native_password' is not loaded），因此无法回退到该插件。请改为将客户端驱动程序/连接器升级到支持 caching_sha2_password 的版本（并使用 TLS，因为 caching_sha2_password 要求在非本地连接上进行初始密码交换时使用 TLS）。让用户继续使用默认的 caching_sha2_password 插件。

故障排除

诊断命令

检查迁移进度：

kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
  mysql -uroot -p${TARGET_MYSQL_PASSWORD} -e "SHOW PROCESSLIST;"

kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
  mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -e "SHOW PROCESSLIST;"

验证数据完整性：

for db in ${DATABASES}; do
  echo "=== Database: ${db} ==="
  kubectl exec ${SOURCE_NAME}-pxc-0 -n ${SOURCE_NAMESPACE} -- \
    mysql -uroot -p${SOURCE_MYSQL_PASSWORD} -N -e "
      SELECT TABLE_NAME, TABLE_ROWS
      FROM information_schema.TABLES
      WHERE TABLE_SCHEMA = '${db}' AND TABLE_TYPE = 'BASE TABLE'
      ORDER BY TABLE_NAME;
    " > /tmp/source_counts.txt

  kubectl exec ${TARGET_NAME}-0 -n ${TARGET_NAMESPACE} -c mysql -- \
    mysql -uroot -p${TARGET_MYSQL_PASSWORD} -N -e "
      SELECT TABLE_NAME, TABLE_ROWS
      FROM information_schema.TABLES
      WHERE TABLE_SCHEMA = '${db}' AND TABLE_TYPE = 'BASE TABLE'
      ORDER BY TABLE_NAME;
    " > /tmp/target_counts.txt

  diff /tmp/source_counts.txt /tmp/target_counts.txt || echo "Row count differences detected!"
done

检查 MySQL 8.0 错误日志：

kubectl logs -n ${TARGET_NAMESPACE} ${TARGET_NAME}-0 -c mysql --tail=100 -f | grep -i error

最佳实践

迁移前规划

在预发布环境中测试：始终先在非生产环境中执行测试迁移
清理架构：在生产环境迁移之前修复所有架构兼容性问题
字符集迁移：提前转换为 utf8mb4（提前 3-5 天）
备份策略：确保迁移前已有最新备份可用
维护窗口：根据数据库大小安排足够的停机时间

迁移期间

停止应用写入：确保导出/导入期间没有写入操作，以保证一致性
监控进度：定期跟踪导出/导入进度
保持源实例运行：在确认迁移完成之前不要删除源实例

迁移后

全面测试：彻底测试应用功能
性能监控：监控查询性能 24-48 小时
保留源实例以便回滚：保留源集群 24-48 小时作为回滚窗口
更新文档：更新连接字符串和监控面板

参考

大小与时间估算

数据库大小	导出时间	导入时间	总停机时间
< 10GB	1-5 分钟	2-10 分钟	15-30 分钟
10-50GB	5-20 分钟	10-30 分钟	30-60 分钟
50-100GB	20-40 分钟	30-60 分钟	1-2 小时
100-200GB	40-80 分钟	1-2 小时	2-4 小时

mysqldump 标志参考

标志	用途
`--single-transaction`	使用 MVCC（InnoDB）执行一致性快照
`--quick`	一次检索一行数据（节省内存）
`--lock-tables=false`	不锁定表（依赖 single-transaction）
`--set-gtid-purged=ON`	包含 GTID 信息
`--routines`	导出存储过程和函数
`--events`	导出事件
`--triggers`	导出触发器
`--databases`	指定要导出的数据库

#将 MySQL-PXC 迁移到 MySQL-MGR

#目录

#背景

#面临的挑战

#解决方案

#环境信息

#PXC 与 MGR：主要差异

#常见使用场景

#前提条件

#重要限制

#开始使用

#1. 获取 MySQL Root 密码

#2. 确定 Pod 名称

#3. 验证集群状态

#4. kubectl Exec 最佳实践

#执行指南

#步骤 1：Schema 兼容性分析

#修复 Schema 问题

#步骤 2：字符集和排序规则分析

#转换为 utf8mb4

#步骤 3：创建目标 MySQL-MGR 8.0 实例

#步骤 4：迁移数据、用户和权限

#步骤 5：验证迁移

#步骤 6：迁移后优化

#1. 更新表统计信息

#2. 检查碎片

#应用切换

#步骤 7：将应用切换到目标实例

#1. 验证应用已停止

#2. 更新应用连接字符串

#3. 重启应用

#4. 验证应用功能

#监控

#灾难恢复

#回滚计划

#常见问题和解决方案

#问题：GTID_PURGED 错误

#问题：字符集转换错误

#问题：DEFINER 权限错误

#问题：身份验证插件错误

#故障排除

#诊断命令

#最佳实践

#迁移前规划

#迁移期间

#迁移后

#参考

#大小与时间估算

#mysqldump 标志参考

#有用的链接

将 MySQL-PXC 迁移到 MySQL-MGR

目录

背景

面临的挑战

解决方案

环境信息

PXC 与 MGR：主要差异

常见使用场景

前提条件

重要限制

开始使用

1. 获取 MySQL Root 密码

2. 确定 Pod 名称

3. 验证集群状态

4. kubectl Exec 最佳实践

执行指南

步骤 1：Schema 兼容性分析

修复 Schema 问题

步骤 2：字符集和排序规则分析

转换为 utf8mb4

步骤 3：创建目标 MySQL-MGR 8.0 实例

步骤 4：迁移数据、用户和权限

步骤 5：验证迁移

步骤 6：迁移后优化

1. 更新表统计信息

2. 检查碎片

应用切换

步骤 7：将应用切换到目标实例

1. 验证应用已停止

2. 更新应用连接字符串

3. 重启应用

4. 验证应用功能

监控

灾难恢复

回滚计划

常见问题和解决方案

问题：GTID_PURGED 错误

问题：字符集转换错误

问题：DEFINER 权限错误

问题：身份验证插件错误

故障排除

诊断命令

最佳实践

迁移前规划

迁移期间

迁移后

参考

大小与时间估算

mysqldump 标志参考

有用的链接