Comprobaciones previas de actualización de versiones principales para Aurora MySQL

MySQL 8.0 presenta numerosas incompatibilidades con MySQL 5.7. Dichas incompatibilidades pueden causar problemas durante una actualización de Aurora MySQL versión 2 a la versión 3. Puede requerirse cierta preparación con respecto a su base de datos para que la actualización se realice correctamente.

Si inicia una actualización de Aurora MySQL versión 2 a la versión 3, Amazon Aurora ejecutará comprobaciones previas de forma automática para detectar estas incompatibilidades.

Estas comprobaciones previas son obligatorias. No tiene la opción de omitirlas. Las comprobaciones previas proporcionan las siguientes ventajas:

• Le permiten evitar tiempos de inactividad no planeados durante la actualización.

• Si hay incompatibilidades, Amazon Aurora impide la actualización y proporciona un registro para que se informe sobre ellas. Luego podrá usar el registro para preparar su base de datos para la actualización a la versión 3 y reducir así las incompatibilidades. Para obtener información detallada acerca de cómo eliminar incompatibilidades, consulte Preparing your installation for upgrade en la documentación de MySQL y Upgrading to MySQL 8.0? Here is what you need to know... en el blog de MySQL Server.

  Para obtener más información acerca de cómo actualizar a MySQL 8.0, consulte la sección sobre la actualización de MySQL en la documentación de MySQL.

Entre las comprobaciones previas se incluyen algunas que a su vez se incluyen con MySQL y otras que el equipo de Aurora creó específicamente. Para obtener información acerca de las comprobaciones previas que proporciona MySQL, consulte la sección sobre la utilidad del comprobador de actualización.

Las comprobaciones previas se ejecutan antes de detenerse la instancia de base de datos para la actualización, lo que quiere decir que no causan tiempos de inactividad al ejecutarse. Si las verificaciones previas encuentran una incompatibilidad, Aurora cancela automáticamente la actualización antes de detenerse la instancia de base de datos. Aurora también genera un evento por la incompatibilidad. Para obtener más información acerca de los eventos de Amazon Aurora, consulte Uso de notificaciones de eventos de Amazon RDS.

Aurora registra información detallada acerca de cada incompatibilidad en el archivo de registro PrePatchCompatibility.log. En la mayoría de los casos, la entrada de registro incluye un vínculo a la documentación de SQL para corregir la incompatibilidad. Para obtener más información acerca de cómo visualizar los archivos de registro, consulte Visualización y descripción de archivos de registro de base de datos.

Debido a la naturaleza de las comprobaciones previa, analizan objetos en su base de datos. Este análisis genera un consumo de recursos y aumenta el tiempo de ejecución de la actualización.

Comprobaciones previas de actualización de MySQL en la comunidad

A continuación, se muestra una lista general de incompatibilidades entre MySQL 5.7 y 8.0:

• Su clúster de base de datos compatible con MySQL 5.7 no puede usar características que no sean compatibles con MySQL 8.0.

  Para obtener más información, consulte la sección sobre características eliminadas en MySQL 8.0, en la documentación de MySQL.

• No debe haber ninguna infracción de la palabra clave ni de la palabra reservada. Es posible que en MySQL 8.0 haya algunas palabras clave reservadas que no estaban reservadas previamente.

  Para obtener más información, consulte la página sobre Palabras clave y palabras reservadas en la documentación de MySQL.

• Para mejorar la compatibilidad de Unicode, piense en convertir objetos que usen el conjunto de caracteres utf8mb3 para usar el conjunto de caracteres utf8mb4. El conjunto de caracteres utf8mb3 ha quedado obsoleto. Asimismo, piense en utilizar utf8mb4 para referencias de conjuntos de caracteres, en vez de utilizar utf8, ya que actualmente utf8 es un alias del conjunto de caracteres utf8mb3.

  Para obtener más información, consulte la sección sobre el conjunto de caracteres utf8mb3 (codificación Unicode UTF-8 de 3 bytes) en la documentación de MySQL.

• No debe haber tablas InnoDB con un formato de fila que no sea el predeterminado.

• No debe haber atributos de tipo de longitud ZEROFILL o display.

• Ninguna tabla particionada debe usar un motor de almacenamiento que no tenga soporte de particiones nativo.

• No tiene que haber tablas en la base de datos del sistema mysql de MySQL 5.7 que tengan el mismo nombre que una tabla usada por el diccionario de datos de MySQL 8.0.

• Ninguna tabla debe usar tipos o funciones de datos obsoletos.

• No tiene que haber nombres de restricción de clave externa que superen los 64 caracteres.

• No tiene que haber modos SQL obsoletos en su configuración de variable del sistema sql_mode.

• No tiene que haber tablas ni procedimientos almacenados que tengan elementos de columna ENUM o SET individuales que superen los 255 caracteres de longitud.

• Ninguna partición de tabla debe residir en espacios de tablas InnoDB compartidos.

• No debe haber referencias circulares en las rutas de los archivos de datos de los espacios de tablas.

• No tiene que haber consultas ni definiciones de programas almacenadas que usen calificadores ASC o DESC para cláusulas GROUP BY.

• No debe haber ninguna variable de sistema eliminada y las variables de sistema deben usar los nuevos valores predeterminados para MySQL 8.0.

• No debe haber valores de fecha, fecha y hora o marca temporal que sean cero (0).

• No debe haber inconsistencias en el esquema causadas por la eliminación o la corrupción de un archivo.

• No debe haber nombres de tablas que contengan la cadena de caracteres FTS.

• No debe haber tablas InnoDB que pertenezcan a un motor diferente.

• No debe haber nombres de tablas o esquemas que no sean válidos para MySQL 5.7.

Para obtener más información acerca de cómo actualizar a MySQL 8.0, consulte la sección sobre la actualización de MySQL en la documentación de MySQL.

Comprobaciones previas de actualización de Aurora MySQL

Aurora MySQL tiene sus propios requisitos específicos al actualizar de la versión 2 a la versión 3:

• No debe haber ninguna sintaxis SQL obsoleta, como SQL_CACHE, SQL_NO_CACHE y QUERY_CACHE, en las vistas, las rutinas, los disparadores y los eventos.

• No debe haber ninguna columna FTS_DOC_ID en ninguna tabla sin el índice FTS.

• No debe haber ninguna discrepancia en la definición de columna entre el diccionario de datos de InnoDB y la definición real de la tabla.

• Todos los nombres de bases de datos y tablas deben estar en minúscula cuando el parámetro lower_case_table_names esté configurado como 1.

• No debe haber un definidor vacío ni faltar un definidor en los eventos y disparadores, y el contexto de creación de los disparadores tiene que ser válido.

• Todos los nombres de los activadores de una base de datos tienen que ser únicos.

• La recuperación de DDL y la DDL rápida no son compatibles con la versión 3 de Aurora MySQL. No debe haber artefactos en las bases de datos relacionados con estas características.

• Las tablas con el formato de fila REDUNDANT o COMPACT no pueden tener índices de más de 767 bytes.

• La longitud del prefijo de los índices definidos en las columnas de texto tiny no puede superar los 255 bytes. Con el conjunto de caracteres utf8mb4 configurado, esto limita la longitud de prefijo admitida a 63 caracteres.

  Se permitía una longitud de prefijo mayor en MySQL 5.7 utilizando el parámetro innodb_large_prefix . Este parámetro ha quedado obsoleto en MySQL 8.0.

• No debe haber ninguna incoherencia en los metadatos de InnoDB en la tabla mysql.host.

• No debe haber ninguna discrepancia en los tipos de datos de las columnas en las tablas del sistema.

• No debe haber transacciones XA en el estado prepared.

• Los nombres de las columnas de las vistas no pueden tener más de 64 caracteres.

• Los caracteres especiales de los procedimientos almacenados no pueden ser incoherentes.

• Las tablas no pueden tener incoherencias en las rutas de los archivos de datos.