Comparación entre Aurora MySQL versión 2 y Aurora MySQL versión  3 - Amazon Aurora
Compatibilidad con el lenguaje de definición de datos (DDL) atómicosDiferencias de características entre las versiones 2 y 3 de Aurora MySQLCompatibilidad con clases de instanciaCambios de parámetrosVariables de estadoCambios de idioma inclusivos para Aurora MySQL versión 3Valores de AUTO_INCREMENTReproducción de registros binarios

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.

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. 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 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 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 y Atomic Data Definition Statement Support 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.

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).

  • 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 y Sugerencias de Aurora MySQL. Para obtener información general de uso sobre las uniones hash, consulte Optimización de combinaciones hash 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) 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.

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.

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.

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.

Para obtener una lista de todos los parámetros de clúster de Aurora MySQL, consulte Parámetros de nivel de clúster. 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. 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.

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.

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_fwd_master_dml_stmt_duration Aurora_fwd_writer_dml_stmt_duration
Aurora_fwd_master_dml_stmt_count Aurora_fwd_writer_dml_stmt_count
Aurora_fwd_master_select_stmt_duration Aurora_fwd_writer_select_stmt_duration
Aurora_fwd_master_select_stmt_count Aurora_fwd_writer_select_stmt_count
Aurora_fwd_master_errors_session_timeout Aurora_fwd_writer_errors_session_timeout
Aurora_fwd_master_open_sessions Aurora_fwd_writer_open_sessions
Aurora_fwd_master_errors_session_limit Aurora_fwd_writer_errors_session_limit
Aurora_fwd_master_errors_rpc_timeout Aurora_fwd_writer_errors_rpc_timeout

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_fwd_master_idle_timeout aurora_fwd_writer_idle_timeout
aurora_fwd_master_max_connections_pct aurora_fwd_writer_max_connections_pct
master_verify_checksum source_verify_checksum
sync_master_info sync_source_info
init_slave init_replica
rpl_stop_slave_timeout rpl_stop_replica_timeout
log_slow_slave_statements log_slow_replica_statements
slave_max_allowed_packet replica_max_allowed_packet
slave_compressed_protocol replica_compressed_protocol
slave_exec_mode replica_exec_mode
slave_type_conversions replica_type_conversions
slave_sql_verify_checksum replica_sql_verify_checksum
slave_parallel_type replica_parallel_type
slave_preserve_commit_order replica_preserve_commit_order
log_slave_updates log_replica_updates
slave_allow_batching replica_allow_batching
slave_load_tmpdir replica_load_tmpdir
slave_net_timeout replica_net_timeout
sql_slave_skip_counter sql_replica_skip_counter
slave_skip_errors replica_skip_errors
slave_checkpoint_period replica_checkpoint_period
slave_checkpoint_group replica_checkpoint_group
slave_transaction_retries replica_transaction_retries
slave_parallel_workers replica_parallel_workers
slave_pending_jobs_size_max replica_pending_jobs_size_max
pseudo_slave_mode pseudo_replica_mode

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_set_master_auto_position mysql.rds_set_source_auto_position
mysql.rds_set_external_master mysql.rds_set_external_source
mysql.rds_set_external_master_with_auto_position mysql.rds_set_external_source_with_auto_position
mysql.rds_reset_external_master mysql.rds_reset_external_source
mysql.rds_next_master_log mysql.rds_next_source_log

Valores de AUTO_INCREMENT

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).

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 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 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.