Comprobaciones previas de actualización de versiones principales para Aurora MySQL - Amazon Aurora
Proceso de comprobación previa de Aurora MySQLFormato de registro de comprobación previa de Aurora MySQLEjemplos de resultados del registro de comprobación previa de Aurora MySQLRendimiento de la comprobación previa de Aurora MySQLResumen de comprobaciones previas de actualizaciones de Community MySQLResumen de comprobaciones previas de actualizaciones de Aurora MySQL

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

La actualización de MySQL de una versión principal a otra, como, por ejemplo, pasar de MySQL 5.7 a MySQL 8.0, implica algunos cambios arquitectónicos importantes que requieren una planificación y preparación minuciosas. A diferencia de las actualizaciones de versiones secundarias, que se centran principalmente en actualizar el software del motor de base de datos y, en algunos casos, las tablas del sistema, las actualizaciones principales de MySQL suelen introducir cambios fundamentales en la forma en que la base de datos almacena y administra sus metadatos.

Para ayudarle a identificar dichas incompatibilidades, al actualizar de la versión 2 de Aurora MySQL a la versión 3, Aurora ejecuta automáticamente comprobaciones de compatibilidad de actualizaciones (comprobaciones previas) para examinar los objetos del clúster de base de datos e identificar las incompatibilidades conocidas que pueden impedir que se lleve a cabo la actualización. Para obtener información detallada sobre las comprobaciones previas de Aurora MySQL, consulte Referencia de descripciones de comprobaciones previas de Aurora MySQL. Las comprobaciones previas de Aurora se ejecutan junto con las que lleva a cabo la utilidad del comprobador de actualización de Community MySQL.

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

  • Pueden reducir la posibilidad de que se produzcan errores de actualización que puedan provocar un tiempo de inactividad prolongado.

  • Si hay incompatibilidades, Amazon Aurora impedirá que se lleve a cabo la actualización y proporcionará un registro para que obtenga más información sobre ellas. Luego podrá usar el registro para preparar la base de datos para la actualización a la versión 3 y resolver así las incompatibilidades. Para obtener información detallada sobre cómo resolver incompatibilidades, consulte la sección Preparing your installation for upgrade en la documentación de MySQL y la sección 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.

Las comprobaciones previas se ejecutan antes de que el clúster de base de datos se desconecte para la actualización de la versión principal. 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.

Una vez completadas las comprobaciones previas, Aurora registra información detallada sobre cada incompatibilidad en el archivo upgrade-prechecks.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.

nota

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. Para obtener más información sobre los aspectos a tener en cuenta con respecto al rendimiento de las comprobaciones previas, consulte Proceso de comprobación previa de Aurora MySQL.

Contenido

Proceso de comprobación previa de Aurora MySQL

Tal y como se ha indicado anteriormente, el proceso de actualización de Aurora MySQL implica la ejecución de comprobaciones de compatibilidad (comprobaciones previas) en la base de datos antes de continuar con la actualización de la versión principal.

En el caso de las actualizaciones locales, las comprobaciones previas se ejecutan en la instancia de base de datos de escritor mientras esté en línea. Si la comprobación previa se realiza correctamente, se llevará a cabo la actualización. Si se encuentran errores, se registrarán en el archivo upgrade-prechecks.log y se cancelará la actualización. Antes de volver a intentar la actualización, resuelva los errores que aparezcan en el archivo upgrade-prechecks.log.

En el caso de las actualizaciones de restauración de instantánea, la comprobación previa se ejecuta durante el proceso de restauración. Si se realiza correctamente, la base de datos se actualizará a la nueva versión de Aurora MySQL. Si se encuentran errores, se registrarán en el archivo upgrade-prechecks.log y se cancelará la actualización. Antes de volver a intentar la actualización, resuelva los errores que aparezcan en el archivo upgrade-prechecks.log.

Para obtener más información, consulte Determinación del motivo de los errores en una actualización de la versión principal de Aurora MySQL y Referencia de descripciones de comprobaciones previas de Aurora MySQL.

Para supervisar el estado de la comprobación previa, puede ver los siguientes eventos en el clúster de la base de datos.

Estado de la comprobación previa Mensaje de evento Acción

Started

Preparación de la actualización en curso: se están iniciando las comprobaciones previas de la actualización en línea.

 Ninguna

Con error

El clúster de la base de datos tiene un estado que no se puede actualizar: se ha producido un error en las comprobaciones previas de la actualización. Para obtener más información, consulte el archivo upgrade-prechecks.log.

Para obtener más información sobre cómo solucionar la causa del error de actualización, consulte

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html

Revise el archivo upgrade-prechecks.log por si tiene errores.

Corrija los errores.

Vuelva a intentar la actualización.

Succeeded

Preparación de la actualización en curso: se han completado las comprobaciones previas de la actualización en línea.

Se ha realizado correctamente la comprobación previa y no se ha devuelto ningún error.

Revise el archivo upgrade-prechecks.log por si hay advertencias y avisos.

Para obtener más información sobre la visualización de eventos, consulte Consulta de eventos de Amazon RDS.

Formato de registro de comprobación previa de Aurora MySQL

Una vez finalizadas las comprobaciones de compatibilidad de las actualizaciones (comprobaciones previas), puede revisar el archivo upgrade-prechecks.log. En el archivo de registro se incluyen los resultados, los objetos afectados y la información de corrección de cada comprobación previa.

Los errores bloquean la actualización. Debe resolverlos antes de volver a intentar la actualización.

Las advertencias y los avisos son menos importantes, pero le recomendamos que los revise detenidamente para asegurarse de que no haya problemas de compatibilidad con la carga de trabajo de la aplicación. Resuelva de inmediato cualquier problema que se detecte.

El archivo de registro tiene el formato siguiente:

  • targetVersion: la versión compatible con MySQL de la actualización de Aurora MySQL.

  • auroraServerVersion: la versión de Aurora MySQL en la que se ha ejecutado la comprobación previa.

  • auroraTargetVersion: la versión de Aurora MySQL a la que está actualizando.

  • checksPerformed: incluye la lista de comprobaciones previas realizadas.

  • id: el nombre de la comprobación previa que se está ejecutando.

  • title: una descripción de la comprobación previa que se está ejecutando.

  • status: esto no indica si la comprobación previa se ha realizado correctamente o si se ha producido un error en ella, pero muestra el estado de la consulta de comprobación previa:

    • OK: la consulta de comprobación previa se ha ejecutado y completado correctamente.

    • ERROR: no se ha podido ejecutar la consulta de comprobación previa. Esto puede ocurrir debido a problemas, como, por ejemplo, las limitaciones de recursos, los reinicios inesperados de la instancia o la interrupción de la consulta de comprobación previa de la compatibilidad.

      Para obtener más información, consulte este ejemplo.

  • description: una descripción general de la incompatibilidad y cómo solucionar el problema.

  • documentationLink: si procede, aquí encontrará un enlace a la documentación pertinente de Aurora MySQL o MySQL. Para obtener más información, consulte Referencia de descripciones de comprobaciones previas de Aurora MySQL.

  • detectedProblems: si la comprobación previa devuelve un error, una advertencia o un aviso, se mostrarán los detalles de la incompatibilidad y los objetos incompatibles, si procede:

    • level: el nivel de incompatibilidad detectado por la comprobación previa. A continuación, se muestran los niveles válidos:

      • Error: no se puede continuar con la actualización hasta que se resuelva la incompatibilidad.

      • Warning: se puede continuar con la actualización, pero se ha detectado un objeto, una sintaxis o una configuración obsoletos. Revise detenidamente las advertencias y resuélvalas de inmediato para evitar problemas en futuras versiones.

      • Notice: se puede continuar con la actualización, pero se ha detectado un objeto, una sintaxis o una configuración obsoletos. Revise detenidamente los avisos y resuélvalos de inmediato para evitar problemas en futuras versiones.

    • dbObject: el nombre del objeto de la base de datos en el que se ha detectado la incompatibilidad.

    • description: una descripción detallada de la incompatibilidad y cómo solucionar el problema.

  • errorCount: el número de errores de incompatibilidad detectados. Bloquean la actualización.

  • warningCount: el número de advertencias de incompatibilidad detectadas. No bloquean la actualización, pero resuélvalas de inmediato para evitar problemas en futuras versiones.

  • noticeCount: el número de avisos de incompatibilidad detectados. No bloquean la actualización; resuélvalos de inmediato para evitar problemas en futuras versiones.

  • Summary: un resumen del número de errores, advertencias y avisos de compatibilidad de las comprobaciones previas.

Ejemplos de resultados del registro de comprobación previa de Aurora MySQL

En los siguientes ejemplos se muestra el resultado del registro de comprobación previa que puede ver. Para obtener más información sobre las comprobaciones previas que se ejecutan, consulte Referencia de descripciones de comprobaciones previas de Aurora MySQL.

Estado correcto de la comprobación previa; no se ha detectado ninguna incompatibilidad

La consulta de comprobación previa se ha completado correctamente. No se ha detectado ninguna incompatibilidad.

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinytext",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny text columns",
  "status": "OK",
  "detectedProblems": []
},
Estado correcto de la comprobación previa; se ha detectado un error

La consulta de comprobación previa se ha completado correctamente. Se ha detectado un error.

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexes",
  "status": "OK",
  "description": "Consider dropping the prefix indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test25.sbtest1",
        "description": "Table `test25`.`sbtest1` has an index `idx_t1` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `idx_t1` ON `test25`.`sbtest1`;"
      },
 }
Estado correcto de la comprobación previa; se ha detectado una advertencia

Se pueden devolver advertencias cuando una comprobación previa se ha realizado correctamente o se ha producido un error en ella.

En este caso, la consulta de comprobación previa se ha completado correctamente. Se han detectado dos advertencias.

{
  "id": "zeroDatesCheck",
  "title": "Zero Date, Datetime, and Timestamp values",
  "status": "OK",
  "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
  "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "global.sql_mode",
        "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      },
      {
        "level": "Warning",
        "dbObject": "session.sql_mode",
        "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      }
    ]
}
ERROR en el estado de la comprobación previa; no se ha registrado ninguna incompatibilidad

Se ha producido un error en la consulta de comprobación previa, por lo que no se han podido comprobar las incompatibilidades.

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "ERROR",
  "description": "Can't connect to MySQL server on 'localhost:3306' (111) at 13/08/2024 12:22:20 UTC. This failure can occur due to low memory available on the instance for executing upgrade prechecks. Please check 'FreeableMemory' Cloudwatch metric to verify the available memory on the instance while executing prechecks. If instance ran out of memory, we recommend to retry the upgrade on a higher instance class."
}

Este error puede producirse debido a un reinicio inesperado de la instancia o a la interrupción de una consulta de comprobación previa de compatibilidad en la base de datos durante la ejecución. Por ejemplo, en clases de instancias de base de datos más pequeñas, es posible que esto se produzca cuando se agote la memoria disponible en la instancia.

Puede usar la métrica FreeableMemory de Amazon CloudWatch para verificar la memoria disponible en la instancia mientras se ejecutan las comprobaciones previas. Si la instancia se ha quedado sin memoria, le recomendamos que vuelva a intentar la actualización en una clase de instancia de base de datos más grande. En algunos casos, puede utilizar una implementación azul/verde, lo que permite que las comprobaciones previas y las actualizaciones se ejecuten en el clúster de base de datos “verde” con independencia de la carga de trabajo de producción, lo que también consume recursos del sistema.

Para obtener más información, consulte Solución de problemas de uso de memoria de bases de datos Aurora MySQL.

Resumen de la comprobación previa: se han detectado un error y tres advertencias

Las comprobaciones previas de compatibilidad también incluyen información sobre las versiones de Aurora MySQL de origen y destino, así como un resumen del número de errores, advertencias y avisos, al final del resultado de la comprobación previa.

Por ejemplo, en el siguiente resultado se indica que se ha intentado actualizar de Aurora MySQL 2.11.6 a Aurora MySQL 3.07.1. La actualización ha devuelto un error, tres advertencias y ningún aviso. Dado que las actualizaciones no pueden continuar cuando se devuelve un error, debe resolver el problema de compatibilidad routineSyntaxCheck y volver a intentar la actualización.

{
  "serverAddress": "/tmp%2Fmysql.sock",
  "serverVersion": "5.7.12 - MySQL Community Server (GPL)",
  "targetVersion": "8.0.36",
  "auroraServerVersion": "2.11.6",
  "auroraTargetVersion": "3.07.1",
  "outfilePath": "/rdsdbdata/tmp/PreChecker.log",
  "checksPerformed": [{
      ... output for each individual precheck ...
      .
      .
      {
        "id": "oldTemporalCheck",
        "title": "Usage of old temporal type",
        "status": "OK",
          "detectedProblems": []
      },
      {
        "id": "routinesSyntaxCheck",
        "title": "MySQL 8.0 syntax check for routine-like objects",
        "status": "OK",
        "description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
        "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
        "detectedProblems": [{
            "level": "Error",
            "dbObject": "test.select_res_word",
            "description": "at line 2,18: unexpected token 'except'"
        }]
      },
      .
      .
      .
      {
        "id": "zeroDatesCheck",
        "title": "Zero Date, Datetime, and Timestamp values",
        "status": "OK",
        "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
        "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
        "detectedProblems": [{
            "level": "Warning",
            "dbObject": "global.sql_mode",
            "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
            },
            {
            "level": "Warning",
            "dbObject": "session.sql_mode",
            "description": " of 8 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
            }
          ]
       },
       .
       .
       .
  }],
  "errorCount": 1,
  "warningCount": 3,
  "noticeCount": 0,
  "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues."
}

Rendimiento de la comprobación previa de Aurora MySQL

Las comprobaciones previas de compatibilidad se ejecutan antes de que se desconecte la instancia de base de datos para la actualización, de modo que, en circunstancias normales, no provocan tiempos de inactividad en la instancia de base de datos al ejecutarse. Sin embargo, pueden afectar a la carga de trabajo de la aplicación que se ejecuta en la instancia de base de datos del escritor. Las comprobaciones previas acceden al diccionario de datos a través de las tablas de information_schema, lo que puede ser lento si hay muchos objetos de base de datos. Tenga en cuenta los siguientes factores:

  • La duración de la comprobación previa varía en función del número de objetos de la base de datos, como, por ejemplo, tablas, columnas, rutinas y limitaciones. Los clústeres de base de datos con un gran número de objetos pueden tardar más en ejecutarse.

    Por ejemplo, removedFunctionsCheck puede tardar más y utilizar más recursos en función del número de objetos almacenados.

  • En el caso de las actualizaciones locales, el uso de una clase de instancia de base de datos mayor (por ejemplo, db.r5.24xlarge o db.r6g.16xlarge) puede ayudar a que la actualización se complete de forma más rápida al utilizar más CPU. Puede reducir el tamaño después de la actualización.

  • Las consultas en information_schema en varias bases de datos pueden ser lentas, especialmente si hay muchos objetos y en instancias de bases de datos más pequeñas. En tales casos, plantéese la posibilidad de utilizar la clonación, la restauración de instantáneas o una implementación azul/verde para las actualizaciones.

  • El uso de recursos de comprobación previa (CPU, memoria) puede aumentar con más objetos, lo que se traduce en tiempos de ejecución más prolongados en instancias de base de datos más pequeñas. En tales casos, plantéese la posibilidad de probar la clonación, la restauración de instantáneas o una implementación azul/verde para las actualizaciones.

    Si se produce un error en las comprobaciones previas por falta de recursos, puede detectarlo en el registro de comprobaciones previas mediante el resultado de estado:

    "status": "ERROR",

Para obtener más información, consulte Cómo funciona la actualización de la versión principal en el lugar Aurora MySQL y Planificación de una actualización de versión principal para un clúster Aurora MySQL.

Resumen de comprobaciones previas de actualizaciones de Community MySQL

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 sobre las comprobaciones previas que se ejecutan, consulte Referencia de descripciones de comprobaciones previas de Aurora MySQL.

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. Para obtener una descripción general de los cambios en MySQL 8.0, consulte la sección What is new in MySQL 8.0 en la documentación de MySQL.

Resumen de comprobaciones previas de actualizaciones de Aurora MySQL

Aurora MySQL tiene sus propios requisitos específicos al actualizar de la versión 2 a la versión 3, entre los que se incluyen los siguientes:

  • 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 desencadenadores de una base de datos deben 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 mediante 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.

Para obtener más información sobre las comprobaciones previas que se ejecutan, consulte Referencia de descripciones de comprobaciones previas de Aurora MySQL.