# Información general de Amazon Aurora MySQL
En las siguientes secciones, encontrará información general de Amazon Aurora MySQL.
**Topics**
+ [Mejoras del rendimiento de Amazon Aurora MySQL](#Aurora.AuroraMySQL.Performance)
+ [Amazon Aurora MySQL y los datos espaciales](#Aurora.AuroraMySQL.Spatial)
+ [Aurora MySQL versión 3 compatible con MySQL 8.0](AuroraMySQL.MySQL80.md)
+ [Aurora MySQL versión 2 compatible con MySQL 5.7](AuroraMySQL.CompareMySQL57.md)
## Mejoras del rendimiento de Amazon Aurora MySQL
Amazon Aurora incluye mejoras del desempeño para responder a las distintas necesidades de las bases de datos comerciales de gama alta.
### Inserción rápida
La inserción rápida acelera las inserciones paralelas ordenadas por clave principal y se aplica específicamente a las declaraciones `LOAD DATA` e `INSERT INTO ... SELECT ...`. La inserción rápida almacena en caché la posición de un cursor en un recorrido del índice mientras se ejecuta la declaración. Esto evita tener que recorrer el índice de nuevo sin necesidad.
La inserción rápida solo se ha habilitado para tablas InnoDB estándar en Aurora MySQL (versión 3.03.2 o superior). Esta optimización no funciona para las tablas temporales de InnoDB. Se ha deshabilitado en la versión 2 de Aurora MySQL para todas las versiones 2.11 y 2.12. La optimización de la inserción rápida solo funciona si se ha deshabilitado la optimización del índice hash adaptativo.
Puede monitorizar las siguientes métricas para determinar la eficacia de la inserción rápida para su clúster de bases de datos:
+ `aurora_fast_insert_cache_hits`: un contador que se incrementa cuando el cursor en caché se recupera y se verifica correctamente.
+ `aurora_fast_insert_cache_misses`: un contador que se incrementa cuando el cursor en caché deja de ser válido y Aurora realiza un recorrido normal del índice.
Puede recuperar el valor actual de las métricas de inserción rápida con el siguiente comando:
```
mysql> show global status like 'Aurora_fast_insert%';
```
Obtendrá un resultado similar al siguiente:
```
+---------------------------------+-----------+
| Variable_name | Value |
+---------------------------------+-----------+
| Aurora_fast_insert_cache_hits | 3598300 |
| Aurora_fast_insert_cache_misses | 436401336 |
+---------------------------------+-----------+
```
## Amazon Aurora MySQL y los datos espaciales
La siguiente lista resume las principales características espaciales de Aurora MySQL y explica cómo se corresponden con las características espaciales en MySQL:
+ La versión 2 de Aurora MySQL admite los mismos tipos de datos espaciales y funciones de relaciones espaciales que MySQL 5.7. Para obtener más información sobre estos tipos de datos y funciones, consulte [Tipos de datos espaciales](https://dev.mysql.com/doc/refman/5.7/en/spatial-types.html) y [Funciones de relaciones espaciales](https://dev.mysql.com/doc/refman/5.7/en/spatial-relation-functions-object-shapes.html) en la documentación de MySQL 5.7.
+ La versión 3 de Aurora MySQL admite los mismos tipos de datos espaciales y funciones de relaciones espaciales que MySQL 8.0. Para obtener más información sobre estos tipos de datos y funciones, consulte [Tipos de datos espaciales](https://dev.mysql.com/doc/refman/8.0/en/spatial-types.html) y [Funciones de relaciones espaciales](https://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-object-shapes.html) en la documentación de MySQL 8.0.
+ Aurora MySQL admite la indexación espacial en tablas InnoDB. La indexación espacial mejora el desempeño de las consultas en conjuntos de datos grandes, para consultas sobre datos espaciales. En MySQL, la indexación espacial para tablas InnoDB está disponible en MySQL 5.7 y 8.0.
Aurora MySQL usa una estrategia de indexación espacial diferente a MySQL para un alto rendimiento con consultas espaciales. La implementación del índice espacial de Aurora utiliza una curva de relleno de espacio en un árbol B, que está destinada a proporcionar un rendimiento mayor para los escaneos de rango espacial que un árbol R.
**nota**
En Aurora MySQL, una transacción de una tabla con un índice espacial definido en una columna con un identificador de referencia espacial (SRID) no puede realizar inserciones en un área seleccionada para que la actualice otra transacción.
Las siguientes declaraciones en el lenguaje de definición de datos (DDL) se admiten para crear índices en columnas que usan tipos de datos espaciales.
### CREATE TABLE
Puede usar las palabras clave `SPATIAL INDEX` en una declaración `CREATE TABLE` para añadir un índice espacial a una columna en una tabla nueva. A continuación se muestra un ejemplo.
```
CREATE TABLE test (shape POLYGON NOT NULL, SPATIAL INDEX(shape));
```
### ALTER TABLE
Puede usar las palabras clave `SPATIAL INDEX` en una declaración `ALTER TABLE` para añadir un índice espacial a una columna en una tabla existente. A continuación se muestra un ejemplo.
```
ALTER TABLE test ADD SPATIAL INDEX(shape);
```
### CREATE INDEX
Puede usar la palabra clave `SPATIAL` en una declaración `CREATE INDEX` para añadir un índice espacial a una columna en una tabla existente. A continuación se muestra un ejemplo.
```
CREATE SPATIAL INDEX shape_index ON test (shape);
```
# Aurora MySQL versión 3 compatible con MySQL 8.0
Puede utilizar Aurora MySQL versión 3 para obtener las últimas funciones compatibles con MySQL, mejoras de rendimiento y correcciones de errores. A continuación, puede obtener información sobre Aurora MySQL versión 3, con compatibilidad MySQL 8.0. Puede obtener información sobre cómo actualizar sus clústeres y aplicaciones a Aurora MySQL versión 3.
Algunas características de Aurora, como Aurora Serverless v2, requieren Aurora MySQL versión 3.
**Topics**
+ [Características de MySQL 8.0 Community Edition](#AuroraMySQL.8.0-features-community)
+ [Requisito previo de Aurora MySQL versión 3 para Aurora MySQL Serverless v2](#AuroraMySQL.serverless-v2-8.0-prereq)
+ [Notas de la versión 3 de Aurora MySQL](#AuroraMySQL.mysql80-bugs-fixed)
+ [Nuevas optimizaciones de consultas paralelas](#AuroraMySQL.8.0-features-pq)
+ [Optimizaciones para reducir el tiempo de reinicio de la base de datos](#ReducedRestartTime)
+ [Nuevo comportamiento de tabla temporal en Aurora MySQL versión 3](ams3-temptable-behavior.md)
+ [Comparación entre Aurora MySQL versión 2 y Aurora MySQL versión 3](AuroraMySQL.Compare-v2-v3.md)
+ [Comparación de Aurora MySQL versión 3 y MySQL 8.0 Community Edition](AuroraMySQL.Compare-80-v3.md)
+ [Actualización a Aurora MySQL versión 3](AuroraMySQL.mysql80-upgrade-procedure.md)
## Características de MySQL 8.0 Community Edition
La versión inicial de Aurora MySQL versión 3 es compatible con MySQL 8.0.23 Community Edition. MySQL 8.0 presenta varias funciones nuevas, entre ellas las siguientes:
+ Compatibilidad con el lenguaje de definición de datos (DDL) atómicos. Para obtener más información, consulte [Compatibilidad con el lenguaje de definición de datos (DDL) atómicos](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl).
+ Funciones JSON. Para obtener más información, consulte [Funciones JSON](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html) en el *Manual de referencia de MySQL*.
+ Funciones de ventana. Para obtener más información, consulte [Funciones de ventana](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html) en el *Manual de referencia de MySQL*.
+ Expresiones de tabla comunes (CTE), utilizando la cláusula `WITH`. Para obtener más información, consulte [WITH (expresiones de tabla comunes)](https://dev.mysql.com/doc/refman/8.0/en/with.html) en el *Manual de referencia de MySQL*.
+ Cláusulas `ADD COLUMN` y `RENAME COLUMN` optimizadas para la instrucción `ALTER TABLE`. Estas optimizaciones se denominan “DDL instantáneo”. Aurora MySQL versión 3 es compatible con la característica DDL instantánea de la comunidad MySQL. No se usa la antigua característica DDL rápida de Aurora. Para obtener información de uso de DDL instantáneo, consulte [DDL instantáneo (Aurora MySQL versión 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl).
+ Índices descendentes, funcionales e invisibles. Para obtener más información, consulte [Índices invisibles](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html), [Índices descendentes](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html), e [Instrucción CREATE INDEX](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts) en el *Manual de referencia de MySQL*.
+ Privilegios basados en roles controlados mediante instrucciones SQL. Para obtener más información sobre los cambios en el modelo de privilegios, consulte [Modelo de privilegios basado en roles](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
+ Cláusulas `NOWAIT` y `SKIP LOCKED` con la instrucción `SELECT ... FOR SHARE`. Estas cláusulas evitan esperar a que otras transacciones liberen bloqueos de fila. Para obtener más información, consulte [Lecturas de bloqueo](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html) en el *Manual de referencia de MySQL Reference*.
+ Mejoras en la replicación del registro binario (binlog). Para obtener información detallada sobre Aurora MySQL, consulte [Reproducción de registros binarios](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog). En particular, puede realizar una replicación filtrada. Para obtener información de uso sobre la replicación filtrada, 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*.
+ Sugerencias. Algunas de las sugerencias compatibles con MySQL 8.0 ya estaban respaldadas en Aurora MySQL versión 2. Para obtener información sobre el uso de las sugerencias con Aurora MySQL, consulte [Sugerencias de Aurora MySQL](AuroraMySQL.Reference.Hints.md). Para obtener lista completa de sugerencias en la comunidad MySQL 8.0, consulte [Sugerencias del optimizador](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) en el *Manual de referencia de MySQL*.
Para obtener la lista completa de funciones añadidas a la edición de la comunidad MySQL 8.0, consulte la entrada del blog [Lista completa de las nuevas características de MySQL 8.0](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/).
Aurora MySQL versión 3 también incluye cambios en las palabras clave para un lenguaje inclusivo, respaldado desde la comunidad MySQL 8.0.26. Para obtener más detalles acerca de estos cambios, consulte [Cambios de idioma inclusivos para Aurora MySQL versión 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
## Requisito previo de Aurora MySQL versión 3 para Aurora MySQL Serverless v2
Tener Aurora MySQL versión 3 es un requisito previo para todas las instancias de base de datos de un clúster de Aurora MySQL Serverless v2. Aurora MySQL Serverless v2 es compatible con instancias del lector en un clúster de base de datos y otras características de Aurora que no están disponibles para Aurora MySQL Serverless v1. También tiene un escalado más rápido y granular que Aurora MySQL Serverless v1.
## Notas de la versión 3 de Aurora MySQL
Para ver las notas de todas las versiones de Aurora MySQL versión 3, consulte el tema sobre [actualizaciones del motor de base de datos de Amazon Aurora MySQL versión 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) en las *notas de la versión de Aurora MySQL*.
## Nuevas optimizaciones de consultas paralelas
La optimización de consultas paralelas de Aurora se aplica ahora a más operaciones SQL:
+ La consulta paralela se aplica ahora a las tablas que contienen los tipos de datos `TEXT`, `BLOB`, `JSON`, `GEOMETRY`, y `VARCHAR` y `CHAR` de más de 768 bytes.
+ La consulta paralela puede optimizar las consultas que implican tablas particionadas.
+ Las consultas paralelas pueden optimizar consultas que implican llamadas a funciones agregadas en la lista de selección y en la cláusula `HAVING`.
Para obtener más información acerca de estas mejoras, consulte [Actualización de clústeres de consultas en paralelo para la versión 3 de Aurora MySQL](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). Para obtener información general sobre la consulta paralela de Aurora, consulte [Consulta paralela para Amazon Aurora MySQL](aurora-mysql-parallel-query.md).
## Optimizaciones para reducir el tiempo de reinicio de la base de datos
Su clúster de base de datos Aurora MySQL debe tener alta disponibilidad durante las interrupciones previstas e imprevistas.
Los administradores de bases de datos deben realizar un mantenimiento ocasional de la base de datos. Estas tareas de mantenimiento incluyen la aplicación de parches en la base de datos, las actualizaciones, las modificaciones de parámetros de la base de datos que requieren un reinicio manual, la realización de una conmutación por error para reducir el tiempo que tardan los cambios de clase de instancia, etc. Estas acciones previstas requieren un tiempo de inactividad.
Sin embargo, el tiempo de inactividad también puede deberse a acciones imprevistas, como una conmutación por error inesperada debida a un fallo de hardware subyacente o a la limitación de recursos de la base de datos. Todas estas acciones previstas e imprevistas provocan el reinicio de la base de datos.
En la versión 3.05 de Aurora MySQL y versiones posteriores, hemos introducido optimizaciones que reducen el tiempo de reinicio de la base de datos. Estas optimizaciones reducen hasta en un 65 % el tiempo de inactividad y las interrupciones de las cargas de trabajo de la base de datos tras un reinicio.
Durante el inicio de la base de datos, se inicializan muchos componentes de la memoria interna. El componente de mayor tamaño es el [grupo de búferes de InnoDB](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/), que en Aurora MySQL ocupa el 75 % del tamaño de la memoria de la instancia de forma predeterminada. Nuestras pruebas han revelado que el tiempo de inicialización es proporcional al tamaño de la reserva de búferes de InnoDB y, por tanto, aumenta con el tamaño de la clase de instancia de base de datos. Durante la fase de inicialización, la base de datos no puede aceptar conexiones, lo que prolonga el tiempo de inactividad durante los reinicios. La primera fase del reinicio rápido de Aurora MySQL optimiza la inicialización del grupo de búferes, lo que reduce el tiempo de inicialización de la base de datos y, por lo tanto, reduce el tiempo total de reinicio.
Para obtener más información, consulte el blog [Reduzca el tiempo de inactividad con las optimizaciones del tiempo de reinicio de bases de datos Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/).
# Nuevo comportamiento de tabla temporal en Aurora MySQL versión 3
La versión 3 de Aurora MySQL gestiona las tablas temporales de forma diferente a las versiones anteriores de Aurora MySQL. Este nuevo comportamiento se hereda de MySQL 8.0 Community Edition. Hay dos tipos de tablas temporales que se pueden crear con la versión 3 de Aurora MySQL:
+ Tablas temporales internas (o *implícitas*): las crea el motor de Aurora MySQL para gestionar algunas operaciones, como agregación de ordenación, tablas derivadas o expresiones comunes de tabla (CTE).
+ Tablas temporales creadas por el usuario (o *explícitas*): las crea el motor de Aurora MySQL cuando se utiliza la instrucción `CREATE TEMPORARY TABLE`.
Hay consideraciones adicionales para las tablas temporales, tanto internas como creadas por el usuario, en las instancias de base de datos del lector de Aurora. En las siguientes secciones se analizan estos cambios.
**Topics**
+ [Motor de almacenamiento para tablas temporales internas (implícitas)](#ams3-temptable-behavior-engine)
+ [Limitación del tamaño de las tablas temporales internas en memoria](#ams3-temptable-behavior-limit)
+ [Mitigación de los problemas de llenado de las tablas temporales internas en las réplicas de Aurora](#ams3-temptable-behavior-mitigate)
+ [Optimización del parámetro temptable\$1max\$1mmap en instancias de base de datos de Aurora MySQL](#ams-optimize-temptable_max_mmap)
+ [Tablas temporales creadas por el usuario (explícitas) en las instancias de base de datos del lector](#ams3-temptable-behavior.user)
+ [Errores de creación de tablas temporales y su mitigación](#ams3-temptable-behavior.errors)
## Motor de almacenamiento para tablas temporales internas (implícitas)
Al generar conjuntos de resultados intermedios, Aurora MySQL intenta inicialmente escribir en tablas temporales en memoria. Es posible que esto no se realice correctamente debido a tipos de datos incompatibles o a límites configurados. Si es así, la tabla temporal se convierte en una tabla temporal en el disco en lugar de mantenerse en la memoria. Puede encontrar más información al respecto en [Internal Temporary Table Use in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) (Uso de tablas temporales internas en MySQL) de la documentación de MySQL.
En Aurora MySQL versión 3, la forma en que funcionan las tablas temporales internas es diferente de las versiones anteriores de Aurora MySQL. En lugar de elegir entre los motores de almacenamiento InnoDB y MyISAM para estas tablas temporales, ahora elige entre los motores de almacenamiento `TempTable` y `MEMORY`.
Con el motor de almacenamiento `TempTable`, puede tomar una opción adicional sobre cómo manejar ciertos datos. Los datos afectados desbordan el grupo de memoria que contiene todas las tablas temporales internas de la instancia de base de datos.
Estas opciones pueden influir en el rendimiento de las consultas que generan grandes volúmenes de datos temporales, por ejemplo, al realizar agregaciones tales como `GROUP BY` sobre tablas grandes.
**sugerencia**
Si la carga de trabajo incluye consultas que generan tablas temporales internas, confirme cómo funciona su aplicación con este cambio ejecutando puntos de referencia y monitoreando las métricas relacionadas con el rendimiento.
En algunos casos, la cantidad de datos temporales se ajusta al grupo de memoria `TempTable` o solo desborda el grupo de memoria en una pequeña cantidad. En estos casos, le recomendamos que utilice la configuración `TempTable` para tablas temporales internas y archivos asignados por memoria para contener los datos de desbordamiento. Esta configuración es la predeterminada.
El motor de almacenamiento `TempTable` es el predeterminado. `TempTable` utiliza un grupo de memoria común para todas las tablas temporales que utilizan este motor, en lugar de un límite máximo de memoria por tabla. El tamaño de este grupo de memoria se especifica mediante el parámetro [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram). El valor predeterminado es 1 GiB en instancias de base de datos con 16 GiB o más de memoria y 16 MB en instancias de base de datos con menos de 16 GiB de memoria. El tamaño del grupo de memoria influye en el consumo de memoria a nivel de sesión.
En algunos casos, al utilizar el motor de almacenamiento `TempTable`, los datos temporales pueden superar el tamaño del grupo de memoria. Si es así, Aurora MySQL almacena los datos de desbordamiento mediante un mecanismo secundario.
Puede establecer el parámetro [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) para especificar si los datos se desbordan a archivos temporales asignados a memoria o a tablas temporales internas de InnoDB en disco. Los distintos formatos de datos y criterios de desbordamiento de estos mecanismos de desbordamiento pueden afectar al rendimiento de las consultas. Lo hacen al influir en la cantidad de datos escritos en el disco y en la demanda de rendimiento del almacenamiento en disco.
La versión 3 de Aurora MySQL almacena los datos de desbordamiento de la siguiente manera:
+ En la instancia de base de datos de escritor, los datos que se desbordan en las tablas temporales internas de InnoDB o en los archivos temporales asignados a la memoria residen en el almacenamiento local de la instancia.
+ En las instancias de base de datos de lector, los datos de desbordamiento siempre residen en los archivos temporales asignados a la memoria del almacenamiento local.
Las instancias de solo lectura no pueden almacenar datos en el volumen del clúster de Aurora.
Los parámetros de configuración relacionados con las tablas temporales internas se aplican de forma diferente a las instancias de escritor y lector del clúster:
+ En instancias de lector, Aurora MySQL siempre utiliza el motor de almacenamiento `TempTable`.
+ El tamaño de `temptable_max_mmap` tiene un valor predeterminado de 1 GiB, tanto para las instancias de escritor como de lector, independientemente del tamaño de la memoria de la instancia de base de datos. Puede ajustar este valor tanto en instancias de escritor como de lector.
+ Al configurar `temptable_max_mmap` en `0`, se desactiva el uso de archivos temporales asignados a memoria en las instancias de escritor.
+ No puede establecer `temptable_max_mmap` en `0` en instancias de lector.
**nota**
No recomendamos utilizar el parámetro [temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap). Ha quedado obsoleto y se espera que se elimine en una futura versión de MySQL.
## Limitación del tamaño de las tablas temporales internas en memoria
Como se explica en [Motor de almacenamiento para tablas temporales internas (implícitas)](#ams3-temptable-behavior-engine), puede controlar los recursos de la tabla temporal a nivel global mediante las configuraciones [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) y [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap).
También puede limitar el tamaño de cualquier tabla temporal interna individual en memoria mediante el parámetro de base de datos [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size). Este límite tiene por objeto evitar que las consultas individuales consuman una cantidad desmesurada de recursos de las tablas temporales globales, lo que puede afectar al rendimiento de las consultas simultáneas que requieren estos recursos.
El parámetro `tmp_table_size` define el tamaño máximo de las tablas temporales creadas por el motor de almacenamiento `MEMORY` en la versión 3 y versiones posteriores de Aurora MySQL.
En la versión 3.04 y versiones posteriores de Aurora MySQL, `tmp_table_size` también define el tamaño máximo de las tablas temporales creadas por el motor de almacenamiento `TempTable` cuando el parámetro de base de datos `aurora_tmptable_enable_per_table_limit` está establecido en `ON`. Este comportamiento está deshabilitado de forma predeterminada (`OFF`), lo que es el mismo comportamiento que en la versión 3.03 y anteriores de Aurora MySQL.
+ Cuándo `aurora_tmptable_enable_per_table_limit` está establecido en `OFF`, `tmp_table_size` no se tiene en cuenta para las tablas temporales internas en memoria creadas por el motor de almacenamiento `TempTable`.
Sin embargo, se sigue aplicando el límite de recursos global de `TempTable`. Aurora MySQL tiene el siguiente comportamiento cuando se ha alcanzado el límite de recursos global de `TempTable`:
+ Instancias de base de datos del escritor: Aurora MySQL convierte automáticamente la tabla temporal en memoria en una tabla temporal en disco de InnoDB.
+ Instancias de base de datos del lector: la consulta finaliza con un error.
```
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full
```
+ Cuándo `aurora_tmptable_enable_per_table_limit` está establecido en `ON`, Aurora MySQL tiene el siguiente comportamiento cuando se alcanza el límite de `tmp_table_size`:
+ Instancias de base de datos del escritor: Aurora MySQL convierte automáticamente la tabla temporal en memoria en una tabla temporal en disco de InnoDB.
+ Instancias de base de datos del lector: la consulta finaliza con un error.
```
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full
```
En este caso se aplica tanto el límite de recursos global como el límite por tabla de `TempTable`.
**nota**
El parámetro `aurora_tmptable_enable_per_table_limit` no tiene ningún efecto cuando[ internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) está configurado en `MEMORY`. En este caso, el tamaño máximo de una tabla temporal en memoria se define mediante el valor [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) o [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size) , el que sea menor.
Los siguientes ejemplos muestran el comportamiento del parámetro `aurora_tmptable_enable_per_table_limit` para instancias de base de datos del escritor y lector.
**Example Ejemplo de una instancia de base de datos del escritor con `aurora_tmptable_enable_per_table_limit` establecido en `OFF`**
La tabla temporal en memoria no se convierte en una tabla temporal en disco de InnoDB.
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 0 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte;
+----------+
| max(n) |
+----------+
| 60000000 |
+----------+
1 row in set (13.99 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
```
**Example Ejemplo de una instancia de base de datos del escritor con `aurora_tmptable_enable_per_table_limit` establecido en `ON`**
La tabla temporal en memoria se convierte en una tabla temporal en disco de InnoDB.
```
mysql> set aurora_tmptable_enable_per_table_limit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size;
+--------------------+------------------+------------------------------------------+------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size |
+--------------------+------------------+------------------------------------------+------------------+
| 0 | 3.04.0 | 1 | 16777216 |
+--------------------+------------------+------------------------------------------+------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte;
+---------+
| max(n) |
+---------+
| 6000000 |
+---------+
1 row in set (4.10 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 1 |
+-------------------------+-------+
1 row in set (0.00 sec)
```
**Example Ejemplo de una instancia de base de datos del lector con `aurora_tmptable_enable_per_table_limit` establecido en `OFF`**
La consulta finaliza sin errores porque no se aplica `tmp_table_size`, y no se ha alcanzado el límite de recursos global de `TempTable`.
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 1 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte;
+----------+
| max(n) |
+----------+
| 60000000 |
+----------+
1 row in set (14.05 sec)
```
**Example Ejemplo de una instancia de base de datos del lector con `aurora_tmptable_enable_per_table_limit` establecido en `OFF`**
Esta consulta alcanza el límite global de recursos global de TempTable con `aurora_tmptable_enable_per_table_limit` configurado en OFF. La consulta finaliza con un error en las instancias del lector.
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 1 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.01 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte;
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full
```
**Example Ejemplo de una instancia de base de datos del lector con `aurora_tmptable_enable_per_table_limit` establecido en `ON`**
La consulta finaliza con un error cuando se ha alcanzado el límite de `tmp_table_size`.
```
mysql> set aurora_tmptable_enable_per_table_limit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size;
+--------------------+------------------+------------------------------------------+------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size |
+--------------------+------------------+------------------------------------------+------------------+
| 1 | 3.04.0 | 1 | 16777216 |
+--------------------+------------------+------------------------------------------+------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte;
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full
```
## Mitigación de los problemas de llenado de las tablas temporales internas en las réplicas de Aurora
Para evitar problemas de limitación del tamaño de las tablas temporales, establezca los parámetros `temptable_max_ram` y `temptable_max_mmap` a un valor combinado que pueda ajustarse a los requisitos de su carga de trabajo.
Tenga cuidado al establecer el valor del parámetro `temptable_max_ram`. Si se establece un valor demasiado alto, se reduce la memoria disponible en la instancia de base de datos, lo que puede provocar una situación de falta de memoria. Supervise el promedio de memoria que se puede liberar en la instancia de base de datos. A continuación, determine un valor adecuado para `temptable_max_ram`, de modo que le quede una cantidad razonable de memoria libre en la instancia. Para obtener más información, consulte [Problemas de memoria que se puede liberar en Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory).
También es importante supervisar el tamaño del almacenamiento local y el consumo de espacio de las tablas temporales. Puede supervisar el almacenamiento temporal disponible para una instancia de base de datos con la métrica `FreeLocalStorage` de Amazon CloudWatch, que se describe en [Métricas de Amazon CloudWatch para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md).
**nota**
Este procedimiento no funciona cuando el parámetro `aurora_tmptable_enable_per_table_limit` está establecido en `ON`. Para obtener más información, consulte [Limitación del tamaño de las tablas temporales internas en memoria](#ams3-temptable-behavior-limit).
**Example 1**
Sabe que sus tablas temporales crecen hasta un tamaño acumulado de 20 GiB. Desea establecer las tablas temporales en memoria a 2 GiB y que crezcan hasta un máximo de 20 GiB en disco.
Establezca `temptable_max_ram` en **2,147,483,648** y `temptable_max_mmap` en **21,474,836,480**. Estos valores están expresados en bytes.
Esta configuración de parámetros garantiza que las tablas temporales puedan crecer hasta alcanzar un total acumulado de 22 GiB.
**Example 2**
El tamaño de su instancia actual es 16xlarge o superior. No sabe el tamaño total de las tablas temporales que podría necesitar. Desea poder utilizar hasta 4 GiB en la memoria y hasta el tamaño máximo de almacenamiento disponible en el disco.
Establezca `temptable_max_ram` en **4,294,967,296** y `temptable_max_mmap` en **1,099,511,627,776**. Estos valores están expresados en bytes.
Aquí se establece `temptable_max_mmap` a 1 TiB, que es menos que el almacenamiento local máximo de 1,2 TiB en una instancia de base de datos 16xlarge de Aurora.
En una instancia de menor tamaño, ajuste el valor de `temptable_max_mmap` para que no llene el almacenamiento local disponible. Por ejemplo, una instancia 2xlarge solo dispone de 160 GiB de almacenamiento local. Por lo tanto, recomendamos establecer el valor a menos de 160 GiB. Para obtener más información sobre el almacenamiento local disponible para los tamaños de instancia de base de datos, consulte [Límites de almacenamiento temporal de Aurora MySQLLímites de almacenamiento temporal](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage).
## Optimización del parámetro temptable\$1max\$1mmap en instancias de base de datos de Aurora MySQL
El parámetro `temptable_max_mmap` de Aurora MySQL controla la cantidad máxima de espacio en disco local que pueden utilizar los archivos asignados por memoria antes de desbordarse en las tablas temporales de InnoDB en el disco (en las instancias de base de datos de escritor) o provocar un error (en las instancias de base de datos de lector). Establecer este parámetro de instancia de base de datos correctamente puede ayudar a optimizar el rendimiento de las instancias de base de datos.
**Requisitos previos**
1. Asegúrese de que el esquema de rendimiento esté habilitado. Para verificarlo, ejecute el siguiente comando SQL:
```
SELECT @@performance_schema;
```
Un valor de salida de `1` indica que está activado.
1. Confirme que la instrumentación de la memoria de tabla temporal esté habilitada. Para verificarlo, ejecute el siguiente comando SQL:
```
SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%';
```
La columna `enabled` muestra `YES` para las entradas de instrumentación de memoria de la tabla temporal pertinentes.
**Supervisión del uso de las tablas temporales**
Al establecer el valor inicial para `temptable_max_mmap`, le recomendamos que comience con el 80 % del tamaño de almacenamiento local de la clase de instancia de base de datos que esté utilizando. Esto garantiza que las tablas temporales tengan suficiente espacio en disco para funcionar de manera eficiente y, al mismo tiempo, dejar espacio para otros usos del disco en la instancia.
Para encontrar el tamaño de almacenamiento local de la clase de instancia de base de datos, consulte [Límites de almacenamiento temporal de Aurora MySQLLímites de almacenamiento temporal](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage).
Por ejemplo, si utiliza la clase de instancia de base de datos db.r5.large, el tamaño del almacenamiento local será de 32 GiB. En este caso, establecería inicialmente el parámetro `temptable_max_mmap` en un 80 % de 32 GiB, lo que equivale a 25,6 GiB.
Tras establecer el valor inicial de `temptable_max_mmap`, ejecute la carga de trabajo máxima en las instancias de Aurora MySQL. Supervise el uso actual y elevado del disco de la tabla temporal mediante la siguiente consulta SQL:
```
SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc
FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%';
```
Esta consulta recupera la siguiente información:
+ `event_name`: el nombre del evento de uso de disco o de memoria de la tabla temporal.
+ `current_count`: el número actual de bloques de disco o de memoria de tabla temporal asignados.
+ `current_alloc`: la cantidad actual de memoria o disco asignada a las tablas temporales.
+ `current_avg_alloc`: el tamaño medio actual de bloques de disco o de memoria de tabla temporal.
+ `high_count`: el número más alto de bloques de disco o de memoria de tabla temporal asignados.
+ `high_alloc`: la cantidad mayor de memoria o disco asignada a las tablas temporales.
+ `high_avg_alloc`: el tamaño medio más alto de bloques de disco o de memoria de tabla temporal.
Si las consultas producen el error La tabla está llena al utilizar esta configuración, esto indica que la carga de trabajo requiere más espacio en disco para las operaciones temporales de la tabla. En este caso, considere la posibilidad de aumentar el tamaño de la instancia de base de datos a una con más espacio de almacenamiento local.
**Establecimiento del valor `temptable_max_mmap` óptimo**
Utilice el siguiente procedimiento para supervisar y establecer el tamaño correcto para el parámetro `temptable_max_mmap`.
1. Revise el resultado de la consulta anterior e identifique el pico de uso temporal del disco de la tabla, como se indica en la columna `high_alloc`.
1. En función del uso máximo temporal del disco de la tabla, ajuste el parámetro `temptable_max_mmap` en el grupo de parámetros de base de datos para las instancias de base de datos de Aurora MySQL.
Establezca el valor para que sea ligeramente superior al máximo de uso temporal del disco de la tabla para adaptarse al crecimiento futuro.
1. Aplique los cambios del grupo de parámetros a las instancias de base de datos.
1. Vuelva a supervisar el uso del disco de tabla temporal durante los picos de carga de trabajo para asegurarse de que el nuevo valor de `temptable_max_mmap` es el adecuado.
1. Repita los pasos anteriores según sea necesario para afinar el parámetro `temptable_max_mmap`.
## Tablas temporales creadas por el usuario (explícitas) en las instancias de base de datos del lector
Puede crear tablas temporales explícitas mediante la palabra clave `TEMPORARY` en la instrucción `CREATE TABLE`. Las tablas temporales explícitas se admiten en la instancia de base de datos del escritor en un clúster de base de datos de Aurora. También puede utilizar tablas temporales explícitas en instancias de base de datos del lector, pero las tablas no pueden imponer el uso del motor de almacenamiento InnoDB.
Para evitar errores al crear tablas temporales explícitas en las instancias de la base de datos de escritor de Aurora MySQL, asegúrese de que ejecuta todas las instrucciones `CREATE TEMPORARY TABLE` de una o ambas de las siguientes maneras:
+ No especifique la cláusula `ENGINE=InnoDB`.
+ No establezca el modo SQL en `NO_ENGINE_SUBSTITUTION`.
## Errores de creación de tablas temporales y su mitigación
El error que recibe difiere en función de si utiliza una simple instrucción `CREATE TEMPORARY TABLE` o variante `CREATE TEMPORARY TABLE AS SELECT`. Los siguientes ejemplos muestran los diferentes tipos de errores.
Este comportamiento de tabla temporal solo se aplica a instancias de solo lectura. Este primer ejemplo confirma que ese es el tipo de instancia a la que está conectada la sesión.
```
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
| 1 |
+--------------------+
```
Para instrucciones `CREATE TEMPORARY TABLE` simples, la instrucción falla cuando el modo SQL `NO_ENGINE_SUBSTITUTION` está activado. Cuando `NO_ENGINE_SUBSTITUTION` está desactivado (de forma predeterminada), se realiza la sustitución del motor adecuado y la creación de la tabla temporal se lleva a cabo correctamente.
```
mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION';
mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB;
ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed).
mysql> SET sql_mode = '';
mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB;
mysql> SHOW CREATE TABLE tt4\G
*************************** 1. row ***************************
Table: tt4
Create Table: CREATE TEMPORARY TABLE `tt4` (
`id` int DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
```
Para instrucciones `CREATE TEMPORARY TABLE AS SELECT`, la instrucción falla cuando el modo SQL `NO_ENGINE_SUBSTITUTION` está activado. Cuando `NO_ENGINE_SUBSTITUTION` está desactivado (de forma predeterminada), se realiza la sustitución del motor adecuado y la creación de la tabla temporal se lleva a cabo correctamente.
```
mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION';
mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1;
ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed).
mysql> SET sql_mode = '';
mysql> show create table tt3;
+-------+----------------------------------------------------------+
| Table | Create Table |
+-------+----------------------------------------------------------+
| tt3 | CREATE TEMPORARY TABLE `tt3` (
`id` int DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |
+-------+----------------------------------------------------------+
1 row in set (0.00 sec)
```
Para obtener más información sobre los aspectos de almacenamiento y las implicaciones de rendimiento de las tablas temporales en Aurora MySQL versión 3, consulte la entrada del blog [Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
# 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.
# Comparación de Aurora MySQL versión 3 y MySQL 8.0 Community Edition
Puede utilizar la siguiente información para obtener información sobre los cambios que debe tener en cuenta al convertir de otro sistema compatible con MySQL 8.0 a Aurora MySQL versión 3.
En general, Aurora MySQL versión 3 admite el conjunto de características de la comunidad MySQL 8.0.23. Algunas características nuevas de la edición de la comunidad MySQL 8.0 no se aplican a Aurora MySQL. Algunas de esas funciones no son compatibles con algún aspecto de Aurora, como la arquitectura de almacenamiento Aurora. No se necesitan otras funciones porque el servicio de administración de Amazon RDS proporciona una funcionalidad equivalente. Las siguientes características de la comunidad MySQL 8.0 no son compatibles o funcionan de forma diferente en Aurora MySQL versión 3.
Para ver las notas de todas las versiones de Aurora MySQL versión 3, consulte el tema sobre [actualizaciones del motor de base de datos de Amazon Aurora MySQL versión 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) en las *notas de la versión de Aurora MySQL*.
**Topics**
+ [Las funciones de MySQL 8.0 no están disponibles en Aurora MySQL versión 3](#AuroraMySQL.Compare-80-v3-features)
+ [Modelo de privilegios basado en roles](#AuroraMySQL.privilege-model)
+ [Búsqueda del ID de servidor de base de datos](#AuroraMySQL.server-id)
+ [Autenticación](#AuroraMySQL.mysql80-authentication)
## Las funciones de MySQL 8.0 no están disponibles en Aurora MySQL versión 3
Las siguientes características de la comunidad MySQL 8.0 no son compatibles o funcionan de forma diferente en Aurora MySQL versión 3.
+ Los grupos de recursos y las instrucciones SQL asociadas no son compatibles con Aurora MySQL.
+ Aurora MySQL no admite los espacios de tabla de deshacer definidos por el usuario ni las instrucciones SQL asociadas, como `CREATE UNDO TABLESPACE`, `ALTER UNDO TABLESPACE ... SET INACTIVE` y `DROP UNDO TABLESPACE`.
+ Aurora MySQL no admite deshacer el truncado de espacios de tablas de deshacer en las versiones de Aurora MySQL anteriores a la 3.06. En la versión 3.06 y posteriores de Aurora MySQL, se admite el [truncado automático de espacios de tablas de deshacer](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace).
+ Se admite el complemento de validación de contraseñas.
+ No puede modificar la configuración de ningún complemento de MySQL, incluido el complemento de validación de contraseñas.
+ El complemento X no es compatible.
+ No se admite la replicación automática.
## Modelo de privilegios basado en roles
Con Aurora MySQL versión 3, no se pueden modificar las tablas de base de datos de `mysql` directamente. En particular, no se pueden configurar usuarios insertándolos en la tabla de `mysql.user`. En su lugar, se utilizan sentencias SQL para otorgar privilegios basados en roles. Tampoco puede crear otros tipos de objetos, como procedimientos almacenados en la base de datos `mysql`. Aún puede consultar las tablas de `mysql`. Si utiliza la replicación de registros binarios, los cambios realizados directamente en la tabla de `mysql` del clúster de origen no se replican en el clúster destino.
En algunos casos, la aplicación puede utilizar accesos directos para crear usuarios u otros objetos insertándolos en las tablas de `mysql`. Si es así, cambie el código de la aplicación para utilizar las declaraciones correspondientes, como `CREATE USER`. Si la aplicación crea procedimientos almacenados u otros objetos en la base de datos `mysql`, utilice otra base de datos en su lugar.
Para exportar metadatos para usuarios de bases de datos durante la migración desde una base de datos MySQL externa, puede utilizar el comando del intérprete de comandos de MySQL en lugar de `mysqldump`. Para obtener más información, consulte [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about).
Para simplificar la administración de permisos para muchos usuarios o aplicaciones, puede utilizar la instrucción `CREATE ROLE` para crear un rol que tenga un conjunto de permisos. A continuación, puede utilizar las instrucciones `GRANT` y `SET ROLE` y la función `current_role` para asignar roles a usuarios o aplicaciones, cambiar el rol actual y verificar qué roles están en vigor. Para obtener más información sobre el sistema de permisos basado en roles de MySQL 8.0, consulte [Uso de roles](https://dev.mysql.com/doc/refman/8.0/en/roles.html) en el Manual de referencia de MySQL.
**importante**
Le recomendamos encarecidamente que no utilice el usuario maestro directamente en sus aplicaciones. En lugar de ello, es mejor ceñirse a la práctica recomendada de utilizar un usuario de base de datos creado con los privilegios mínimos necesarios para su aplicación.
**Topics**
+ [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role)
+ [Usuario de comprobaciones de privilegios para replicación de registros binarios](#AuroraMySQL.privilege-model.binlog)
+ [Roles para acceder a otros servicios de AWS](#AuroraMySQL.privilege-model.other)
### rds\$1superuser\$1role
Aurora MySQL versión 3 incluye un rol especial que tiene todos los siguientes privilegios. El rol se denomina `rds_superuser_role`. El usuario administrativo principal de cada clúster ya tiene asignada este rol. El rol `rds_superuser_role` incluye los siguientes privilegios para todos los objetos de base de datos:
+ `ALTER`
+ `APPLICATION_PASSWORD_ADMIN`
+ `ALTER ROUTINE`
+ `CONNECTION_ADMIN`
+ `CREATE`
+ `CREATE ROLE`
+ `CREATE ROUTINE`
+ `CREATE TEMPORARY TABLES`
+ `CREATE USER`
+ `CREATE VIEW`
+ `DELETE`
+ `DROP`
+ `DROP ROLE`
+ `EVENT`
+ `EXECUTE`
+ `FLUSH_OPTIMIZER_COSTS` (versión 3.09 y posteriores de Aurora MySQL)
+ `FLUSH_STATUS` (versión 3.09 y posteriores de Aurora MySQL)
+ `FLUSH_TABLES` (versión 3.09 y posteriores de Aurora MySQL)
+ `FLUSH_USER_RESOURCES` (versión 3.09 y posteriores de Aurora MySQL)
+ `INDEX`
+ `INSERT`
+ `LOCK TABLES`
+ `PROCESS`
+ `REFERENCES`
+ `RELOAD`
+ `REPLICATION CLIENT`
+ `REPLICATION SLAVE`
+ `ROLE_ADMIN`
+ `SET_USER_ID`
+ `SELECT`
+ `SHOW DATABASES`
+ `SHOW_ROUTINE` (versión 3.04 y posteriores de Aurora MySQL)
+ `SHOW VIEW`
+ `TRIGGER`
+ `UPDATE`
+ `XA_RECOVER_ADMIN`
La definición de rol también incluye `WITH GRANT OPTION` para que un usuario administrativo pueda conceder ese rol a otros usuarios. En particular, el administrador debe conceder los privilegios necesarios para realizar la replicación de registros binarios con el clúster Aurora MySQL como destino.
**sugerencia**
Para ver todos los detalles de los permisos, ingrese las siguientes instrucciones.
```
SHOW GRANTS FOR rds_superuser_role@'%';
SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%';
```
### Usuario de comprobaciones de privilegios para replicación de registros binarios
La versión 3 de Aurora MySQL incluye un usuario de comprobaciones de privilegios para la replicación de registros binarios (binlog), `rdsrepladmin_priv_checks_user`. Además de los privilegios de `rds_superuser_role`, este usuario tiene el privilegio `replication_applier`.
Cuando se activa la replicación de binlog mediante una llamada al procedimiento almacenado `mysql.rds_start_replication`, se crea `rdsrepladmin_priv_checks_user`.
El usuario `rdsrepladmin_priv_checks_user@localhost` es un usuario reservado. No lo modifique.
### Roles para acceder a otros servicios de AWS
Aurora MySQL versión 3 también incluye roles que puede utilizar para acceder a otros servicios de AWS. Puede establecer muchos de estos roles como alternativa a la concesión de privilegios. Por ejemplo, especifica `GRANT AWS_LAMBDA_ACCESS TO user` en lugar de `GRANT INVOKE LAMBDA ON *.* TO user`. Para ver los procedimientos de acceso a otros servicios de AWS, consulte [Integración de Amazon Aurora MySQL con otros servicios de AWS](AuroraMySQL.Integrating.md). Aurora MySQL versión 3 incluye los siguientes roles relacionados con el acceso a otros servicios de:AWS
+ `AWS_LAMBDA_ACCESS`: una alternativa al privilegio `INVOKE LAMBDA`. Para obtener más información, consulte [Invocación de una función de Lambda desde un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md).
+ `AWS_LOAD_S3_ACCESS`: una alternativa al privilegio `LOAD FROM S3`. Para obtener más información, consulte [Carga de datos en un clúster de base de datos Amazon Aurora MySQL desde archivos de texto en un bucket de Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md).
+ `AWS_SELECT_S3_ACCESS`: una alternativa al privilegio `SELECT INTO S3`. Para obtener más información, consulte [Grabación de datos desde un clúster de base de datos Amazon Aurora MySQL en archivos de texto de un bucket de Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md).
+ `AWS_COMPREHEND_ACCESS`: una alternativa al privilegio `INVOKE COMPREHEND`. Para obtener más información, consulte [Concesión de acceso a los usuarios de bases de datos a machine learning de Aurora](mysql-ml.md#aurora-ml-sql-privileges).
+ `AWS_SAGEMAKER_ACCESS`: una alternativa al privilegio `INVOKE SAGEMAKER`. Para obtener más información, consulte [Concesión de acceso a los usuarios de bases de datos a machine learning de Aurora](mysql-ml.md#aurora-ml-sql-privileges).
+ `AWS_BEDROCK_ACCESS`: no hay un privilegio análogo a `INVOKE` para Amazon Bedrock. Para obtener más información, consulte [Concesión de acceso a los usuarios de bases de datos a machine learning de Aurora](mysql-ml.md#aurora-ml-sql-privileges).
Cuando concede acceso mediante roles en Aurora MySQL versión 3, también activa el rol mediante la instrucción `SET ROLE role_name` o `SET ROLE ALL`. El siguiente ejemplo muestra cómo. Sustituya el nombre de rol apropiado por `AWS_SELECT_S3_ACCESS`.
```
# Grant role to user.
mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address'
# Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated.
# Only the rds_superuser_role is currently in effect.
mysql> SELECT CURRENT_ROLE();
+--------------------------+
| CURRENT_ROLE() |
+--------------------------+
| `rds_superuser_role`@`%` |
+--------------------------+
1 row in set (0.00 sec)
# Activate all roles associated with this user using SET ROLE.
# You can activate specific roles or all roles.
# In this case, the user only has 2 roles, so we specify ALL.
mysql> SET ROLE ALL;
Query OK, 0 rows affected (0.00 sec)
# Verify role is now active
mysql> SELECT CURRENT_ROLE();
+-----------------------------------------------------+
| CURRENT_ROLE() |
+-----------------------------------------------------+
| `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` |
+-----------------------------------------------------+
```
## Búsqueda del ID de servidor de base de datos
El ID de servidor de base de datos (`server_id`) es necesario para la replicación de registro binario (binlog). La búsqueda del ID del servidor en Aurora MySQL se realiza de forma diferente que en Community MySQL.
En Community MySQL, el ID del servidor es un número que se obtiene mediante la siguiente sintaxis al registrarse en el servidor:
```
mysql> select @@server_id;
+-------------+
| @@server_id |
+-------------+
| 2 |
+-------------+
1 row in set (0.00 sec)
```
En Aurora MySQL, el ID del servidor es el ID de la instancia de base de datos, que se obtiene mediante la siguiente sintaxis al registrarse en la instancia de base de datos:
```
mysql> select @@aurora_server_id;
+------------------------+
| @@aurora_server_id |
+------------------------+
| mydbcluster-instance-2 |
+------------------------+
1 row in set (0.00 sec)
```
Para obtener más información sobre la replicación binlog, 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).
## Autenticación
En la comunidad MySQL 8.0, el complemento de autenticación predeterminado es `caching_sha2_password`. Aurora MySQL versión 3 sigue utilizando el complemento `mysql_native_password`. No se puede cambiar la configuración de `default_authentication_plugin`. Sin embargo, puede crear nuevos usuarios y modificar los usuarios actuales, y las contraseñas individuales utilizarán el nuevo complemento de autenticación. A continuación se muestra un ejemplo.
```
mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword';
Query OK, 0 rows affected (0.74 sec)
```
# Actualización a Aurora MySQL versión 3
Para obtener información sobre cómo actualizar su base de datos de la versión 2 a la versión 3 de Aurora MySQL, consulte [Actualización de la versión principal de un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md).
# Aurora MySQL versión 2 compatible con MySQL 5.7
En este tema, se describen las diferencias entre la versión 2 de Aurora MySQL y MySQL 5.7 Community Edition.
**importante**
La versión 2 de Aurora MySQL ya no recibe soporte estándar desde el 31 de octubre de 2024. Para obtener más información, consulte [Preparación para el final del soporte estándar de la versión 2 de Amazon Aurora MySQL-Compatible Edition](Aurora.MySQL57.EOL.md).
## Características no compatibles con Aurora MySQL versión 2
Las siguientes características se admiten en MySQL 5.7, pero no se admiten actualmente en Aurora MySQL versión 2:
+ `CREATE TABLESPACE` Instrucción SQL
+ Complemento de replicación de grupo
+ Tamaño de página incrementado
+ Carga de grupo de búfer de InnoDB al inicio
+ Complemento de analizador de texto completo de InnoDB
+ Replicación de varios orígenes
+ Cambio de tamaño de grupo de búfer online
+ Complemento de validación de contraseñas: puede instalar el complemento, pero no es compatible. No se puede personalizar el complemento.
+ Complementos de reescritura de consulta
+ Filtrado de replicación
+ Protocolo X
Para obtener más información sobre estas características, consulte la [documentación de MySQL 5.7](https://dev.mysql.com/doc/refman/5.7/en/).
## Comportamiento de los espacios de tabla temporales en Aurora MySQL versión 2
En MySQL 5.7, el espacio de tablas temporal se amplía automáticamente y aumenta de tamaño según sea necesario para dar cabida a las tablas temporales en el disco. Cuando se eliminan tablas temporales, el espacio libre se puede reutilizar para nuevas tablas temporales, pero el espacio de tablas temporal sigue teniendo el tamaño ampliado y no se reduce. El espacio de tablas temporal se elimina y se vuelve a crear cuando se reinicia el motor.
En Aurora MySQL versión 2, se aplica el siguiente comportamiento:
+ En el caso de nuevos clústeres de base de datos de Aurora MySQL creados con la versión 2.10 o posteriores, el espacio de tablas temporal se elimina y se vuelve a crear al reiniciar la base de datos. Esto permite que la función de cambio de tamaño dinámico recupere el espacio de almacenamiento.
+ Para clústeres de base de datos de Aurora MySQL existentes actualizados a las siguientes versiones:
+ Versión 2.10 o posteriores: el espacio de tablas temporal se elimina y se vuelve a crear al reiniciar la base de datos. Esto permite que la función de cambio de tamaño dinámico recupere el espacio de almacenamiento.
+ Versión 2.09: el espacio de tablas temporal no se elimina al reiniciar la base de datos.
Puede comprobar el tamaño del espacio de tablas temporal de su clúster de base de datos de Aurora MySQL versión 2 mediante la siguiente consulta:
```
SELECT
FILE_NAME,
TABLESPACE_NAME,
ROUND((TOTAL_EXTENTS * EXTENT_SIZE) / 1024 / 1024 / 1024, 4) AS SIZE
FROM
INFORMATION_SCHEMA.FILES
WHERE
TABLESPACE_NAME = 'innodb_temporary';
```
Para obtener más información, consulte [The Temporary Tablespace](https://dev.mysql.com/doc/refman/5.7/en/innodb-temporary-tablespace.html) (El espacio de tablas temporal) en la documentación de MySQL.
## Motor de almacenamiento para tablas temporales en disco
La versión 2 de Aurora MySQL usa diferentes motores de almacenamiento para las tablas temporales internas en disco, según el rol de la instancia.
+ En la instancia de escritor, las tablas temporales en disco utilizan el motor de almacenamiento InnoDB de forma predeterminada. Están almacenadas en el espacio de tablas temporal del volumen del clúster de Aurora.
Puede cambiar este comportamiento en la instancia de escritor modificando el valor del parámetro de base de datos `internal_tmp_disk_storage_engine`. Para obtener más información, consulte [Parámetros de nivel de instancia](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance).
+ En las instancias de lector, las tablas temporales en disco utilizan el motor de almacenamiento MyISAM, que utiliza el almacenamiento local. Esto se debe a que las instancias de solo lectura no pueden almacenar datos en el volumen del clúster de Aurora.