ApsaraDB RDS:Upgrade the database version

Selección del método de actualización

Tanto Method 1: Directly upgrade the database version in the console como Method 2: Upgrade the database version using DTS admiten las siguientes rutas de actualización de MySQL: de 5.5 a 5.6, de 5.6 a 5.7, de 5.7 a 8.0 y de 8.0 a 8.4. Antes de actualizar la base de datos, seleccione el método adecuado según la siguiente información:

• Si su instancia pertenece a una de las cuatro categorías siguientes y su configuración cumple con los requisitos correspondientes, utilice Method 1: Directly upgrade the database version in the console.

  Nota

  Las instancias serverless no admiten actualizaciones directas desde la consola. Debe utilizar Method 2: Upgrade the database version using DTS.

  Cluster Edition (ESSD and premium performance disk)

  • Restricción de replicación de grupo: No es posible actualizar instancias de Cluster Edition que utilizan MySQL Group Replication (MGR).

  • Restricción del proxy de base de datos (si aplica): Para actualizaciones de 5.7 a 8.0, la versión secundaria del proxy de base de datos debe ser 1.13.41 o posterior. Para actualizaciones de 8.0 a 8.4, la versión secundaria del proxy de base de datos debe ser 2.25.11 o posterior.

  • Restricción de estado de la instancia: El estado de la instancia debe ser Running, y los nodos primario y secundario deben estar en buen estado sin retraso de replicación.

  • Restricción de motor: La base de datos y todas sus tablas deben usar el motor de almacenamiento InnoDB.

  • La instancia no debe utilizar un phased-out instance type.

  High-availability Edition (ESSD and premium performance disk)

  • Restricción del proxy de base de datos (si aplica): Para actualizaciones de 5.7 a 8.0, la versión secundaria del proxy de base de datos debe ser 1.13.41 o posterior. Para actualizaciones de 8.0 a 8.4, la versión secundaria del proxy de base de datos debe ser 2.25.11 o posterior.

  • Restricción de estado de la instancia: El estado de la instancia debe ser Running, y los nodos primario y secundario deben estar en buen estado sin retraso de replicación.

  • Restricción de motor: La base de datos y todas sus tablas deben usar el motor de almacenamiento InnoDB.

  • La instancia no debe utilizar un phased-out instance type.

  High-availability Edition (premium performance local disk)

  • Restricción de cifrado: La función de cifrado transparente de datos (TDE) debe estar deshabilitada. Una vez habilitado TDE, no se puede deshabilitar. Si TDE está habilitado en su instancia, debe utilizar Method 2: Upgrade the database version using DTS.

  • Restricción del proxy de base de datos (si aplica): Para actualizaciones de 5.7 a 8.0, la versión secundaria del proxy de base de datos debe ser 1.13.41 o posterior. Para actualizaciones de 8.0 a 8.4, la versión secundaria del proxy de base de datos debe ser 2.25.11 o posterior.

  • Restricción de estado de la instancia: El estado de la instancia debe ser Running, y los nodos primario y secundario deben estar en buen estado sin retraso de replicación.

  • Restricción de cantidad de tablas: El número de tablas no puede exceder 1 millón.

  • Restricción de motor: La base de datos y todas sus tablas deben usar el motor de almacenamiento InnoDB.

  • Restricción de tipo de instancia: La versión de la base de datos tras la actualización debe ser compatible con los tipos de instancia originales de las instancias primaria y de solo lectura. Las instancias no deben utilizar un tipo obsoleto. Para más información, consulte Primary ApsaraDB RDS for MySQL instance types.

  Basic Edition (ESSD and premium performance disk)

  • Restricción de estado de la instancia: El estado de la instancia debe ser Running.

  • Restricción de motor: La base de datos y todas sus tablas deben usar el motor de almacenamiento InnoDB.

  • La instancia no debe utilizar un phased-out instance type.

• Si su instancia no pertenece a ninguna de las cuatro categorías anteriores o si TDE está habilitado, utilice Method 2: Upgrade the database version using DTS.

• Si su instancia pertenece a una de las cuatro categorías anteriores pero su configuración no cumple con los requisitos, puede modificar la configuración como se describe en la siguiente tabla. Posteriormente, podrá utilizar Method 1: Directly upgrade the database version in the console o Method 2: Upgrade the database version using DTS.

  Problema	Solución
  El estado de la instancia no es Running; por ejemplo, está en Restarting.	Espere a que finalice la tarea actual antes de actualizar la versión de la base de datos.
  El número de tablas en una instancia de High-availability Edition con disco local de alto rendimiento supera 1 millón.	Elimine las tablas redundantes antes de la actualización.
  Algunas bases de datos o tablas no usan el motor InnoDB.	Ejecute el comando ALTER TABLE <table_name> engine=InnoDB; para cambiar al motor InnoDB.
  La instancia utiliza un phased-out instance type.	Actualice el tipo de instancia antes de actualizar la versión de la base de datos. Para más información, consulte Change configuration.
  La versión secundaria del proxy de base de datos no cumple con los requisitos.	Actualice la versión secundaria del proxy de base de datos a 1.13.41 o posterior. Para más información, consulte Upgrade the minor engine version of a database proxy.
  El tipo de almacenamiento de la instancia es SSD estándar.	Primero, upgrade the standard SSD to an enterprise SSD (ESSD), y luego actualice la versión de la base de datos.

Para actualizar la versión principal de otros motores de base de datos, consulte los siguientes temas:

• Upgrade the major database version of an ApsaraDB RDS for PostgreSQL instance

• Upgrade the major database version of an ApsaraDB RDS for SQL Server instance

Método 1: Actualización directa de la versión desde la consola

Método 2: Actualización de la versión mediante DTS

Para instancias que no admiten una actualización directa desde la consola, puede crear una nueva instancia con una versión de base de datos posterior. Luego, utilice una tarea de migración de datos de DTS para migrar los datos de la instancia original a la nueva. Esto actualiza la versión de la base de datos de forma indirecta. Este proceso implica los siguientes pasos:

1. Create a new instance

2. Migrate data to the new instance

3. Release the original instance

Ejemplo: Tiene una instancia de MySQL 5.7 con TDE habilitado, la cual no se puede actualizar directamente desde la consola. En este caso, puede crear una nueva instancia que ejecute MySQL 8.0, migrar los datos de la instancia original a la nueva y finalmente liberar la instancia original. Esto actualiza la versión de la base de datos de manera indirecta.

Apéndice 1: Beneficios de actualizar de MySQL 8.0 a MySQL 8.4

• Mayor estabilidad a largo plazo. MySQL 8.4 es una versión LTS adecuada para uso prolongado en entornos de producción. Las versiones posteriores 8.4.x se centran en estabilidad, correcciones de seguridad y mantenimiento de compatibilidad.

• Autenticación mejorada. Admite autenticación WebAuthn/FIDO2. Enterprise Edition puede usar claves de seguridad, biometría y otros métodos de autenticación. En Windows, se admite la autenticación SASL LDAP/GSSAPI/Kerberos.

• Capacidades GTID mejoradas. Admite GTID etiquetados. Puede usar el formato UUID:TAG:NUMBER para distinguir diferentes dominios de negocio, operaciones administrativas o de datos, y el privilegio TRANSACTION_GTID_TAG proporciona control de acceso.

• Disponibilidad de replicación mejorada. El aplicador multihilo admite SQL_AFTER_GTIDS, por lo que la replicación paralela puede continuar cuando una réplica alcanza un conjunto GTID específico.

• Recuperación de relay log mejorada. Admite la limpieza de transacciones incompletas al final del relay log y archivos residuales relacionados, lo que reduce el riesgo de recuperación causado por inconsistencias en el relay log tras un apagado anómalo.

• Operaciones de Group Replication mejoradas. Dentro de la serie 8.4 LTS, se admiten miembros de grupo entre versiones y reducciones de versión in situ; la espera de operaciones DDL y DCL durante un cambio de primario es más completa, y se admite la limpieza previa de información de autenticación en modo primario único para reducir riesgos de memoria y cambios.

• Estadísticas mejoradas. Los histogramas admiten control de actualización automática o manual, lo que mejora la capacidad de gestión del mantenimiento de estadísticas del optimizador.

• Diagnóstico de planes de ejecución mejorado. EXPLAIN FORMAT=JSON admite selección de versión de formato, EXPLAIN FORMAT=JSON INTO escribe la salida en una variable de usuario, y se admiten EXPLAIN FOR SCHEMA y FOR DATABASE, lo que facilita el diagnóstico de SQL entre esquemas.

• Validación de certificados TLS mejorada. Admite validación de certificados TLS más estricta para mejorar la seguridad de las conexiones cifradas.

• Clone mejorado. Dentro de la misma serie principal o secundaria, la operación de clonación ya no requiere una coincidencia exacta de versión puntual, lo que facilita la inicialización, recuperación y escalado de instancias entre versiones 8.4.x.

• Auditoría y firewall mejorados. Enterprise Firewall admite recargas periódicas de caché y esquemas de objetos internos personalizados para mayor flexibilidad operativa.

• Migración de gestión de claves mejorada. Admite migración de un componente keyring a un plugin keyring, lo que mejora la flexibilidad para escenarios de migración de cifrado y compatibilidad.

• Observability de actualización mejorada. El directorio de datos mantiene un archivo mysql_upgrade_history en formato JSON que registra el historial de instalación y actualización para auditoría y solución de problemas.

• Evolución de SQL y optimizador mejorada. Agrega palabras clave como TABLESAMPLE, QUALIFY y PARALLEL para proporcionar una base para futuras extensiones de SQL y del optimizador.

Apéndice 2: Beneficios de actualizar de MySQL 5.7 a MySQL 8.0

• Mejora la seguridad y ofrece mayor flexibilidad en la gestión de cuentas.

• Admite la creación y gestión de grupos de recursos.

• Mejora las funciones del motor de almacenamiento InnoDB.

• Agrega compatibilidad con nuevos conjuntos de caracteres, tipos de datos, sintaxis, nuevos bloqueos de copia de seguridad y banderas optimizer_switch.

• Mejora la funcionalidad JSON y XML.

• Mejora las funciones del optimizador.

• Mejora el rendimiento de la replicación.

• Admite la creación de índices de múltiples valores y optimización de derivación de condiciones.

• Admite la lectura de tablas de privilegios de MySQL.

• Admite control de asignación de recursos.

Apéndice 3: Beneficios de actualizar de MySQL 5.6 a MySQL 5.7

• Agrega funciones como gestión de contraseñas, bloqueo de cuentas y conexiones cifradas para mejorar la seguridad de la base de datos.

• Admite operaciones DDL en línea, como renombrar un índice mediante RENAME INDEX.

• Mejora la escalabilidad del motor InnoDB y el rendimiento de tablas temporales para una carga de datos más rápida.

• Admite JSON.

• Admite Index Condition Pushdown (ICP) para tablas particionadas y nuevos índices espaciales de InnoDB.

• Optimiza la mayoría de los analizadores sintácticos, optimizadores y modelos de costos para mejorar la mantenibilidad, escalabilidad y rendimiento de la base de datos.

• Amplía el rango de conjuntos de caracteres admitidos, incluido el conjunto de caracteres GB18030 especificado por el estándar nacional chino.

• Proporciona el plugin analizador de texto completo ngram, que admite chino, japonés y coreano.

• Optimiza los hilos de volcado de origen para reducir la contención de bloqueos y aumentar el throughput del origen.

• Reduce significativamente el retraso de replicación.

• Agrega la base de datos del sistema sys, que proporciona múltiples métricas y reduce el uso de almacenamiento, mejorando significativamente la usabilidad de la base de datos.

Apéndice 4: Diferencias de funciones entre MySQL 8.4 y MySQL 8.0

Apéndice 5: Diferencias de funciones entre MySQL 8.0 y MySQL 5.7

Apéndice 6: Diferencias de funciones entre MySQL 5.7 y MySQL 5.6

Apéndice 7: Diferencias de funciones entre MySQL 5.5 y MySQL 5.6

Preguntas frecuentes

• P: ¿Por qué ocurre un cambio de instancia durante la actualización? ¿Existen otros riesgos graves?

  R: Para garantizar la estabilidad del servicio, las instancias con discos locales de alto rendimiento se actualizan primero en el nodo secundario y luego se realiza un cambio de instancia. Las instancias con ESSD se actualizan creando un nuevo nodo y posteriormente ejecutando un cambio de instancia. No existen otros riesgos graves. Para obtener más información sobre el impacto de un failover primario/secundario, consulte Impact of a primary/secondary failover.

• P: ¿Los nodos primario y secundario se actualizan al mismo tiempo?

  R: Al actualizar un disco local de alto rendimiento, primero se actualiza la instancia secundaria y después la instancia primaria.

• P: ¿Cómo actualizo una instancia Basic Edition que ejecuta MySQL 5.7 con SSD estándar?

  R: No es posible actualizar directamente este tipo de instancia. Para actualizar una instancia Basic Edition que ejecuta MySQL 5.7 con SSD estándar, primero debe change the storage type from standard SSD to ESSD y luego upgrade the database version.

• P: ¿Se conserva la plantilla de parámetros después de actualizar la versión de la base de datos?

  R: Depende. Si la instancia utiliza una plantilla de parámetros del sistema antes de la actualización, cambiará automáticamente a la plantilla de parámetros del sistema correspondiente para la nueva versión. Por ejemplo, una instancia que usa la plantilla de parámetros MySQL_InnoDB_5.7_High-availability_Performance cambiará a la plantilla MySQL_InnoDB_8.0_High-availability_Performance tras una actualización de MySQL 5.7 a 8.0. Sin embargo, si la instancia utiliza una plantilla de parámetros personalizada, dicha plantilla no se conservará después de la actualización.

• P: ¿Puedo modificar la instancia durante la actualización de la versión de la base de datos?

  R: No, no es posible. Solo podrá realizar otras operaciones en la instancia una vez completada la actualización.

• P: ¿La versión de la base de datos admite actualizaciones automáticas?

  R: No. Las actualizaciones automáticas de versión principal no son compatibles.

• P: ¿Puedo bajar de versión la base de datos?

  R: No, no es posible bajar de versión directamente desde la consola. Seleccione uno de los siguientes métodos según si la instancia contiene datos de negocio:

  • Con datos de negocio: Adquiera una instancia que ejecute una versión anterior, utilice DTS para migrar los datos de la instancia de versión superior a la nueva instancia de versión inferior y, finalmente, libere la instancia de versión superior una vez completada la migración. Esto reduce indirectamente la versión de la base de datos. Para obtener más información, consulte Data migration between RDS instances.

  • Sin datos de negocio: Cancele la suscripción de la instancia original y adquiera una nueva instancia que ejecute la versión anterior requerida. Para instancias de suscripción, siga el proceso de reembolso para cancelar la suscripción. Para instancias pay-as-you-go, libérelas directamente.

• P: Al actualizar una instancia de RDS for MySQL de 5.6 a 5.7 o de 5.7 a 8.0, la actualización falla. Aparece el mensaje "The current instance has a full-text index and its minor version is earlier than 20221130. Please upgrade the minor version before deleting and rebuilding the full-text index" o "The current instance contains a full-text index built in the system tablespace. Please delete and rebuild the corresponding full-text index before proceeding with the upgrade." ¿Cuál es la causa y la solución?

  R: La causa y la solución son las siguientes:

  • Causa

    Debido a un problema histórico en MySQL, al crear un índice de texto completo en una versión temprana de MySQL 5.6, este se construye en el tablespace del sistema. Al actualizar a la versión 5.7 u 8.0, un índice de texto completo en el tablespace del sistema podría causar daños en dicho tablespace. Por lo tanto, debe resolver este problema antes de la actualización para evitar la corrupción de datos y la inaccesibilidad.

    Nota

    Este problema se corrigió en la versión 20221130 de RDS for MySQL 5.6. Los índices de texto completo ahora se construyen en un tablespace independiente.

  • Solución

    Importante

    Los índices de texto completo en versiones anteriores de RDS for MySQL 5.6 se crean en el tablespace del sistema. Por lo tanto, asegúrese de que la versión desde la que actualiza sea RDS for MySQL 5.6 20221130 o posterior antes de actualizar a RDS for MySQL 5.7. Si utiliza una versión anterior, actualice primero a la última versión de RDS for MySQL 5.6.

    1. Según el nombre de la tabla indicado en el mensaje, elimine el índice de texto completo que se construyó en el tablespace del sistema.

       # Delete the full-text index.
       ALTER TABLE $table_name DROP INDEX $fts_name;

    2. Vuelva a crear el índice de texto completo.

       # Re-create the full-text index.
       ALTER TABLE $table_name ADD FULLTEXT INDEX $fts_name;

    3. Después de crear el índice, puede ejecutar la siguiente instrucción SQL para comprobar los índices de texto completo en la instancia actual. La instrucción devuelve cualquier índice de texto completo construido en el tablespace del sistema. Si la consulta devuelve un resultado vacío, la actualización de RDS for MySQL 5.6 a RDS for MySQL 5.7 no fallará debido a este problema.

       # Query for full-text indexes built in the system tablespace.
       SELECT NAME FROM information_schema.INNODB_SYS_TABLES WHERE TABLE_ID IN ( SELECT CONV(SUBSTRING_INDEX(SUBSTRING_INDEX(NAME, '_', -4),'_', 1),16,10) FROM INNODB_SYS_TABLES WHERE NAME LIKE '%fts_00000000%' AND SPACE = 0);

• P: Al actualizar una instancia de RDS for MySQL de 5.7 a 8.0, se reporta el error 267 - Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '='. ¿Cómo debo proceder?

  R: Compruebe el conjunto de caracteres y la intercalación en MySQL. Si está utilizando utf8mb4_general_ci, ejecute las siguientes instrucciones SQL para cambiarlo a utf8mb4_0900_ai_ci.

  # Modify the character set and collation of the database.
  ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;
  # Modify the character set and collation of the table.
  ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
  # Modify the character set and collation of the field.
  ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

  Si crea una tabla con la intercalación utf8mb4_general_ci en MySQL 5.7 y luego actualiza a MySQL 8.0, el sistema utiliza utf8mb4_0900_ai_ci como intercalación predeterminada. Si ejecuta una consulta que compara una columna que usa utf8mb4_general_ci con una columna que usa utf8mb4_0900_ai_ci, MySQL no podrá procesar las dos intercalaciones diferentes, lo que provocará un error.

• P: ¿El tiempo de conexión transitoria para una actualización de versión principal es siempre de 15 segundos, independientemente de si existen instancias de solo lectura?

  R: Sí, así es. Se recomienda realizar la actualización fuera del horario pico.

Operaciones de API relacionadas