# Comparación entre Aurora MySQL versión 2 y Aurora MySQL versión 3
Utilice lo siguiente para obtener información sobre los cambios que debe tener en cuenta al actualizar el clúster de Aurora MySQL versión 2 a la versión 3.
**Topics**
+ [Compatibilidad con el lenguaje de definición de datos (DDL) atómicos](#AuroraMySQL.Compare-v2-v3-atomic-ddl)
+ [Diferencias de características entre las versiones 2 y 3 de Aurora MySQL](#AuroraMySQL.Compare-v2-v3-features)
+ [Compatibilidad con clases de instancia](#AuroraMySQL.mysql80-instance-classes)
+ [Cambios de parámetros para Aurora MySQL versión 3](#AuroraMySQL.mysql80-parameter-changes)
+ [Variables de estado](#AuroraMySQL.mysql80-status-vars)
+ [Cambios de idioma inclusivos para Aurora MySQL versión 3](#AuroraMySQL.8.0-inclusive-language)
+ [Valores de AUTO\$1INCREMENT](#AuroraMySQL.mysql80-autoincrement)
+ [Reproducción de registros binarios](#AuroraMySQL.mysql80-binlog)
## Compatibilidad con el lenguaje de definición de datos (DDL) atómicos
Uno de los cambios más importantes de MySQL 5.7 a 8.0 es la introducción del [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html). En las versiones anteriores a MySQL 8.0, el diccionario de datos de MySQL utilizaba un enfoque basado en archivos para almacenar metadatos, tales como definiciones de tablas (.frm), desencadenadores (.trg) y funciones por separado de los metadatos del motor de almacenamiento (como los de InnoDB). Esto tenía algunos problemas, como el riesgo de que las tablas quedaran [huérfanas](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html) si se producía algo inesperado durante una operación de DDL, lo que provocaba que los metadatos basados en archivos y los del motor de almacenamiento no estuvieran sincronizados.
Para solucionar este problema, MySQL 8.0 ha introducido el Atomic Data Dictionary, que almacena todos los metadatos en un conjunto de tablas internas de InnoDB en el esquema de `mysql`. Esta nueva arquitectura proporciona una forma transaccional y compatible con [ACID](https://en.wikipedia.org/wiki/ACID) para administrar los metadatos de las bases de datos, lo que resuelve el problema de DDL atómico que planteaba el antiguo enfoque basado en archivos. Para obtener más información sobre el Atomic Data Dictionary, consulte las secciones [Removal of File-based Metadata Storage](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) y [Atomic Data Definition Statement Support](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html) del *MySQL Reference Manual*.
Debido a este cambio de diseño, debe plantearse lo siguiente cuando tenga que actualizar de la versión 2 a la versión 3 de Aurora MySQL:
+ Los metadatos basados en archivos de la versión 2 se deben migrar a las nuevas tablas del diccionario de datos durante el proceso de actualización a la versión 3. Según el número de objetos de la base de datos que se migren, este proceso puede tardar algún tiempo.
+ Los cambios también han introducido algunas incompatibilidades nuevas que puede que tengan que abordarse antes de llevar a cabo la actualización de MySQL 5.7 a 8.0. Por ejemplo, la versión 8.0 tiene algunas palabras clave reservadas nuevas que podrían entrar en conflicto con los nombres de objetos existentes de la base de datos.
Para ayudarle a identificar estas incompatibilidades antes de actualizar el motor, Aurora MySQL ejecuta una serie de comprobaciones de compatibilidad de actualizaciones (comprobaciones previas) para determinar si hay algún objeto incompatible en el diccionario de la base de datos antes de actualizar el diccionario de datos. Para obtener más información sobre las comprobaciones previas, consulte [Comprobaciones previas de actualización de versiones principales para Aurora MySQL](AuroraMySQL.upgrade-prechecks.md).
## Diferencias de características entre las versiones 2 y 3 de Aurora MySQL
Las siguientes características de Amazon Aurora MySQL son compatibles en Aurora MySQL para MySQL 5.7, pero dichas características no se admiten actualmente en Aurora MySQL para MySQL 8.0:
+ No puede usar Aurora MySQL versión 3 para clústeres de Aurora Serverless v1. Aurora MySQL versión 3 funciona con Aurora Serverless v2.
+ El modo lab no se aplica a Aurora MySQL versión 3. No hay funciones de modo lab en Aurora MySQL versión 3. DDL instantáneo sustituye a la característica rápida DDL en línea que antes estaba disponible en modo lab. Para ver un ejemplo, consulte [DDL instantáneo (Aurora MySQL versión 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl).
+ La caché de consultas se elimina de la comunidad MySQL 8.0 y también de Aurora MySQL versión 3.
+ Aurora MySQL versión 3 es compatible con la característica de unión hash de la comunidad MySQL. No se utiliza la implementación específica de Aurora de uniones hash en Aurora MySQL versión 2. Para obtener información sobre el uso de combinaciones hash con una consulta paralela de Aurora, consulte [Activación de una combinación hash para clústeres de consultas paralelas](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) y [Sugerencias de Aurora MySQL](AuroraMySQL.Reference.Hints.md). Para obtener información general de uso sobre las uniones hash, consulte [Optimización de combinaciones hash](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html) en el *Manual de referencia de MySQL*.
+ El procedimiento almacenado `mysql.lambda_async` que quedó obsoleto en Aurora MySQL versión 2 se elimina en la versión 3. Para la versión 3, utilice la función asíncrona `lambda_async` en su lugar.
+ El conjunto de caracteres predeterminado en Aurora MySQL versión 3 es `utf8mb4`. En Aurora MySQL versión 2, el conjunto de caracteres predeterminado era `latin1`. Para obtener información sobre este conjunto de caracteres, consulte [El conjunto de caracteres utf8mb4 (codificación Unicode UTF-8 de 4 bytes)](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) en el *Manual de referencia de MySQL*.
Algunas funciones de Aurora MySQL están disponibles para ciertas combinaciones de versión del motor de base de datos y región AWS. Para obtener más información, consulte [Funciones admitidas en Amazon Aurora por Región de AWS y el motor de base de datos de Aurora](Concepts.AuroraFeaturesRegionsDBEngines.grids.md).
## Compatibilidad con clases de instancia
La versión 3 de Aurora MySQL admite un conjunto de clases de instancia diferente al de la versión 2 de Aurora MySQL:
+ Para instancias más grandes, puede utilizar las clases de instancias modernas, como `db.r5`, `db.r6g`, y `db.x2g`.
+ Para instancias más pequeñas, puede utilizar las clases de instancias modernas, como `db.t3` y `db.t4g`.
**nota**
Recomendamos que se usen solo las clases de instancia de base de datos T para los servidores de desarrollo y de pruebas, o para otros servidores que no se utilicen para la producción. Para obtener más información sobre las clases de instancia T, consulte [Utilización de clases de instancia T para el desarrollo y la prueba](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
Las siguientes clases de instancia de Aurora MySQL versión 2 no están disponibles para Aurora MySQL versión 3:
+ `db.r4`
+ `db.r3`
+ `db.t3.small`
+ `db.t2`
Verifique los scripts de administración en busca de instrucciones CLI que crean instancias de base de datos de Aurora MySQL. Nombres de clase de instancia codificada que no están disponibles para Aurora MySQL, versión 3. Si es necesario, modifique los nombres de las clases de instancia a los que admite Aurora MySQL versión 3.
**sugerencia**
Para verificar las clases de instancias que puede utilizar para una combinación específica de la versión de Aurora MySQL y la región AWS, utilice el comando `describe-orderable-db-instance-options` AWS CLI.
Para obtener más detalles acerca de las clases de instancia Aurora, consulte [Clases de instancia de base de datos de Amazon Aurora](Concepts.DBInstanceClass.md).
## Cambios de parámetros para Aurora MySQL versión 3
Aurora MySQL versión 3 incluye nuevos parámetros de configuración a nivel de clúster y de instancia. Aurora MySQL versión 3 también elimina algunos parámetros que estaban presentes en Aurora MySQL versión 2. Algunos nombres de parámetros se modifican como resultado de la iniciativa de un lenguaje inclusivo. Para obtener compatibilidad con versiones anteriores, puede recuperar los valores de los parámetros utilizando los nombres antiguos o los nombres nuevos. Sin embargo, debe utilizar los nombres nuevos para especificar valores de parámetro en un grupo de parámetros personalizado.
En Aurora MySQL versión 3, el valor del parámetro `lower_case_table_names` se establece permanentemente en el momento en que se crea el clúster. Si utiliza un valor no predeterminado para esta opción, configure el grupo de parámetros personalizados Aurora MySQL versión 3 antes de actualizar. A continuación, especifique el grupo de parámetros durante la operación de creación de clúster o restauración de instantáneas.
**nota**
Con una base de datos global de Aurora basada en Aurora MySQL, no se puede realizar una actualización local desde la versión 2 a la versión 3 de Aurora MySQL si el parámetro `lower_case_table_names` está activado. Utilice el método de restauración de instantáneas en su lugar.
En la versión 3 de Aurora MySQL, los parámetros `init_connect` y `read_only` no se aplican a los usuarios que tienen el privilegio `CONNECTION_ADMIN`. Esto incluye al usuario maestro de Aurora. Para obtener más información, consulte [Modelo de privilegios basado en roles](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
Para obtener una lista de todos los parámetros de clúster de Aurora MySQL, consulte [Parámetros de nivel de clúster](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster). La tabla cubre todos los parámetros de las versiones 2 y 3 de Aurora MySQL. La tabla incluye notas que muestran qué parámetros son nuevos en Aurora MySQL versión 3 o se eliminaron de Aurora MySQL versión 3.
Para obtener la lista completa de los parámetros de instancia de Aurora MySQL, consulte [Parámetros de nivel de instancia](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance). La tabla cubre todos los parámetros de las versiones 2 y 3 de Aurora MySQL. La tabla incluye notas que muestran qué parámetros son nuevos en Aurora MySQL versión 3 y qué parámetros se eliminaron de Aurora MySQL versión 3. También incluye notas que muestran qué parámetros eran modificables en versiones anteriores, pero no en Aurora MySQL versión 3.
Para obtener información sobre los nombres de parámetros que han cambiado, consulte [Cambios de idioma inclusivos para Aurora MySQL versión 3](#AuroraMySQL.8.0-inclusive-language).
## Variables de estado
Para obtener información sobre las variables de estado que no se aplican a Aurora MySQL, consulte [Variables de estado de MySQL que no se aplican a Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable).
## Cambios de idioma inclusivos para Aurora MySQL versión 3
La versión inicial de Aurora MySQL versión 3 es compatible con la versión 8.0.23 de la edición de la comunidad MySQL. Aurora MySQL versión 3 también incluye cambios de MySQL 8.0.26 relacionados con palabras clave y esquemas del sistema para un lenguaje inclusivo. Por ejemplo, ahora se prefiere el comando `SHOW REPLICA STATUS` en lugar de `SHOW SLAVE STATUS`.
Las siguientes métricas de Amazon CloudWatch tienen nuevos nombres en Aurora MySQL versión 3.
En Aurora MySQL versión 3, solo están disponibles los nuevos nombres de métricas. Asegúrese de actualizar las alarmas u otra automatización que se basa en nombres de métricas cuando actualice a Aurora MySQL versión 3.
| Nombre antiguo | Nombre nuevo |
| --- | --- |
| ForwardingMasterDMLLatency | ForwardingWriterDMLLatency |
| ForwardingMasterOpenSessions | ForwardingWriterOpenSessions |
| AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull |
| ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput |
Las siguientes variables de estado tienen nombres nuevos en Aurora MySQL versión 3.
Para obtener compatibilidad, puede utilizar cualquiera de los dos nombres en la versión inicial de Aurora MySQL versión 3. Los nombres de variables de estado anteriores se eliminarán en una próxima versión.
| Nombre que se va a eliminar | Nombre nuevo o preferido |
| --- | --- |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout |
| Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions |
| Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit |
| Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout |
Los siguientes parámetros de configuración tienen nombres nuevos en Aurora MySQL versión 3.
Para obtener compatibilidad, puede verificar los valores de los parámetros en el cliente `mysql` mediante cualquiera de los dos nombres de la versión inicial de Aurora MySQL versión 3. Solo podrá utilizar los nuevos nombres cuando modifique los valores de un grupo de parámetros personalizado. Los nombres de los parámetros anteriores se eliminarán en una próxima versión.
| Nombre que se va a eliminar | Nombre nuevo o preferido |
| --- | --- |
| aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout |
| aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct |
| master\$1verify\$1checksum | source\$1verify\$1checksum |
| sync\$1master\$1info | sync\$1source\$1info |
| init\$1slave | init\$1replica |
| rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout |
| log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements |
| slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet |
| slave\$1compressed\$1protocol | replica\$1compressed\$1protocol |
| slave\$1exec\$1mode | replica\$1exec\$1mode |
| slave\$1type\$1conversions | replica\$1type\$1conversions |
| slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum |
| slave\$1parallel\$1type | replica\$1parallel\$1type |
| slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order |
| log\$1slave\$1updates | log\$1replica\$1updates |
| slave\$1allow\$1batching | replica\$1allow\$1batching |
| slave\$1load\$1tmpdir | replica\$1load\$1tmpdir |
| slave\$1net\$1timeout | replica\$1net\$1timeout |
| sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter |
| slave\$1skip\$1errors | replica\$1skip\$1errors |
| slave\$1checkpoint\$1period | replica\$1checkpoint\$1period |
| slave\$1checkpoint\$1group | replica\$1checkpoint\$1group |
| slave\$1transaction\$1retries | replica\$1transaction\$1retries |
| slave\$1parallel\$1workers | replica\$1parallel\$1workers |
| slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max |
| pseudo\$1slave\$1mode | pseudo\$1replica\$1mode |
Los siguientes procedimientos almacenados tienen nombres nuevos en Aurora MySQL versión 3.
Para obtener compatibilidad, puede utilizar cualquiera de los dos nombres en la versión inicial de Aurora MySQL versión 3. Los nombres de procedimientos antiguos se eliminarán en una próxima versión.
| Nombre que se va a eliminar | Nombre nuevo o preferido |
| --- | --- |
| mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position |
| mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source |
| mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position |
| mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source |
| mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log |
## Valores de AUTO\$1INCREMENT
En Aurora MySQL versión 3, Aurora conserva el valor `AUTO_INCREMENT` para cada tabla cuando reinicia cada instancia de base de datos. En Aurora MySQL versión 2, no se ha conservado el valor `AUTO_INCREMENT` después de un reinicio.
El valor `AUTO_INCREMENT` no se conserva cuando configura un nuevo clúster al restaurar desde una instantánea, realizar una recuperación a un momento dado y clonar un clúster. En estos casos, el valor `AUTO_INCREMENT` se inicializa en el valor basándose en el valor de columna más grande de la tabla en el momento de crear la instantánea. Este comportamiento es diferente al de RDS for MySQL 8.0, donde el valor `AUTO_INCREMENT` se conserva durante estas operaciones.
## Reproducción de registros binarios
En la edición de la comunidad MySQL 8.0, la replicación de registros binarios está activada de forma predeterminada. En Aurora MySQL versión 3, la replicación de registros binarios está desactivada de forma predeterminada.
**sugerencia**
Si las funciones de replicación incorporadas de Aurora cumplen sus requisitos de alta disponibilidad, puede dejar desactivada la replicación de registros binarios. De esta forma, puede evitar la sobrecarga de rendimiento de la replicación de registros binarios. También puede evitar el monitoreo y la solución de problemas asociados que se necesitan para administrar la replicación de registros binarios.
Aurora admite la replicación de registros binarios desde un origen compatible con MySQL 5.7 a Aurora MySQL versión 3. El sistema de origen puede ser un clúster de bases de datos de Aurora MySQL, una instancia de base de datos de RDS for MySQL o una instancia de MySQL local.
Al igual que la comunidad MySQL, Aurora MySQL admite la replicación desde un origen que ejecuta una versión específica en un destino que ejecuta la misma versión principal o una versión principal superior. Por ejemplo, no se admite la replicación desde un sistema compatible con MySQL 5.6 a Aurora MySQL versión 3. No se admite la replicación de Aurora MySQL versión 3 a un sistema compatible con MySQL 5.7 o compatible con MySQL 5.6. Para obtener más detalles acerca de cómo utilizar replicación de registros binarios, consulte [Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario)](AuroraMySQL.Replication.MySQL.md).
Aurora MySQL versión 3 incluye mejoras en la replicación de registros binarios en la comunidad MySQL 8.0, como la replicación filtrada. Para obtener más información sobre las mejoras de MySQL 8.0 de la comunidad, consulte [Cómo evalúan los servidores las reglas de filtrado de replicación](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html) en el *Manual de referencia de MySQL*.
### Compresión de transacciones para replicación de registros binarios
Para obtener información de uso sobre la compresión de registros binarios, consulte [Compresión de transacciones de registros binarios](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html) en el Manual de referencia de MySQL.
Las siguientes limitaciones se aplican a la compresión de registros binarios en Aurora MySQL versión 3:
+ Las transacciones cuyos datos de registro binario superan el tamaño máximo permitido del paquete no se comprimen. Esto se aplica independientemente de si la configuración de compresión de registro binario de Aurora MySQL está activada. Estas transacciones se replican sin comprimirse.
+ Si utiliza un conector para la captura de datos de cambios (CDC) que aún no admite MySQL 8.0, no puede utilizar esta característica. Le recomendamos que pruebe exhaustivamente cualquier conector de terceros con compresión de registro binario. Le recomendamos que lo haga antes de activar la compresión binlog en sistemas que utilizan replicación binlog para CDC.