# Referencia de Amazon Aurora MySQL
Esta referencia incluye información sobre parámetros de Aurora MySQL, variables de estado y extensiones SQL generales o diferencias con el motor de base de datos MySQL de la comunidad.
**Topics**
+ [Parámetros de configuración de Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md)
+ [Variables de estado globales de Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md)
+ [Eventos de espera de Aurora MySQL](AuroraMySQL.Reference.Waitevents.md)
+ [Estados del subproceso Aurora MySQL](AuroraMySQL.Reference.thread-states.md)
+ [Niveles de aislamiento de Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md)
+ [Sugerencias de Aurora MySQL](AuroraMySQL.Reference.Hints.md)
+ [Referencia de procedimientos almacenados en Aurora MySQL](AuroraMySQL.Reference.StoredProcs.md)
+ [Aurora MySQL: tablas de information\$1schema específica](AuroraMySQL.Reference.ISTables.md)
# Parámetros de configuración de Aurora MySQL
El clúster de bases de datos Amazon Aurora MySQL se administra de la misma forma que otras instancias de base de datos de Amazon RDS: con los parámetros de un grupo de parámetros de base de datos. Amazon Aurora difiere de otros motores de base de datos en los que hay un clúster de bases de datos que contiene varias instancias de base de datos. Como resultado, algunos de los parámetros que utiliza para administrar su clúster de bases de datos de Aurora MySQL se aplican a todo el clúster. Los demás parámetros se aplican solo a una instancia de base de datos determinada en el clúster de bases de datos.
Utilice grupos de parámetros de clúster de bases de datos para administrar los parámetros de nivel de clúster. Utilice grupos de parámetros de base de datos para administrar los parámetros de nivel de instancia. Todas las instancias de base de datos en un clúster de bases de datos de Aurora MySQL son compatibles con el motor de base de datos de MySQL. Sin embargo, aplique algunos de los parámetros del motor de base de datos MySQL en el nivel de clúster y administre estos parámetros mediante los grupos de parámetros de clúster de bases de datos. No puede detectar los parámetros de nivel del clúster en el grupo de parámetros de base de datos para una instancia en un clúster de bases de datos de Aurora. Después aparecerá una lista de parámetros de nivel de clúster en este tema.
Puede administrar tanto los parámetros de nivel de clúster como los de nivel de instancia con la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS. Utilice comandos independientes para administrar los parámetros de nivel de clúster y los parámetros de nivel de instancia. Por ejemplo, puede utilizar el comando de la CLI [modify-db-clúster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) para administrar parámetros de nivel de clúster en un grupo de parámetros del clúster de bases de datos. Puede utilizar el comando de la CLI [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para administrar parámetros de nivel de instancia en un grupo de parámetros de base de datos para una instancia de base de datos en un clúster de bases de datos.
Puede ver tanto los parámetros de nivel de clúster como los de nivel de instancia en la consola o usando la CLI o la API de RDS. Por ejemplo, puede utilizar el comando de la AWS CLI [describe-db-clúster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) para ver parámetros de nivel de clúster en un grupo de parámetros del clúster de bases de datos. Puede utilizar el comando de la CLI [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) para ver parámetros de nivel de instancia en un grupo de parámetros de base de datos para una instancia de base de datos en un clúster de bases de datos.
**nota**
Cada [grupo de parámetros predeterminados](USER_WorkingWithParamGroups.md) contiene los valores predeterminados para todos los parámetros del grupo de parámetros. Si el parámetro tiene “engine default” para este valor, consulte la documentación de MySQL o PostgreSQL específica de la versión para obtener el valor predeterminado real.
A menos que se indique lo contrario, los parámetros que figuran en las siguientes tablas son válidos para las versiones 2 y 3 de Aurora MySQL.
Para obtener más información acerca de los grupos de parámetros de base de datos, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Para conocer las reglas y restricciones para clústeres Aurora Serverless v1, consulte [Grupos de parámetros de Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups).
**Topics**
+ [Parámetros de nivel de clúster](#AuroraMySQL.Reference.Parameters.Cluster)
+ [Parámetros de nivel de instancia](#AuroraMySQL.Reference.Parameters.Instance)
+ [Parámetros de MySQL que no se aplican a Aurora MySQL](#AuroraMySQL.Reference.Parameters.Inapplicable)
## Parámetros de nivel de clúster
En la siguiente tabla se muestran todos los parámetros que afectan a todo el clúster de bases de datos Aurora MySQL.
| Nombre del parámetro | Modificable | Notas |
| --- | --- | --- |
| `aurora_binlog_read_buffer_size` | Sí | Solo afecta a los clústeres que utilizan replicación de registro binario (binlog). Para obtener información acerca de la replicación de 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). Eliminado de Aurora MySQL versión 3. |
| `aurora_binlog_replication_max_yield_seconds` | Sí | Solo afecta a los clústeres que utilizan replicación de registro binario (binlog). Para obtener información acerca de la replicación de 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). |
| `aurora_binlog_replication_sec_index_parallel_workers` | Sí | Establece el número total de subprocesos paralelos disponibles para aplicar cambios de índice secundarios al replicar transacciones para tablas grandes con más de un índice secundario. El parámetro está establecido en `0` (deshabilitado) de forma predeterminada. Este parámetro está disponible en la versión 3.06 y versiones posteriores de Aurora MySQL. Para obtener más información, consulte [Optimización de la replicación de registros binarios para Aurora MySQL](binlog-optimization.md). |
| `aurora_binlog_use_large_read_buffer` | Sí | Solo afecta a los clústeres que utilizan replicación de registro binario (binlog). Para obtener información acerca de la replicación de 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). Eliminado de Aurora MySQL versión 3. |
| `aurora_disable_hash_join` | Sí | Establezca este valor en `ON` para desactivar la optimización de las combinaciones hash en Aurora MySQL versión 2.09 o posteriores. No se admite en la versión 3. Para obtener más información, consulte [Consulta paralela para Amazon Aurora MySQL](aurora-mysql-parallel-query.md). |
| `aurora_enable_replica_log_compression` | Sí | Para obtener más información, consulte [Consideraciones sobre el rendimiento de la replicación de Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). No aplica cambios a clústeres que formen parte de una base de datos global de Aurora. Eliminado de Aurora MySQL versión 3. |
| `aurora_enable_repl_bin_log_filtering` | Sí | Para obtener más información, consulte [Consideraciones sobre el rendimiento de la replicación de Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). No aplica cambios a clústeres que formen parte de una base de datos global de Aurora. Eliminado de Aurora MySQL versión 3. |
| `aurora_enable_staggered_replica_restart` | Sí | Esta configuración está disponible en la versión 3 de Aurora MySQL, pero no se usa. |
| `aurora_enable_zdr` | Sí | Esta configuración se activa de forma predeterminada en Aurora MySQL 2.10 y posteriores. Para obtener más información, consulte [Reinicio sin tiempo de inactividad (ZDR) para Amazon Aurora MySQL](AuroraMySQL.Replication.Availability.md). |
| `aurora_enhanced_binlog` | Sí | Establezca el valor de este parámetro en 1 para activar el binlog mejorado en Aurora MySQL versión 3.03.1 y posteriores. Para obtener más información, consulte [Configuración del binlog mejorado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `aurora_jemalloc_background_thread` | Sí | Utilice este parámetro para permitir que un subproceso en segundo plano realice operaciones de mantenimiento de memoria. Los valores permitidos son `0` (deshabilitado) y `1` (habilitado). El valor predeterminado es `0`. Este parámetro se aplica a la versión 3.04 y versiones posteriores de Aurora MySQL. |
| `aurora_jemalloc_dirty_decay_ms` | Sí | Utilice este parámetro para retener la memoria liberada durante un tiempo determinado (en milisegundos). La retención de la memoria permite una reutilización más rápida. Los valores permitidos son: El valor predeterminado (`0`) devuelve toda la memoria al sistema operativo como memoria liberable. Este parámetro se aplica a la versión 3.04 y versiones posteriores de Aurora MySQL. |
| `aurora_jemalloc_tcache_enabled` | Sí | Utilice este parámetro para atender solicitudes de memoria pequeñas (hasta 32 KiB) en una caché local de subprocesos, evitando los ámbitos de memoria. Los valores permitidos son `0` (deshabilitado) y `1` (habilitado). El valor predeterminado es `1`. Este parámetro se aplica a la versión 3.04 y versiones posteriores de Aurora MySQL. |
| `aurora_load_from_s3_role` | Sí | 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). Actualmente no está disponible en Aurora MySQL versión 3. Utilice `aws_default_s3_role`. |
| `aurora_mask_password_hashes_type` | Sí | Esta configuración se activa de forma predeterminada en Aurora MySQL 2.11 y posteriores. Utilice esta configuración para ocultar los hash de contraseñas de Aurora MySQL en las consultas lentas y los registros de de auditoría. Los valores permitidos son `0` y `1` (predeterminado). Cuando se establece en `1`, las contraseñas se registran como ``. Cuando se establece en `0`, las contraseñas se registran como valores hash (`#`). |
| `aurora_select_into_s3_role` | Sí | 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). Actualmente no está disponible en Aurora MySQL versión 3. Utilice `aws_default_s3_role`. |
| `authentication_kerberos_caseins_cmp` | Sí | Controla la comparación de nombres de usuario del complemento de `authentication_kerberos` que no distingue mayúsculas de minúsculas. Configúrelo en `true` para que la comparación no distinga entre mayúsculas y minúsculas. De forma predeterminada, se utiliza la comparación entre mayúsculas y minúsculas (`false`). Para obtener más información, consulte [Uso de la autenticación Kerberos para Aurora MySQL](aurora-mysql-kerberos.md). Este parámetro está disponible en Aurora MySQL versión 3.03 y posterior. |
| `auto_increment_increment` | Sí | |
| `auto_increment_offset` | Sí | |
| `aws_default_lambda_role` | Sí | 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_default_s3_role` | Sí | Se utiliza al invocar la instrucción `LOAD DATA FROM S3`, `LOAD XML FROM S3` o `SELECT INTO OUTFILE S3` desde el clúster de base de datos. En la versión 2 de Aurora MySQL, el rol de IAM especificado en este parámetro se usa cuando no se especifica un rol de IAM para `aurora_load_from_s3_role` o `aurora_select_into_s3_role` en la instrucción correspondiente. En la versión 3 de Aurora MySQL, siempre se utiliza el rol de IAM especificado para este parámetro. Para obtener más información, consulte [Asociación de un rol de IAM con un clúster de base de datos Amazon Aurora MySQL](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md). |
| `binlog_backup` | Sí | Establezca el valor de este parámetro en 0 para activar el binlog mejorado en Aurora MySQL versión 3.03.1 y posteriores. Puede desactivar este parámetro solo si usa el binlog mejorado. Para obtener más información, consulte [Configuración del binlog mejorado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `binlog_checksum` | Sí | La API AWS CLI y RDS informa un valor de `None` si este parámetro no está establecido. En ese caso, Aurora MySQL utiliza el valor predeterminado del motor, que es `CRC32`. Esto es diferente de la configuración explícita de `NONE`, que desactiva la suma de comprobación. |
| `binlog-do-db` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog_format` | Sí | Para obtener más información, 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). |
| `binlog_group_commit_sync_delay` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog_group_commit_sync_no_delay_count` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog-ignore-db` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog_replication_globaldb` | Sí | Establezca el valor de este parámetro en 0 para activar el binlog mejorado en Aurora MySQL versión 3.03.1 y posteriores. Puede desactivar este parámetro solo si usa el binlog mejorado. Para obtener más información, consulte [Configuración del binlog mejorado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `binlog_row_image` | No | |
| `binlog_row_metadata` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog_row_value_options` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog_rows_query_log_events` | Sí | |
| `binlog_transaction_compression` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog_transaction_compression_level_zstd` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog_transaction_dependency_history_size` | Sí | Este parámetro establece un límite superior en el número de hashes de fila que se guardan en la memoria y se utiliza para buscar la transacción que modificó por última vez una fila determinada. Cuando se alcanza este número de hashes, se purga el historial. Este parámetro se aplica a la versión 2.12 y versiones posteriores y a la versión 3 de Aurora MySQL. |
| `binlog_transaction_dependency_tracking` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `character-set-client-handshake` | Sí | |
| `character_set_client` | Sí | |
| `character_set_connection` | Sí | |
| `character_set_database` | Sí | |
| `character_set_filesystem` | Sí | |
| `character_set_results` | Sí | |
| `character_set_server` | Sí | |
| `collation_connection` | Sí | |
| `collation_server` | Sí | |
| `completion_type` | Sí | |
| `default_storage_engine` | No | Los clústeres de Aurora MySQL usan el motor de almacenamiento de InnoDB para todos sus datos. |
| `enforce_gtid_consistency` | A veces | Se puede modificar en la versión 2 de Aurora MySQL y versiones posteriores. |
| `event_scheduler` | Sí | Indica el estado del programador de eventos. Solo se puede modificar en el nivel del clúster en Aurora MySQL versión 3. |
| `gtid-mode` | A veces | Se puede modificar en la versión 2 de Aurora MySQL y versiones posteriores. |
| `information_schema_stats_expiry` | Sí | El número de segundos después de los cuales el servidor de bases de datos MySQL recupera los datos del motor de almacenamiento y los reemplaza en la memoria caché. Los valores permitidos son: Este parámetro se aplica a Aurora MySQL versión 3. |
| `init_connect` | Sí | El comando que ejecutará el servidor para cada cliente que se conecte. Utilice comillas dobles (") en la configuración para evitar errores de conexión, por ejemplo: SET optimizer_switch="hash_join=off"
En la versión 3 de Aurora MySQL, este parámetro no se aplica 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). |
| `innodb_adaptive_hash_index` | Sí | Puede modificar este parámetro en el nivel del clúster de base de datos en las versiones 2 y 3 de Aurora MySQL. El índice hash adaptativo no se admite en instancias de base de datos de lector. |
| `innodb_aurora_instant_alter_column_allowed` | Sí | Controla si el `INSTANT` algoritmo se puede utilizar para `ALTER COLUMN` operaciones a nivel global. Los valores permitidos son los siguientes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Para obtener más información, consulte [Optimizing Locking Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations) en la documentación de MySQL. Este parámetro se aplica a la versión 3.04 y versiones posteriores de Aurora MySQL. |
| `innodb_autoinc_lock_mode` | Sí | |
| `innodb_checksums` | No | Eliminado de Aurora MySQL versión 3. |
| `innodb_cmp_per_index_enabled` | Sí | |
| `innodb_commit_concurrency` | Sí | |
| `innodb_data_home_dir` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `innodb_deadlock_detect` | Sí | Esta opción se utiliza para deshabilitar la detección de bloqueos en la versión 2.11 y versiones posteriores y la versión 3 de Aurora MySQL. En los sistemas de alta simultaneidad, la detección de bloqueos puede provocar una ralentización cuando numerosos hilos esperan el mismo bloqueo. Consulte la documentación de MySQL para obtener más información sobre este parámetro. |
| `innodb_default_row_format` | Sí | Este parámetro define el formato de fila predeterminado para las tablas de InnoDB (incluidas las tablas temporales de InnoDB creadas por el usuario). Se aplica a las versiones 2 y 3 de Aurora MySQL. Su valor puede ser `DYNAMIC`, `COMPACT` o `REDUNDANT.`. |
| `innodb_file_per_table` | Sí | El parámetro afecta a cómo se organiza el almacenamiento de tablas. Para obtener más información, consulte [Escalado del almacenamiento](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling). |
| `innodb_flush_log_at_trx_commit` | Sí | Le recomendamos encarecidamente que utilice el valor predeterminado de `1`. En la versión 3 de Aurora MySQL, antes de poder configurar este parámetro con un valor distinto de `1`, primero debe cambiar el valor de `innodb_trx_commit_allow_data_loss` a `1`. Para obtener más información, consulte [Configuración de la frecuencia de vaciado del búfer de registro](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). |
| `innodb_ft_max_token_size` | Sí | |
| `innodb_ft_min_token_size` | Sí | |
| `innodb_ft_num_word_optimize` | Sí | |
| `innodb_ft_sort_pll_degree` | Sí | |
| `innodb_online_alter_log_max_size` | Sí | |
| `innodb_optimize_fulltext_only` | Sí | |
| `innodb_page_size` | No | |
| `innodb_print_all_deadlocks` | Sí | Cuando está activado, registra información sobre todos los interbloqueos de InnoDB en el registro de errores de Aurora MySQL. Para obtener más información, consulte [Minimización y solución de problemas de los interbloqueos de Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). |
| `innodb_purge_batch_size` | Sí | |
| `innodb_purge_threads` | Sí | |
| `innodb_rollback_on_timeout` | Sí | |
| `innodb_rollback_segments` | Sí | |
| `innodb_spin_wait_delay` | Sí | |
| `innodb_strict_mode` | Sí | |
| `innodb_support_xa` | Sí | Eliminado de Aurora MySQL versión 3. |
| `innodb_sync_array_size` | Sí | |
| `innodb_sync_spin_loops` | Sí | |
| `innodb_stats_include_delete_marked` | Sí | Cuando este parámetro está habilitado, InnoDB incluye los registros marcados como borrados al calcular las estadísticas persistentes del optimizador. Este parámetro se aplica a la versión 2.12 y versiones posteriores y a la versión 3 de Aurora MySQL. |
| `innodb_table_locks` | Sí | |
| `innodb_trx_commit_allow_data_loss` | Sí | En Aurora MySQL versión 3, establezca el valor de este parámetro en `1` de modo que pueda cambiar el valor de `innodb_flush_log_at_trx_commit`. El valor predeterminado de `innodb_trx_commit_allow_data_loss` es `0`. Para obtener más información, consulte [Configuración de la frecuencia de vaciado del búfer de registro](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). |
| `innodb_undo_directory` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `internal_tmp_disk_storage_engine` | Sí | Controla qué motor de almacenamiento en memoria se utiliza para las tablas temporales internas. Los valores permitidos son `INNODB` y `MYISAM`. Este parámetro se aplica a Aurora MySQL versión 2. |
| `internal_tmp_mem_storage_engine` | Sí | Controla qué motor de almacenamiento en memoria se utiliza para las tablas temporales internas. Los valores permitidos son `MEMORY` y `TempTable`. Este parámetro se aplica a Aurora MySQL versión 3. |
| `key_buffer_size` | Sí | Memoria caché de claves para tablas MyISAM. Para obtener más información, consulte [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). |
| `lc_time_names` | Sí | |
| `log_error_suppression_list` | Sí | Especifica una lista de códigos de error que no se registran en el registro de errores de MySQL. Esto le permite ignorar ciertas condiciones de error no críticas para ayudar a mantener limpios los registros de errores. Para obtener más información, consulte [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) en la documentación de MySQL. Este parámetro se aplica a la versión 3.03 y versiones posteriores de Aurora MySQL. |
| `low_priority_updates` | Sí | Las operaciones `INSERT`, `UPDATE`, `DELETE` y `LOCK TABLE WRITE` esperan hasta que no haya ninguna operación `SELECT` pendiente. Este parámetro solo afecta a los motores de almacenamiento que utilizan únicamente el bloqueo en el nivel de tabla (MyISAM, MEMORY, MERGE). Este parámetro se aplica a Aurora MySQL versión 3. |
| `lower_case_table_names` | Sí (para la versión 2 de Aurora MySQL) Solo en el momento de la creación del clúster (versión 3 de Aurora MySQL) | En las versiones 2.10 de Aurora MySQL y posteriores 2.x, asegúrese de reiniciar todas las instancias del lector después de cambiar esta configuración y reiniciar la instancia del escritor. Para obtener más información, consulte [Reinicio de un clúster de Aurora con disponibilidad de lectura](aurora-mysql-survivable-replicas.md). En Aurora MySQL versión 3, el valor de este parámetro se establece de forma permanente en el momento de crear 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 y especifique el grupo de parámetros durante la operación de restauración de instantáneas que crea el clúster de la versión 3. 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. Para obtener más información sobre los métodos que puede utilizar, consulte [Actualizaciones de la versión principal](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major). |
| `master-info-repository` | Sí | Eliminado de Aurora MySQL versión 3. |
| `master_verify_checksum` | Sí | Aurora MySQL versión 2. Usar `source_verify_checksum` en Aurora MySQL versión 3. |
| `max_delayed_threads` | Sí | Establece el número máximo de subprocesos para gestionar las instrucciones `INSERT DELAYED`. Este parámetro se aplica a Aurora MySQL versión 3. |
| `max_error_count` | Sí | Número máximo de mensajes de error, advertencia y nota que se almacenará para su visualización. Este parámetro se aplica a Aurora MySQL versión 3. |
| `max_execution_time` | Sí | El tiempo de espera para ejecutar instrucciones `SELECT`, en milisegundos. Los valores pueden ser de `0` a `18446744073709551615`. Si se establece en `0`, no hay tiempo de espera. Para obtener más información, consulte [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) en la documentación de MySQL. |
| `min_examined_row_limit` | Sí | Utilice este parámetro para evitar que se registren las consultas que examinan un número de filas inferior al especificado. Este parámetro se aplica a Aurora MySQL versión 3. |
| `partial_revokes` | No | Este parámetro se aplica a Aurora MySQL versión 3. |
| `preload_buffer_size` | Sí | Tamaño del búfer que se asigna al precargar los índices. Este parámetro se aplica a Aurora MySQL versión 3. |
| `query_cache_type` | Sí | Eliminado de Aurora MySQL versión 3. |
| `read_only` | Sí | Cuando este parámetro está activado, el servidor no permite actualizaciones, excepto las que realizan los subprocesos de réplica. Los valores válidos para Aurora MySQL versión 2 son los siguientes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Los valores válidos para Aurora MySQL versión 3 son los siguientes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) En la versión 3 de Aurora MySQL, este parámetro no se aplica 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). |
| `relay-log-space-limit` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `replica_parallel_type` | Sí | Este parámetro permite la ejecución en paralelo en la réplica de todos los subprocesos no confirmados que ya se encuentran en la fase de preparación, sin infringir la coherencia. Se aplica a la versión 3 de Aurora MySQL. En la versión 3.03.\$1 y versiones anteriores de Aurora MySQL, el valor predeterminado es DATABASE. En la versión 3.04 y versiones anteriores de Aurora MySQL, el valor predeterminado es LOGICAL\$1CLOCK. |
| `replica_preserve_commit_order` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `replica_transaction_retries` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `replica_type_conversions` | Sí | Este parámetro determina las conversiones de tipo utilizadas en las réplicas. Los valores permitidos son `ALL_LOSSY` `ALL_NON_LOSSY`, `ALL_SIGNED` y `ALL_UNSIGNED`. Para obtener más información, consulte el tema de [Replicación con definiciones de tablas diferentes sobre el origen y la réplica](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) en la documentación de MySQL. Este parámetro se aplica a Aurora MySQL versión 3. |
| `replicate-do-db` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `replicate-do-table` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `replicate-ignore-db` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `replicate-ignore-table` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `replicate-wild-do-table` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `replicate-wild-ignore-table` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `require_secure_transport` | Sí | Este parámetro se aplica a Aurora MySQL versión 2 y 3. Para obtener más información, consulte [Conexiones TLS a clústeres de base de datos de Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). |
| `rpl_read_size` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `server_audit_cw_upload` | No | Este parámetro ha quedado obsoleto en Aurora MySQL. Utilice `server_audit_logs_upload`. Para obtener más información, consulte [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_audit_events` | Sí | Para obtener más información, consulte [Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Auditing.md). |
| `server_audit_excl_users` | Sí | Para obtener más información, consulte [Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Auditing.md). |
| `server_audit_incl_users` | Sí | Para obtener más información, consulte [Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Auditing.md). |
| `server_audit_logging` | Sí | Para conocer las instrucciones sobre la carga de los registros en registros de Amazon Cloudwatch, consulte [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_audit_logs_upload` | Sí | Puede publicar registros de auditoría en CloudWatch Logs activando la auditoría avanzada y configurando este parámetro en `1`. El valor predeterminado para el parámetro `server_audit_logs_upload` es `0`. Para obtener más información, consulte [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_id` | No | |
| `skip-character-set-client-handshake` | Sí | |
| `skip_name_resolve` | No | |
| `slave-skip-errors` | Sí | Solo se aplica a clústeres de la versión 2 de Aurora MySQL, con compatibilidad MySQL 5.7. |
| `source_verify_checksum` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `sync_frm` | Sí | Eliminado de Aurora MySQL versión 3. |
| `thread_cache_size` | Sí | La cantidad de subprocesos que se van a almacenar en caché. Este parámetro se aplica a Aurora MySQL versiones 2 y 3. |
| `time_zone` | Sí | De manera predeterminada, la zona horaria de un clúster de base de datos de Aurora es el horario universal coordinado (UTC). En su lugar, puede definir la zona horaria de las instancias del clúster de base de datos en la zona horaria local de su aplicación. Para obtener más información, consulte [Zona horaria local para los clústeres de base de datos de Amazon Aurora](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone). |
| `tls_version` | Sí | Para obtener más información, consulte [Versiones de TLS para Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version). |
## Parámetros de nivel de instancia
En la siguiente tabla se muestran todos los parámetros que afectan a una instancia de base de datos concreta de un clúster de bases de datos Aurora MySQL.
| Nombre del parámetro | Modificable | Notas |
| --- | --- | --- |
| `activate_all_roles_on_login` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `allow-suspicious-udfs` | No | |
| `aurora_disable_hash_join` | Sí | Establezca este valor en `ON` para desactivar la optimización de las combinaciones hash en Aurora MySQL versión 2.09 o posteriores. No se admite en la versión 3. Para obtener más información, consulte [Consulta paralela para Amazon Aurora MySQL](aurora-mysql-parallel-query.md). |
| `aurora_lab_mode` | Sí | Para obtener más información, consulte [Modo lab de Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md). Eliminado de Aurora MySQL versión 3. |
| `aurora_oom_response` | Sí | Este parámetro se admite en las versiones 2 y 3 de Aurora MySQL. Para obtener más información, consulte [Solución de problemas de memoria insuficiente de bases de datos Aurora MySQL](AuroraMySQLOOM.md). |
| `aurora_parallel_query` | Sí | Establezca este valor en `ON` para activar la consulta paralela en las versiones de Aurora MySQL 2.09 o posteriores. El parámetro anterior de `aurora_pq` no se utiliza en estas versiones. Para obtener más información, consulte [Consulta paralela para Amazon Aurora MySQL](aurora-mysql-parallel-query.md). |
| `aurora_pq` | Sí | Establezca el valor en `OFF` para desactivar la consulta paralela para instancias de base de datos específicas en versiones de Aurora MySQL anteriores a 2.09. En la versión 2.09 o posteriores, active y desactive la consulta paralela con `aurora_parallel_query` en su lugar. Para obtener más información, consulte [Consulta paralela para Amazon Aurora MySQL](aurora-mysql-parallel-query.md). |
| `aurora_read_replica_read_committed` | Sí | Habilita el nivel de aislamiento `READ COMMITTED` para las réplicas de Aurora y cambia el comportamiento del aislamiento para reducir el lag de purgado durante las consultas de ejecución prolongada. Habilite esta configuración solo si comprende los cambios de comportamiento y cómo afectan a los resultados de su consulta. Por ejemplo, esta configuración utiliza un aislamiento menos estricto que el MySQL predeterminado. Cuando se habilita, las consultas de ejecución prolongada pueden ver más de una copia de la misma fila ya que Aurora reorganiza los datos de la tabla mientras se ejecuta la consulta. Para obtener más información, consulte [Niveles de aislamiento de Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md). |
| `aurora_tmptable_enable_per_table_limit` | Sí | Determina si el parámetro `tmp_table_size` controla el tamaño máximo de las tablas temporales en memoria creadas por el motor de almacenamiento `TempTable` en la versión 3.04 y versiones posteriores de Aurora MySQL. Para obtener más información, consulte [Limitación del tamaño de las tablas temporales internas en memoria](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). |
| `aurora_use_vector_instructions` | Sí | Cuando este parámetro está habilitado, Aurora MySQL utiliza las instrucciones de procesamiento vectorial optimizadas que proporcionan las CPU modernas para mejorar el rendimiento en las cargas de trabajo con un uso intensivo de E/S. Esta configuración se activa de forma predeterminada en Aurora MySQL 2.11 y posteriores. |
| `autocommit` | Sí | |
| `automatic_sp_privileges` | Sí | |
| `back_log` | Sí | |
| `basedir` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `binlog_cache_size` | Sí | |
| `binlog_max_flush_queue_time` | Sí | |
| `binlog_order_commits` | Sí | |
| `binlog_stmt_cache_size` | Sí | |
| `binlog_transaction_compression` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `binlog_transaction_compression_level_zstd` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `bulk_insert_buffer_size` | Sí | |
| `concurrent_insert` | Sí | |
| `connect_timeout` | Sí | |
| `core-file` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `datadir` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `default_authentication_plugin` | No | Este parámetro se aplica a Aurora MySQL versión 3. |
| `default_time_zone` | No | |
| `default_tmp_storage_engine` | Sí | Motor de almacenamiento predeterminado para tablas temporales. |
| `default_week_format` | Sí | |
| `delay_key_write` | Sí | |
| `delayed_insert_limit` | Sí | |
| `delayed_insert_timeout` | Sí | |
| `delayed_queue_size` | Sí | |
| `div_precision_increment` | Sí | |
| `end_markers_in_json` | Sí | |
| `eq_range_index_dive_limit` | Sí | |
| `event_scheduler` | A veces | Indica el estado del programador de eventos. Solo se puede modificar a nivel de clúster en Aurora MySQL versión 3. |
| `explicit_defaults_for_timestamp` | Sí | |
| `flush` | No | |
| `flush_time` | Sí | |
| `ft_boolean_syntax` | No | |
| `ft_max_word_len` | Sí | |
| `ft_min_word_len` | Sí | |
| `ft_query_expansion_limit` | Sí | |
| `ft_stopword_file` | Sí | |
| `general_log` | Sí | Para conocer las instrucciones sobre la carga de los registros en CloudWatch Logs, consulte [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `general_log_file` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `group_concat_max_len` | Sí | |
| `host_cache_size` | Sí | |
| `init_connect` | Sí | El comando que ejecutará el servidor para cada cliente que se conecte. Utilice comillas dobles (") en la configuración para evitar errores de conexión, por ejemplo: SET optimizer_switch="hash_join=off"
En la versión 3 de Aurora MySQL, este parámetro no se aplica a los usuarios que tienen el privilegio `CONNECTION_ADMIN`, incluido el 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). |
| `innodb_adaptive_hash_index` | Sí | Puede modificar este parámetro en el nivel de la instancia de base de datos en la versión 2 de Aurora MySQL. Solo se puede modificar en el nivel del clúster de base de datos en Aurora MySQL versión 3. El índice hash adaptativo no se admite en instancias de base de datos de lector. |
| `innodb_adaptive_max_sleep_delay` | Sí | La modificación de este parámetro no tiene ningún efecto, porque `innodb_thread_concurrency` es siempre 0 para Aurora. |
| `innodb_aurora_max_partitions_for_range` | Sí | En algunos casos en los que las estadísticas persistentes no estén disponibles, puede utilizar este parámetro para mejorar el rendimiento de las estimaciones del recuento de filas en las tablas divididas. Puede configurarlo en un valor comprendido entre 0 y 8192, donde el valor determina el número de particiones que se van a comprobar durante la estimación del recuento de filas. El valor predeterminado es 0, que se estima utilizando todas las particiones, de acuerdo con el comportamiento predeterminado de MySQL. Este parámetro está disponible para la versión 3.03.1 y posteriores de Aurora MySQL. |
| `innodb_autoextend_increment` | Sí | |
| `innodb_buffer_pool_dump_at_shutdown` | No | |
| `innodb_buffer_pool_dump_now` | No | |
| `innodb_buffer_pool_filename` | No | |
| `innodb_buffer_pool_load_abort` | No | |
| `innodb_buffer_pool_load_at_startup` | No | |
| `innodb_buffer_pool_load_now` | No | |
| `innodb_buffer_pool_size` | Sí | El valor predeterminado se representa con una fórmula. Para obtener más información sobre cómo se calcula el valor de `DBInstanceClassMemory` de la fórmula, consulte [Variables de las fórmulas de parámetros de base de datos](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `innodb_change_buffer_max_size` | No | Aurora MySQL no utiliza el búfer de cambio de InnoDB en absoluto. |
| `innodb_compression_failure_threshold_pct` | Sí | |
| `innodb_compression_level` | Sí | |
| `innodb_compression_pad_pct_max` | Sí | |
| `innodb_concurrency_tickets` | Sí | La modificación de este parámetro no tiene ningún efecto, porque `innodb_thread_concurrency` es siempre 0 para Aurora. |
| `innodb_deadlock_detect` | Sí | Esta opción se utiliza para deshabilitar la detección de bloqueos en la versión 2.11 y versiones posteriores y la versión 3 de Aurora MySQL. En los sistemas de alta simultaneidad, la detección de bloqueos puede provocar una ralentización cuando numerosos hilos esperan el mismo bloqueo. Consulte la documentación de MySQL para obtener más información sobre este parámetro. |
| `innodb_file_format` | Sí | Eliminado de Aurora MySQL versión 3. |
| `innodb_flushing_avg_loops` | No | |
| `innodb_force_load_corrupted` | No | |
| `innodb_ft_aux_table` | Sí | |
| `innodb_ft_cache_size` | Sí | |
| `innodb_ft_enable_stopword` | Sí | |
| `innodb_ft_server_stopword_table` | Sí | |
| `innodb_ft_user_stopword_table` | Sí | |
| `innodb_large_prefix` | Sí | Eliminado de Aurora MySQL versión 3. |
| `innodb_lock_wait_timeout` | Sí | |
| `innodb_log_compressed_pages` | No | |
| `innodb_lru_scan_depth` | Sí | |
| `innodb_max_purge_lag` | Sí | |
| `innodb_max_purge_lag_delay` | Sí | |
| `innodb_monitor_disable` | Sí | |
| `innodb_monitor_enable` | Sí | |
| `innodb_monitor_reset` | Sí | |
| `innodb_monitor_reset_all` | Sí | |
| `innodb_old_blocks_pct` | Sí | |
| `innodb_old_blocks_time` | Sí | |
| `innodb_open_files` | Sí | |
| `innodb_print_all_deadlocks` | Sí | Cuando está activado, registra información sobre todos los interbloqueos de InnoDB en el registro de errores de Aurora MySQL. Para obtener más información, consulte [Minimización y solución de problemas de los interbloqueos de Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). |
| `innodb_random_read_ahead` | Sí | |
| `innodb_read_ahead_threshold` | Sí | |
| `innodb_read_io_threads` | No | |
| `innodb_read_only` | No | Aurora MySQL administra el estado de solo lectura y lectura/escritura de las instancias de base de datos según el tipo de clúster. Por ejemplo, un clúster aprovisionado dispone de una instancia de base de datos de lectura/escritura (la *instancia principal*) y mis otras instancias en el clúster son de solo lectura (las réplicas de Aurora). |
| `innodb_replication_delay` | Sí | |
| `innodb_sort_buffer_size` | Sí | |
| `innodb_stats_auto_recalc` | Sí | |
| `innodb_stats_method` | Sí | |
| `innodb_stats_on_metadata` | Sí | |
| `innodb_stats_persistent` | Sí | |
| `innodb_stats_persistent_sample_pages` | Sí | |
| `innodb_stats_transient_sample_pages` | Sí | |
| `innodb_thread_concurrency` | No | |
| `innodb_thread_sleep_delay` | Sí | La modificación de este parámetro no tiene ningún efecto, porque `innodb_thread_concurrency` es siempre 0 para Aurora. |
| `interactive_timeout` | Sí | Aurora evalúa el valor mínimo de `interactive_timeout` y `wait_timeout`. Utiliza ese mínimo como tiempo de espera para finalizar todas las sesiones inactivas, tanto interactivas como no interactivas. |
| `internal_tmp_disk_storage_engine` | Sí | Controla qué motor de almacenamiento en memoria se utiliza para las tablas temporales internas. Los valores permitidos son `INNODB` y `MYISAM`. Este parámetro se aplica a Aurora MySQL versión 2. |
| `internal_tmp_mem_storage_engine` | Sí | Controla qué motor de almacenamiento en memoria se utiliza para las tablas temporales internas. Los valores permitidos son `MEMORY` y `TempTable`. Este parámetro se aplica a Aurora MySQL versión 3. |
| `join_buffer_size` | Sí | |
| `keep_files_on_create` | Sí | |
| `key_buffer_size` | Sí | Memoria caché de claves para tablas MyISAM. Para obtener más información, consulte [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). |
| `key_cache_age_threshold` | Sí | |
| `key_cache_block_size` | Sí | |
| `key_cache_division_limit` | Sí | |
| `local_infile` | Sí | |
| `lock_wait_timeout` | Sí | |
| `log-bin` | No | Si `binlog_format` se establece en `STATEMENT`, `MIXED`, o `ROW`, `log-bin` se establecerá automáticamente en `ON`. Si se establece `binlog_format` en `OFF`, `log-bin` se establecerá automáticamente en `OFF`. Para obtener más información, 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). |
| `log_bin_trust_function_creators` | Sí | |
| `log_bin_use_v1_row_events` | Sí | Eliminado de Aurora MySQL versión 3. |
| `log_error` | No | |
| `log_error_suppression_list` | Sí | Especifica una lista de códigos de error que no se registran en el registro de errores de MySQL. Esto le permite ignorar ciertas condiciones de error no críticas para ayudar a mantener limpios los registros de errores. Para obtener más información, consulte [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) en la documentación de MySQL. Este parámetro se aplica a la versión 3.03 y versiones posteriores de Aurora MySQL. |
| `log_output` | Sí | |
| `log_queries_not_using_indexes` | Sí | |
| `log_slave_updates` | No | Aurora MySQL versión 2. Usar `log_replica_updates` en Aurora MySQL versión 3. |
| `log_replica_updates` | No | Aurora MySQL versión 3 |
| `log_throttle_queries_not_using_indexes` | Sí | |
| `log_warnings` | Sí | Eliminado de Aurora MySQL versión 3. |
| `long_query_time` | Sí | |
| `low_priority_updates` | Sí | Las operaciones `INSERT`, `UPDATE`, `DELETE` y `LOCK TABLE WRITE` esperan hasta que no haya ninguna operación `SELECT` pendiente. Este parámetro solo afecta a los motores de almacenamiento que utilizan únicamente el bloqueo en el nivel de tabla (MyISAM, MEMORY, MERGE). Este parámetro se aplica a Aurora MySQL versión 3. |
| `max_allowed_packet` | Sí | |
| `max_binlog_cache_size` | Sí | |
| `max_binlog_size` | No | |
| `max_binlog_stmt_cache_size` | Sí | |
| `max_connect_errors` | Sí | |
| `max_connections` | Sí | El valor predeterminado se representa con una fórmula. Para obtener más información sobre cómo se calcula el valor de `DBInstanceClassMemory` de la fórmula, consulte [Variables de las fórmulas de parámetros de base de datos](USER_ParamValuesRef.md#USER_FormulaVariables). Para ver los valores predeterminados en función de la clase de instancia, consulte [Número máximo de conexiones a una instancia de base de datos Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections). |
| `max_delayed_threads` | Sí | Establece el número máximo de subprocesos para gestionar las instrucciones `INSERT DELAYED`. Este parámetro se aplica a Aurora MySQL versión 3. |
| `max_error_count` | Sí | Número máximo de mensajes de error, advertencia y nota que se almacenará para su visualización. Este parámetro se aplica a Aurora MySQL versión 3. |
| `max_execution_time` | Sí | El tiempo de espera para ejecutar instrucciones `SELECT`, en milisegundos. Los valores pueden ser de `0` a `18446744073709551615`. Si se establece en `0`, no hay tiempo de espera. Para obtener más información, consulte [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) en la documentación de MySQL. |
| `max_heap_table_size` | Sí | |
| `max_insert_delayed_threads` | Sí | |
| `max_join_size` | Sí | |
| `max_length_for_sort_data` | Sí | Eliminado de Aurora MySQL versión 3. |
| `max_prepared_stmt_count` | Sí | |
| `max_seeks_for_key` | Sí | |
| `max_sort_length` | Sí | |
| `max_sp_recursion_depth` | Sí | |
| `max_tmp_tables` | Sí | Eliminado de Aurora MySQL versión 3. |
| `max_user_connections` | Sí | |
| `max_write_lock_count` | Sí | |
| `metadata_locks_cache_size` | Sí | Eliminado de Aurora MySQL versión 3. |
| `min_examined_row_limit` | Sí | Utilice este parámetro para evitar que se registren las consultas que examinan un número de filas inferior al especificado. Este parámetro se aplica a Aurora MySQL versión 3. |
| `myisam_data_pointer_size` | Sí | |
| `myisam_max_sort_file_size` | Sí | |
| `myisam_mmap_size` | Sí | |
| `myisam_sort_buffer_size` | Sí | |
| `myisam_stats_method` | Sí | |
| `myisam_use_mmap` | Sí | |
| `net_buffer_length` | Sí | |
| `net_read_timeout` | Sí | |
| `net_retry_count` | Sí | |
| `net_write_timeout` | Sí | |
| `old-style-user-limits` | Sí | |
| `old_passwords` | Sí | Eliminado de Aurora MySQL versión 3. |
| `optimizer_prune_level` | Sí | |
| `optimizer_search_depth` | Sí | |
| `optimizer_switch` | Sí | Para obtener información acerca de las características de Aurora MySQL que utilizan este modificador, consulte [Prácticas recomendadas con Amazon Aurora MySQL](AuroraMySQL.BestPractices.md). |
| `optimizer_trace` | Sí | |
| `optimizer_trace_features` | Sí | |
| `optimizer_trace_limit` | Sí | |
| `optimizer_trace_max_mem_size` | Sí | |
| `optimizer_trace_offset` | Sí | |
| `performance-schema-consumer-events-waits-current` | Sí | |
| `performance-schema-instrument` | Sí | |
| `performance_schema` | Sí | |
| `performance_schema_accounts_size` | Sí | |
| `performance_schema_consumer_global_instrumentation` | Sí | |
| `performance_schema_consumer_thread_instrumentation` | Sí | |
| `performance_schema_consumer_events_stages_current` | Sí | |
| `performance_schema_consumer_events_stages_history` | Sí | |
| `performance_schema_consumer_events_stages_history_long` | Sí | |
| `performance_schema_consumer_events_statements_current` | Sí | |
| `performance_schema_consumer_events_statements_history` | Sí | |
| `performance_schema_consumer_events_statements_history_long` | Sí | |
| `performance_schema_consumer_events_waits_history` | Sí | |
| `performance_schema_consumer_events_waits_history_long` | Sí | |
| `performance_schema_consumer_statements_digest` | Sí | |
| `performance_schema_digests_size` | Sí | |
| `performance_schema_events_stages_history_long_size` | Sí | |
| `performance_schema_events_stages_history_size` | Sí | |
| `performance_schema_events_statements_history_long_size` | Sí | |
| `performance_schema_events_statements_history_size` | Sí | |
| `performance_schema_events_transactions_history_long_size` | Sí | |
| `performance_schema_events_transactions_history_size` | Sí | |
| `performance_schema_events_waits_history_long_size` | Sí | |
| `performance_schema_events_waits_history_size` | Sí | |
| `performance_schema_hosts_size` | Sí | |
| `performance_schema_max_cond_classes` | Sí | |
| `performance_schema_max_cond_instances` | Sí | |
| `performance_schema_max_digest_length` | Sí | |
| `performance_schema_max_file_classes` | Sí | |
| `performance_schema_max_file_handles` | Sí | |
| `performance_schema_max_file_instances` | Sí | |
| `performance_schema_max_index_stat` | Sí | |
| `performance_schema_max_memory_classes` | Sí | |
| `performance_schema_max_metadata_locks` | Sí | |
| `performance_schema_max_mutex_classes` | Sí | |
| `performance_schema_max_mutex_instances` | Sí | |
| `performance_schema_max_prepared_statements_instances` | Sí | |
| `performance_schema_max_program_instances` | Sí | |
| `performance_schema_max_rwlock_classes` | Sí | |
| `performance_schema_max_rwlock_instances` | Sí | |
| `performance_schema_max_socket_classes` | Sí | |
| `performance_schema_max_socket_instances` | Sí | |
| `performance_schema_max_sql_text_length` | Sí | |
| `performance_schema_max_stage_classes` | Sí | |
| `performance_schema_max_statement_classes` | Sí | |
| `performance_schema_max_statement_stack` | Sí | |
| `performance_schema_max_table_handles` | Sí | |
| `performance_schema_max_table_instances` | Sí | |
| `performance_schema_max_table_lock_stat` | Sí | |
| `performance_schema_max_thread_classes` | Sí | |
| `performance_schema_max_thread_instances` | Sí | |
| `performance_schema_session_connect_attrs_size` | Sí | |
| `performance_schema_setup_actors_size` | Sí | |
| `performance_schema_setup_objects_size` | Sí | |
| `performance_schema_show_processlist` | Sí | Este parámetro determina qué implementación SHOW PROCESSLIST utilizar: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)Este parámetro se aplica a la versión 2.12 y versiones posteriores y a la versión 3 de Aurora MySQL. |
| `performance_schema_users_size` | Sí | |
| `pid_file` | No | |
| `plugin_dir` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `port` | No | Aurora MySQL administra las propiedades de conexión e implementa una configuración coherente para todas las instancias de base de datos en un clúster. |
| `preload_buffer_size` | Sí | Tamaño del búfer que se asigna al precargar los índices. Este parámetro se aplica a Aurora MySQL versión 3. |
| `profiling_history_size` | Sí | |
| `query_alloc_block_size` | Sí | |
| `query_cache_limit` | Sí | Eliminado de Aurora MySQL versión 3. |
| `query_cache_min_res_unit` | Sí | Eliminado de Aurora MySQL versión 3. |
| `query_cache_size` | Sí | El valor predeterminado se representa con una fórmula. Para obtener más información sobre cómo se calcula el valor de `DBInstanceClassMemory` de la fórmula, consulte [Variables de las fórmulas de parámetros de base de datos](USER_ParamValuesRef.md#USER_FormulaVariables). Eliminado de Aurora MySQL versión 3. |
| `query_cache_type` | Sí | Eliminado de Aurora MySQL versión 3. |
| `query_cache_wlock_invalidate` | Sí | Eliminado de Aurora MySQL versión 3. |
| `query_prealloc_size` | Sí | |
| `range_alloc_block_size` | Sí | |
| `read_buffer_size` | Sí | |
| `read_only` | Sí | Cuando este parámetro está activado, el servidor no permite actualizaciones, excepto las que realizan los subprocesos de réplica. Los valores válidos para Aurora MySQL versión 2 son los siguientes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Le recomendamos que utilice el grupo de parámetros del clúster de base de datos de la versión 2 de Aurora MySQL para asegurarse de que el parámetro `read_only` se aplica a las nuevas instancias de escritor en caso de conmutación por error. Las instancias de lector siempre son de solo lectura, porque Aurora MySQL establece `innodb_read_only` en `1` en todos los lectores. Por lo tanto, `read_only` es redundante en las instancias del lector. Eliminado en el nivel de la instancia en Aurora MySQL versión 3. |
| `read_rnd_buffer_size` | Sí | |
| `relay-log` | No | |
| `relay_log_info_repository` | Sí | Eliminado de Aurora MySQL versión 3. |
| `relay_log_recovery` | No | |
| `replica_checkpoint_group` | Sí | Aurora MySQL versión 3 |
| `replica_checkpoint_period` | Sí | Aurora MySQL versión 3 |
| `replica_parallel_workers` | Sí | Aurora MySQL versión 3 |
| `replica_pending_jobs_size_max` | Sí | Aurora MySQL versión 3 |
| `replica_skip_errors` | Sí | Aurora MySQL versión 3 |
| `replica_sql_verify_checksum` | Sí | Aurora MySQL versión 3 |
| `safe-user-create` | Sí | |
| `secure_auth` | Sí | Este parámetro está siempre activado en Aurora MySQL versión 2. Al intentar desactivarlo, se produce un error. Eliminado de Aurora MySQL versión 3. |
| `secure_file_priv` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `show_create_table_verbosity` | Sí | La habilitación de esta variable provoca que [SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html) muestre `ROW_FORMAT` con independencia de si es el formato predeterminado. Este parámetro se aplica a la versión 2.12 y versiones posteriores y a la versión 3 de Aurora MySQL. |
| `skip-slave-start` | No | |
| `skip_external_locking` | No | |
| `skip_show_database` | Sí | |
| `slave_checkpoint_group` | Sí | Aurora MySQL versión 2. Usar `replica_checkpoint_group` en Aurora MySQL versión 3. |
| `slave_checkpoint_period` | Sí | Aurora MySQL versión 2. Usar `replica_checkpoint_period` en Aurora MySQL versión 3. |
| `slave_parallel_workers` | Sí | Aurora MySQL versión 2. Usar `replica_parallel_workers` en Aurora MySQL versión 3. |
| `slave_pending_jobs_size_max` | Sí | Aurora MySQL versión 2. Usar `replica_pending_jobs_size_max` en Aurora MySQL versión 3. |
| `slave_sql_verify_checksum` | Sí | Aurora MySQL versión 2. Usar `replica_sql_verify_checksum` en Aurora MySQL versión 3. |
| `slow_launch_time` | Sí | |
| `slow_query_log` | Sí | Para conocer las instrucciones sobre la carga de los registros en CloudWatch Logs, consulte [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `slow_query_log_file` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `socket` | No | |
| `sort_buffer_size` | Sí | |
| `sql_mode` | Sí | |
| `sql_select_limit` | Sí | |
| `stored_program_cache` | Sí | |
| `sync_binlog` | No | |
| `sync_master_info` | Sí | |
| `sync_source_info` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. |
| `sync_relay_log` | Sí | Eliminado de Aurora MySQL versión 3. |
| `sync_relay_log_info` | Sí | |
| `sysdate-is-now` | Sí | |
| `table_cache_element_entry_ttl` | No | |
| `table_definition_cache` | Sí | El valor predeterminado se representa con una fórmula. Para obtener más información sobre cómo se calcula el valor de `DBInstanceClassMemory` de la fórmula, consulte [Variables de las fórmulas de parámetros de base de datos](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `table_open_cache` | Sí | El valor predeterminado se representa con una fórmula. Para obtener más información sobre cómo se calcula el valor de `DBInstanceClassMemory` de la fórmula, consulte [Variables de las fórmulas de parámetros de base de datos](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `table_open_cache_instances` | Sí | |
| `temp-pool` | Sí | Eliminado de Aurora MySQL versión 3. |
| `temptable_max_mmap` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. Para obtener más información, consulte [Nuevo comportamiento de tabla temporal en Aurora MySQL versión 3](ams3-temptable-behavior.md). |
| `temptable_max_ram` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. Para obtener más información, consulte [Nuevo comportamiento de tabla temporal en Aurora MySQL versión 3](ams3-temptable-behavior.md). |
| `temptable_use_mmap` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. Para obtener más información, consulte [Nuevo comportamiento de tabla temporal en Aurora MySQL versión 3](ams3-temptable-behavior.md). |
| `thread_cache_size` | Sí | La cantidad de subprocesos que se van a almacenar en caché. Este parámetro se aplica a Aurora MySQL versiones 2 y 3. |
| `thread_handling` | No | |
| `thread_stack` | Sí | |
| `timed_mutexes` | Sí | |
| `tmp_table_size` | Sí | Define el tamaño máximo de las tablas temporales internas en memoria creadas por el motor de almacenamiento `MEMORY` en la versión 3 de Aurora MySQL. En la versión 3.04 y versiones posteriores de Aurora MySQL, define el tamaño máximo de las tablas temporales internas en memoria creadas por el motor de almacenamiento `TempTable` cuando `aurora_tmptable_enable_per_table_limit` está configurado en `ON`. Para obtener más información, consulte [Limitación del tamaño de las tablas temporales internas en memoria](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). |
| `tmpdir` | No | Aurora MySQL utiliza instancias administradas en las que no accede al sistema de archivos directamente. |
| `transaction_alloc_block_size` | Sí | |
| `transaction_isolation` | Sí | Este parámetro se aplica a Aurora MySQL versión 3. Sustituye a `tx_isolation`. |
| `transaction_prealloc_size` | Sí | |
| `tx_isolation` | Sí | Eliminado de Aurora MySQL versión 3. Se sustituye por `transaction_isolation`. |
| `updatable_views_with_limit` | Sí | |
| `validate-password` | No | |
| `validate_password_dictionary_file` | No | |
| `validate_password_length` | No | |
| `validate_password_mixed_case_count` | No | |
| `validate_password_number_count` | No | |
| `validate_password_policy` | No | |
| `validate_password_special_char_count` | No | |
| `wait_timeout` | Sí | Aurora evalúa el valor mínimo de `interactive_timeout` y `wait_timeout`. Utiliza ese mínimo como tiempo de espera para finalizar todas las sesiones inactivas, tanto interactivas como no interactivas. |
## Parámetros de MySQL que no se aplican a Aurora MySQL
Debido a las diferencias de arquitectura entre Aurora MySQL y MySQL, algunos parámetros de MySQL no se aplican a Aurora MySQL.
Los siguientes parámetros de MySQL no se aplican a Aurora MySQL. Esta lista no es exhaustiva.
+ `activate_all_roles_on_login`: este parámetro no se aplica a Aurora MySQL versión 2. Está disponible en Aurora MySQL versión 3.
+ `big_tables`
+ `bind_address`
+ `character_sets_dir`
+ `innodb_adaptive_flushing`
+ `innodb_adaptive_flushing_lwm`
+ `innodb_buffer_pool_chunk_size`
+ `innodb_buffer_pool_instances`
+ `innodb_change_buffering`
+ `innodb_checksum_algorithm`
+ `innodb_data_file_path`
+ `innodb_dedicated_server`
+ `innodb_doublewrite`
+ `innodb_flush_log_at_timeout`: este parámetro no se aplica a Aurora MySQL. Para obtener más información, consulte [Configuración de la frecuencia de vaciado del búfer de registro](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush).
+ `innodb_flush_method`
+ `innodb_flush_neighbors`
+ `innodb_io_capacity`
+ `innodb_io_capacity_max`
+ `innodb_log_buffer_size`
+ `innodb_log_file_size`
+ `innodb_log_files_in_group`
+ `innodb_log_spin_cpu_abs_lwm`
+ `innodb_log_spin_cpu_pct_hwm`
+ `innodb_log_writer_threads`
+ `innodb_max_dirty_pages_pct`
+ `innodb_numa_interleave`
+ `innodb_page_size`
+ `innodb_redo_log_capacity`
+ `innodb_redo_log_encrypt`
+ `innodb_undo_log_encrypt`
+ `innodb_undo_log_truncate`
+ `innodb_undo_logs`
+ `innodb_undo_tablespaces`
+ `innodb_use_native_aio`
+ `innodb_write_io_threads`
# Variables de estado globales de Aurora MySQL
Aurora MySQL incluye variables de estado de la comunidad MySQL y variables que son exclusivas de Aurora. Puede examinar estas variables para obtener información sobre lo que ocurre dentro del motor de base de datos. Para obtener más información sobre las variables de estado en la comunidad MySQL, consulte [Server Status Variables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html) en la documentación de MySQL 8.0 de la comunidad.
Puede encontrar los valores actuales de las variables de estado globales de Aurora MySQL mediante una instrucción como la siguiente:
```
show global status like '%aurora%';
```
**nota**
Las variables de estado globales se borran cuando se reinicia el motor de base de datos.
La siguiente tabla describe las variables de estado globales que utiliza Aurora MySQL.
| Nombre | Descripción |
| --- | --- |
| `AuroraDb_commits` | El número total de confirmaciones desde el último reinicio. |
| `AuroraDb_commit_latency` | La latencia de confirmación agregada desde el último reinicio. |
| `AuroraDb_ddl_stmt_duration` | La latencia de DDL agregada desde el último reinicio. |
| `AuroraDb_select_stmt_duration` | La latencia de la instrucción `SELECT` agregada desde el último reinicio. |
| `AuroraDb_insert_stmt_duration` | La latencia de la instrucción `INSERT` agregada desde el último reinicio. |
| `AuroraDb_update_stmt_duration` | La latencia de la instrucción `UPDATE` agregada desde el último reinicio. |
| `AuroraDb_delete_stmt_duration` | La latencia de la instrucción `DELETE` agregada desde el último reinicio. |
| `Aurora_binlog_io_cache_allocated` | El número de bytes asignados a la memoria caché de E/S de binlog. |
| `Aurora_binlog_io_cache_read_requests` | El número de solicitudes de lectura realizadas a la memoria caché de E/S. |
| `Aurora_binlog_io_cache_reads` | El número de solicitudes de lectura que se atendieron desde la memoria caché de E/S. |
| `Aurora_enhanced_binlog` | Indica si el binlog mejorado está habilitado o deshabilitado para esta instancia de base de datos. Para obtener más información, consulte [Configuración del binlog mejorado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `Aurora_external_connection_count` | El número de conexiones de base de datos a la instancia de base de datos, excluidas las conexiones al servicio RDS utilizadas para las comprobaciones de estado de la base de datos. |
| `Aurora_fast_insert_cache_hits` | Un contador que se incrementa cuando el cursor en caché se recupera y se verifica correctamente. Para obtener más información sobre la inserción rápida en caché, consulte [Mejoras del rendimiento de Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). |
| `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. Para obtener más información sobre la inserción rápida en caché, consulte [Mejoras del rendimiento de Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). |
| `Aurora_fts_cache_memory_used` | La cantidad de memoria en bytes que utiliza el sistema de búsqueda de texto completo de InnoDB. Esta variable se aplica a Aurora MySQL versión 3.07 y posteriores. |
| `Aurora_fwd_master_dml_stmt_count` | El número total de instrucciones DML reenviadas a esta instancia de base de datos del escritor. Esta variable se aplica a la versión 2 de Aurora MySQL. |
| `Aurora_fwd_master_dml_stmt_duration` | La duración total de las instrucciones DML reenviadas a esta instancia de base de datos del escritor. Esta variable se aplica a la versión 2 de Aurora MySQL. |
| `Aurora_fwd_master_errors_rpc_timeout` | El número de veces que no se pudo establecer una conexión reenviada en el escritor. |
| `Aurora_fwd_master_errors_session_limit` | El número de consultas reenviadas que se rechazan debido a`session full` en el escritor. |
| `Aurora_fwd_master_errors_session_timeout` | El número de veces que finaliza una sesión de reenvío debido a un tiempo de espera del escritor. |
| `Aurora_fwd_master_open_sessions` | El número de sesiones reenviadas en la instancia de base de datos del escritor. Esta variable se aplica a la versión 2 de Aurora MySQL. |
| `Aurora_fwd_master_select_stmt_count` | El número total de instrucciones `SELECT` reenviadas a esta instancia de base de datos del escritor. Esta variable se aplica a la versión 2 de Aurora MySQL. |
| `Aurora_fwd_master_select_stmt_duration` | La duración total de las instrucciones `SELECT` reenviadas a esta instancia de base de datos del escritor. Esta variable se aplica a la versión 2 de Aurora MySQL. |
| `Aurora_fwd_writer_dml_stmt_count` | El número total de instrucciones DML reenviadas a esta instancia de base de datos del escritor. Esta variable se aplica a la versión 3 de Aurora MySQL. |
| `Aurora_fwd_writer_dml_stmt_duration` | La duración total de las instrucciones DML reenviadas a esta instancia de base de datos del escritor. Esta variable se aplica a la versión 3 de Aurora MySQL. |
| `Aurora_fwd_writer_errors_rpc_timeout` | El número de veces que no se pudo establecer una conexión reenviada en el escritor. |
| `Aurora_fwd_writer_errors_session_limit` | El número de consultas reenviadas que se rechazan debido a`session full` en el escritor. |
| `Aurora_fwd_writer_errors_session_timeout` | El número de veces que finaliza una sesión de reenvío debido a un tiempo de espera del escritor. |
| `Aurora_fwd_writer_open_sessions` | El número de sesiones reenviadas en la instancia de base de datos del escritor. Esta variable se aplica a la versión 3 de Aurora MySQL. |
| `Aurora_fwd_writer_select_stmt_count` | El número total de instrucciones `SELECT` reenviadas a esta instancia de base de datos del escritor. Esta variable se aplica a la versión 3 de Aurora MySQL. |
| `Aurora_fwd_writer_select_stmt_duration` | La duración total de las instrucciones `SELECT` reenviadas a esta instancia de base de datos del escritor. Esta variable se aplica a la versión 3 de Aurora MySQL. |
| `Aurora_lockmgr_buffer_pool_memory_used` | Cantidad de memoria del grupo de búfer en bytes que utiliza el administrador de bloqueo de Aurora MySQL. |
| `Aurora_lockmgr_memory_used` | La cantidad de memoria en bytes que utiliza el administrador de bloqueo de Aurora MySQL. |
| `Aurora_ml_actual_request_cnt` | El recuento acumulado de solicitudes que hace Aurora MySQL a los servicios de machine learning de Aurora en todas las consultas ejecutadas por usuarios de la instancia de base de datos. Para obtener más información, consulte [Uso de machine learning de Amazon Aurora con Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_actual_response_cnt` | El recuento acumulado de respuestas que recibe Aurora MySQL de los servicios de machine learning de Aurora en todas las consultas ejecutadas por usuarios de la instancia de base de datos. Para obtener más información, consulte [Uso de machine learning de Amazon Aurora con Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_cache_hit_cnt` | El número acumulado de aciertos de la caché interna que Aurora MySQL recibe de los servicios de machine learning de Aurora en todas las consultas ejecutadas por usuarios de la instancia de base de datos. Para obtener más información, consulte [Uso de machine learning de Amazon Aurora con Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_logical_request_cnt` | La cantidad de solicitudes lógicas que la instancia de base de datos ha evaluado para enviarse a los servicios de machine learning de Aurora desde el último restablecimiento de estado. Dependiendo de si se ha utilizado el procesamiento por lotes, este valor puede ser superior a `Aurora_ml_actual_request_cnt`. Para obtener más información, consulte [Uso de machine learning de Amazon Aurora con Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_logical_response_cnt` | El recuento acumulado de respuestas que recibe Aurora MySQL de los servicios de machine learning de Aurora en todas las consultas ejecutadas por usuarios de la instancia de base de datos. Para obtener más información, consulte [Uso de machine learning de Amazon Aurora con Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_retry_request_cnt` | La cantidad de solicitudes reintentadas que la instancia de base de datos ha enviado a los servicios de machine learning de Aurora desde el último restablecimiento de estado. Para obtener más información, consulte [Uso de machine learning de Amazon Aurora con Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_single_request_cnt` | El número acumulado de funciones de machine learning de Aurora evaluadas por un modo distinto al modo de lote en todas las consultas ejecutadas por usuarios de la instancia de base de datos. Para obtener más información, consulte [Uso de machine learning de Amazon Aurora con Aurora MySQL](mysql-ml.md). |
| `aurora_oom_avoidance_recovery_state` | Indica si la recuperación de prevención de falta de memoria (OOM) de Aurora está en estado `ACTIVE` o `INACTIVE` para esta instancia de base de datos. Esta variable se aplica a Aurora MySQL versión 3.06.0 y posteriores. |
| `aurora_oom_reserved_mem_enter_kb` | Representa el umbral para introducir el estado `RESERVED` en el mecanismo de gestión de OOM de Aurora. Cuando la memoria disponible en el servidor se encuentra por debajo de este umbral, `aurora_oom_status` cambia a `RESERVED`, lo que indica que el servidor se acerca a un nivel crítico de uso de memoria. Esta variable se aplica a Aurora MySQL versión 3.06.0 y posteriores. |
| `aurora_oom_reserved_mem_exit_kb` | Representa el umbral para salir del estado `RESERVED` en el mecanismo de gestión de OOM de Aurora. Cuando la memoria disponible en el servidor supera este umbral, `aurora_oom_status` vuelve a ser `NORMAL`, lo que indica que el servidor ha vuelto a un estado más estable con recursos de memoria suficientes. Esta variable se aplica a Aurora MySQL versión 3.06.0 y posteriores. |
| `aurora_oom_status` | Representa el estado de OOM actual de esta instancia de base de datos. Cuando el valor es `NORMAL`, indica que hay suficientes recursos de memoria. Si el valor cambia a `RESERVED`, indica que el servidor tiene poca memoria disponible. En función de la configuración del parámetro `aurora_oom_response`, se adopta una acción u otra. Para obtener más información, consulte [Solución de problemas de memoria insuficiente de bases de datos Aurora MySQL](AuroraMySQLOOM.md). Esta variable se aplica a Aurora MySQL versión 3.06.0 y posteriores. |
| `Aurora_pq_bytes_returned` | El número de bytes de estructuras de datos de tuplas transmitido al nodo director durante las consultas en paralelo. Debe dividirse entre 16 384 para compararse con `Aurora_pq_pages_pushed_down`. |
| `Aurora_pq_max_concurrent_requests` | El número máximo de sesiones de consultas en paralelo que se pueden ejecutar simultáneamente en esta instancia de base de datos Aurora. Este es un número fijo que depende de la clase de instancia de base de datos de AWS. |
| `Aurora_pq_pages_pushed_down` | El número de páginas de datos (cada una con un tamaño fijo de 16 KiB) en las que las consultas en paralelo evitaron una transmisión de red al nodo director. |
| `Aurora_pq_request_attempted` | El número de sesiones de consultas en paralelo solicitadas. Este valor podría representar más de una sesión por consulta, dependiendo de los constructos de SQL como subconsultas y uniones. |
| `Aurora_pq_request_executed` | El número de sesiones de consultas en paralelo ejecutadas correctamente. |
| `Aurora_pq_request_failed` | El número de sesiones de consultas en paralelo que devolvieron un error al cliente. En algunos casos, una solicitud de una consulta en paralelo podría producir un error, por ejemplo, debido a un problema en la capa de almacenamiento. En tales casos, la parte de la consulta que haya producido un error vuelve a intentarse usando el mecanismo de consultas no paralelas. Si la consulta reintentada también produce un error, se devolverá un error al cliente y este contador se incrementará. |
| `Aurora_pq_request_in_progress` | El número de sesiones de consultas en paralelo en curso actualmente. Este número se aplica a la instancia de base de datos de Aurora concreta a la que se conecta, no a todo el clúster de base de datos de Aurora. Para ver si una instancia de base de datos está cerca de su límite de simultaneidad, compare este valor con el de `Aurora_pq_max_concurrent_requests`. |
| `Aurora_pq_request_not_chosen` | El número de veces que las consultas en paralelo no se han elegido para satisfacer una consulta. Este valor es la suma de varios otros contadores más detallados. Una instrucción `EXPLAIN` puede incrementar este contador aunque la consulta no se realiza en realidad. |
| `Aurora_pq_request_not_chosen_below_min_rows` | El número de veces que las consultas en paralelo no se han elegido debido al número de filas de la tabla. Una instrucción `EXPLAIN` puede incrementar este contador aunque la consulta no se realiza en realidad. |
| `Aurora_pq_request_not_chosen_column_bit` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas debido a un tipo de datos no admitido en la lista de columnas proyectadas. |
| `Aurora_pq_request_not_chosen_column_geometry` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la tabla tiene columnas con el tipo de datos `GEOMETRY`. Para obtener información acerca de las versiones de Aurora MySQL que eliminan esta limitación, 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). |
| `Aurora_pq_request_not_chosen_column_lob` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la tabla tiene columnas con un tipo de datos `LOB` o columnas `VARCHAR` que se almacenan externamente debido a la longitud declarada. Para obtener información acerca de las versiones de Aurora MySQL que eliminan esta limitación, 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). |
| `Aurora_pq_request_not_chosen_column_virtual` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la tabla contiene una columna virtual. |
| `Aurora_pq_request_not_chosen_custom_charset` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la tabla tiene columnas con un conjunto de caracteres personalizado. |
| `Aurora_pq_request_not_chosen_fast_ddl` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque actualmente se altera la tabla por una instrucción `ALTER` DDL rápida. |
| `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | El número de veces que las consultas en paralelo no se han elegido, incluso aunque menos del 95 % de los datos de tabla ya estuviera en el grupo de búfer, porque no había suficientes datos de tabla fuera de búfer para que valiera la pena realizar una consulta en paralelo. |
| `Aurora_pq_request_not_chosen_full_text_index` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la tabla tiene índices de texto completo. |
| `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | El número de veces que las consultas en paralelo no se han elegido debido a que un porcentaje elevado de datos de tabla (actualmente, superior al 95 %) ya estaba en el grupo de búfer. En estos casos, el optimizador determina que leer los datos del grupo de búfer es más eficiente. Una instrucción `EXPLAIN` puede incrementar este contador aunque la consulta no se realiza en realidad. |
| `Aurora_pq_request_not_chosen_index_hint` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la consulta incluye una sugerencia de índice. |
| `Aurora_pq_request_not_chosen_innodb_table_format` | El número de solicitudes de consulta en paralelo que utilizan la ruta de procesamiento de consultas no paralelas porque la tabla utiliza un formato de fila de InnoDB no admitido. La consulta en paralelo de Aurora solo se aplica a los formatos de fila `COMPACT`, `REDUNDANT` y `DYNAMIC`. |
| `Aurora_pq_request_not_chosen_long_trx` | El número de solicitudes de consultas en paralelo que usaron la ruta de procesamiento de consultas no en paralelo, debido a que la consulta se estaba iniciando en una transacción de ejecución prolongada. Una instrucción `EXPLAIN` puede incrementar este contador aunque la consulta no se realiza en realidad. |
| `Aurora_pq_request_not_chosen_no_where_clause` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la consulta no incluye ninguna cláusula `WHERE`. |
| `Aurora_pq_request_not_chosen_range_scan` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la consulta utiliza un análisis de intervalo en un índice. |
| `Aurora_pq_request_not_chosen_row_length_too_long` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la longitud total combinada de todas las columnas es demasiado larga. |
| `Aurora_pq_request_not_chosen_small_table` | El número de veces que las consultas en paralelo no se han elegido debido al tamaño general de la tabla, según lo determinado por el número de filas y la longitud promedio de las filas. Una instrucción `EXPLAIN` puede incrementar este contador aunque la consulta no se realiza en realidad. |
| `Aurora_pq_request_not_chosen_temporary_table` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la consulta hace referencia a tablas temporales que utilizan los tipos de tabla `MyISAM` o `memory` no admitidos. |
| `Aurora_pq_request_not_chosen_tx_isolation` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la consulta utiliza un nivel de aislamiento de transacciones no admitido. En las instancias de base de datos del lector, la consulta paralela solo se aplica a los niveles de aislamiento `REPEATABLE READ` y `READ COMMITTED`. |
| `Aurora_pq_request_not_chosen_update_delete_stmts` | El número de solicitudes de consulta paralela que utilizan la ruta de procesamiento de consultas no paralelas porque la consulta forma parte de una instrucción `UPDATE` o `DELETE`. |
| `Aurora_pq_request_not_chosen_unsupported_access` | El número de solicitudes de consultas en paralelo que usan la ruta de procesamiento de consultas no en paralelo porque la cláusula `WHERE` no cumple los criterios de consultas en paralelo. Este resultado puede producirse si la consulta no requiere un análisis de uso intensivo de datos o si la consulta es una instrucción `DELETE` o `UPDATE`. |
| `Aurora_pq_request_not_chosen_unsupported_storage_type` | El número de solicitudes de consultas en paralelo que usan la ruta de procesamiento de consultas no en paralelo porque el clúster de base de datos de Aurora MySQL no utiliza una configuración de almacenamiento de clúster de Aurora compatible. Para obtener más información, consulte [Limitaciones](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations). Este parámetro se aplica a la versión 3.04 y versiones posteriores de Aurora MySQL. |
| `Aurora_pq_request_throttled` | El número de veces que las consultas en paralelo no se han elegido debido a que el número máximo de consultas en paralelo simultáneas que ya se están ejecutando en una instancia de base de datos Aurora concreta. |
| `Aurora_repl_bytes_received` | Número de bytes replicados en una instancia de base de datos del lector de Aurora MySQL desde el último reinicio. Para obtener más información, consulte [Replicación con Amazon Aurora MySQL](AuroraMySQL.Replication.md). |
| `Aurora_reserved_mem_exceeded_incidents` | El número de veces que el motor ha superado los límites de memoria reservada desde el último reinicio. Si `aurora_oom_response` está configurado, este umbral define cuándo se activan las actividades de evitación de memoria insuficiente (OOM). Para obtener más información sobre la respuesta de OOM de Aurora MySQL, consulte [Solución de problemas de memoria insuficiente de bases de datos Aurora MySQL](AuroraMySQLOOM.md). |
| `aurora_temptable_max_ram_allocation` | Es la cantidad máxima de memoria, en bytes, utilizada en cualquier momento por las tablas temporales internas desde el último reinicio. |
| `aurora_temptable_ram_allocation` | Es la cantidad de memoria, en bytes, utilizada por las tablas temporales internas. |
| `Aurora_in_memory_relaylog_status` | El estado actual de la característica de registro de transmisión en memoria, el valor puede ser HABILITADO o DESACTIVADO. |
| `Aurora_in_memory_relaylog_disabled_reason` | Muestra el motivo del estado actual de la característica de registro de transmisión. Si la característica está desactivada, muestra un mensaje explicativo de por qué la característica está desactivada. |
| `Aurora_in_memory_relaylog_fallback_count` | Muestre el número total de retrocesos de la característica de registro de transmisión en memoria al modo de registro de retransmisión persistente (antiguo). El retroceso se puede deber a un solo evento que supere el tamaño de la caché (actualmente 128 MB) o a que un reintento de transacción supere el límite de reintentos de transacciones de réplicas replica\$1transaction\$1retries. |
| `Aurora_in_memory_relaylog_recovery_count` | Muestra el número total de recuperaciones de registros de transmisión en memoria realizadas automáticamente. Este recuento incluye el número total de retrocesos y el número de conmutaciones automáticas de vuelta al modo de registro de transmisión de memoria después de los retrocesos temporales. |
| `Aurora_thread_pool_thread_count` | El número actual de subprocesos del grupo de subprocesos de Aurora. Para obtener más información sobre el grupo de subprocesos de Aurora MySQL, consulte [Grupo de subprocesos](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool). |
| `Aurora_tmz_version` | Indica la versión actual de la información de zona horaria utilizada por el clúster de base de datos. Los valores siguen el formato IANA (Internet Assigned Numbers Authority): `YYYYsuffix`, por ejemplo, `2022a` y `2023c`. Este parámetro se aplica a la versión 2.12 y versiones posteriores y a la versión 3.04 y versiones posteriores de Aurora MySQL. |
| `Aurora_zdr_oom_threshold` | Representa el umbral de memoria, en kilobytes (KB), para que una instancia de base de datos Aurora inicie un reinicio sin tiempo de inactividad (ZDR) para recuperarse de posibles problemas relacionados con la memoria. |
| `server_aurora_das_running` | Indica si los flujos de actividad de la base de datos (DAS) están habilitados o deshabilitados en esta instancia de base de datos. Para obtener más información, consulte [Supervisión de Amazon Aurora con flujos de actividad de la base de datos](DBActivityStreams.md). |
## Variables de estado de MySQL que no se aplican a Aurora MySQL
Debido a las diferencias de arquitectura entre Aurora MySQL y MySQL, algunas variables de estado de MySQL no se aplican a Aurora MySQL.
Las siguientes variables de estado de MySQL no se aplican a Aurora MySQL. Esta lista no es exhaustiva.
+ `innodb_buffer_pool_bytes_dirty`
+ `innodb_buffer_pool_pages_dirty`
+ `innodb_buffer_pool_pages_flushed`
Aurora MySQL versión 3 elimina las siguientes variables de estado que estaban en Aurora MySQL versión 2:
+ `AuroraDb_lockmgr_bitmaps0_in_use`
+ `AuroraDb_lockmgr_bitmaps1_in_use`
+ `AuroraDb_lockmgr_bitmaps_mem_used`
+ `AuroraDb_thread_deadlocks`
+ `available_alter_table_log_entries`
+ `Aurora_lockmgr_memory_used`
+ `Aurora_missing_history_on_replica_incidents`
+ `Aurora_new_lock_manager_lock_release_cnt`
+ `Aurora_new_lock_manager_lock_release_total_duration_micro`
+ `Aurora_new_lock_manager_lock_timeout_cnt`
+ `Aurora_total_op_memory`
+ `Aurora_total_op_temp_space`
+ `Aurora_used_alter_table_log_entries`
+ `Aurora_using_new_lock_manager`
+ `Aurora_volume_bytes_allocated`
+ `Aurora_volume_bytes_left_extent`
+ `Aurora_volume_bytes_left_total`
+ `Com_alter_db_upgrade`
+ `Compression`
+ `External_threads_connected`
+ `Innodb_available_undo_logs`
+ `Last_query_cost`
+ `Last_query_partial_plans`
+ `Slave_heartbeat_period`
+ `Slave_last_heartbeat`
+ `Slave_received_heartbeats`
+ `Slave_retried_transactions`
+ `Slave_running`
+ `Time_since_zero_connections`
Estas variables de estado de MySQL están disponibles en la versión 2 de Aurora MySQL, pero no están disponibles en la versión 3 de Aurora MySQL:
+ `Innodb_redo_log_enabled`
+ `Innodb_undo_tablespaces_total`
+ `Innodb_undo_tablespaces_implicit`
+ `Innodb_undo_tablespaces_explicit`
+ `Innodb_undo_tablespaces_active`
# Eventos de espera de Aurora MySQL
He aquí algunos eventos de espera frecuentes de Aurora MySQL.
**nota**
Para obtener información sobre cómo ajustar el rendimiento de Aurora MySQL mediante eventos de espera, consulte [Ajuste de Aurora MySQL con eventos de espera](AuroraMySQL.Managing.Tuning.wait-events.md).
Para obtener información sobre las convenciones de nomenclatura de los eventos de espera de MySQL, consulte [Performance Schema Instrument Naming Conventions](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) en la documentación de MySQL.
**cpu**
El número de conexiones activas que están listas para ejecutarse es siempre mayor que el número de vCPU. Para obtener más información, consulte [cpu](ams-waits.cpu.md).
**io/aurora\$1redo\$1log\$1flush**
Una sesión está conservando datos en el almacenamiento de Aurora. Este evento de espera suele ser para una operación de E/S de escritura en Aurora MySQL. Para obtener más información, consulte [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
**io/aurora\$1respond\$1to\$1client**
El procesamiento de consultas se ha completado y se devuelven los resultados al cliente de la aplicación para las siguientes versiones de Aurora MySQL: 2.10.2 y versiones posteriores a 2.10, 2.09.3 y versiones posteriores a 2.09 y 2.07.7 y versiones posteriores a 2.07. Compare el ancho de banda de red de la clase de instancia de base de datos con el tamaño del conjunto de resultados que se devuelve. Además, verifique los tiempos de respuesta del lado del cliente. Si el cliente no responde y no puede procesar los paquetes TCP, pueden producirse caídas de paquetes y retransmisiones TCP. Esta situación afecta negativamente al ancho de banda de la red. En las versiones anteriores a 2.10.2, 2.09.3 y 2.07.7, el evento de espera incluye erróneamente el tiempo de inactividad. Para obtener información sobre cómo ajustar la base de datos cuando esta espera es destacada, consulte [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md).
**io/file/csv/data**
Los subprocesos escriben a las tablas con un formato de valores separados por comas (CSV). Compruebe el uso de tablas CSV. Una causa habitual de este evento es que se haya establecido `log_output` en una tabla.
**io/file/sql/binlog**
Un subproceso está esperando por un archivo de registro binario (binlog) que se está escribiendo en disco.
**io/redo\$1log\$1flush**
Una sesión está conservando datos en el almacenamiento de Aurora. Este evento de espera suele ser para una operación de E/S de escritura en Aurora MySQL. Para obtener más información, consulte [io/redo\$1log\$1flush](ams-waits.io-redologflush.md).
**io/socket/sql/client\$1connection**
El programa `mysqld` está ocupado creando subprocesos para gestionar las nuevas conexiones de clientes entrantes. Para obtener más información, consulte [io/socket/sql/client\$1connection](ams-waits.client-connection.md).
**io/table/sql/handler**
El motor está esperando el acceso a una tabla. Este evento se produce independientemente de si los datos se almacenan en caché en el grupo de búferes o si se accede en el disco. Para obtener más información, consulte [io/table/sql/handler](ams-waits.waitio.md).
**lock/table/sql/handler**
Este evento de espera es un controlador de evento de espera de bloqueo de tabla. Para obtener más información sobre los eventos de átomo y molécula del esquema de rendimiento, consulte [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html) en la documentación de MySQL.
**synch/cond/innodb/row\$1lock\$1wait**
Varias instrucciones de lenguaje de manipulación de datos (DML) acceden a las mismas filas de base de datos al mismo tiempo. Para obtener más información, consulte [synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md).
**synch/cond/innodb/row\$1lock\$1wait\$1cond**
Varias instrucciones DML acceden a las mismas filas de base de datos al mismo tiempo. Para obtener más información, consulte [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md).
**synch/cond/sql/MDL\$1context::COND\$1wait\$1status**
Los subprocesos están esperando por un bloqueo de metadatos de tabla. El motor utiliza este tipo de bloqueo para administrar el acceso simultáneo a un esquema de base de datos y garantizar la coherencia de los datos. Para obtener más información, consulte [Optimizing Locking Operations](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html) en la documentación de MySQL. Para obtener información sobre cómo ajustar la base de datos cuando este evento es destacado, consulte [synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md).
**synch/cond/sql/MYSQL\$1BIN\$1LOG::COND\$1done**
Ha activado el registro binario. Puede haber un alto rendimiento de confirmaciones, un gran número de transacciones que se comprometen o réplicas que leen binlogs. Considere utilizar instrucciones de varias filas o agrupar estados de cuenta en una transacción. En Aurora, utilice bases de datos globales en lugar de replicación de registros binarios o utilice los parámetros `aurora_binlog_*`.
**synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex**
Varias instrucciones DML acceden a las mismas filas de base de datos al mismo tiempo. Para obtener más información, consulte [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md).
**synch/mutex/innodb/buf\$1pool\$1mutex**
El grupo de búferes no es lo suficientemente grande como para almacenar el conjunto de datos de trabajo. O bien, la carga de trabajo accede a páginas de una tabla específica, lo que genera contención en el grupo de búferes. Para obtener más información, consulte [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md).
**synch/mutex/innodb/fil\$1system\$1mutex**
El proceso está esperando el acceso a la memoria caché de memoria del espacio de tabla. Para obtener más información, consulte [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md).
**synch/mutex/innodb/trx\$1sys\$1mutex**
Las operaciones comprueban, actualizan, eliminan o agregan ID de transacción en InnoDB de forma coherente o controlada. Estas operaciones requieren un llamada mutex de `trx_sys`, a la que se le realiza un seguimiento mediante la instrumentación Performance Schema. Las operaciones incluyen la administración del sistema de transacciones cuando se inicia o cierra la base de datos, reversiones, limpiezas de deshacer, acceso de lectura de filas y cargas de grupos de búfer. La carga elevada de la base de datos con un gran número de transacciones da como resultado la aparición frecuente de este evento de espera. Para obtener más información, consulte [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md).
**synch/mutex/mysys/KEY\$1CACHE::cache\$1lock**
El mutex de `keycache->cache_lock` controla el acceso a la caché de claves de las tablas MyISAM. Si bien Aurora MySQL no permite el uso de tablas MyISAM para almacenar datos persistentes, se utilizan para almacenar tablas temporales internas. Considere la posibilidad de comprobar los contadores con el estado `created_tmp_tables` o `created_tmp_disk_tables`, ya que, en determinadas situaciones, las tablas temporales se escriben en el disco cuando ya no caben en la memoria.
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1offsets**
El motor adquiere este mutex al abrir o crear un archivo de metadatos de tabla. Cuando este evento de espera se produce con una frecuencia excesiva, el número de tablas que se crean o abren ha aumentado.
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1shim\$1lists**
El motor adquiere este mutex mientras realiza operaciones tales como `reset_size`, `detach_contents`, o bien `add_contents` en la estructura interna que hace un seguimiento de las tablas abiertas. El mutex sincroniza el acceso al contenido de la lista. Cuando este evento de espera se produce con alta frecuencia, indica un cambio repentino en el conjunto de tablas a las que se había accedido anteriormente. El motor necesita acceder a tablas nuevas o dejar de lado el contexto relacionado con las tablas a las que se ha accedido anteriormente.
**synch/mutex/sql/LOCK\$1open**
El número de tablas que están abriendo las sesiones supera el tamaño de la caché de definiciones de tablas o de la caché abierta de tablas. Aumente el tamaño de estas cachés. Para obtener más información, consulte [How MySQL Opens and Closes Tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html).
**synch/mutex/sql/LOCK\$1table\$1cache**
El número de tablas que están abriendo las sesiones supera el tamaño de la caché de definiciones de tablas o de la caché abierta de tablas. Aumente el tamaño de estas cachés. Para obtener más información, consulte [How MySQL Opens and Closes Tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html).
**synch/mutex/sql/LOG**
En este evento de espera, hay subprocesos esperando por un bloqueo de log. Por ejemplo, un subproceso podría esperar a un bloqueo para escribir en el archivo log de consultas lentas.
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1commit**
En este evento de espera, hay un subproceso esperando a adquirir un bloqueo con la intención de efectuar una confirmación en el log binario. La contención de logs binarios se puede producir en las bases de datos cuya velocidad de cambio es muy alta. Según la versión de MySQL, hay algunos bloqueos que se utilizan para proteger la coherencia y durabilidad del log binario. En RDS for MySQL, los registros binarios se utilizan para la replicación y para el proceso de backup automatizado. En Aurora MySQL, los logs binarios no se necesitan para la replicación o las copias de seguridad nativas. Están deshabilitados de forma predeterminada, pero se pueden habilitar y utilizar para la replicación externa o la captura de datos de cambios. Para obtener más información, consulte [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) en la documentación de MySQL.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1dump\$1thread\$1metrics\$1collection**
Si el registro binario está activado, el motor adquiere este mutex cuando imprime métricas de subprocesos de volcado activos en el registro de errores del motor y en el mapa de operaciones interno.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1inactive\$1binlogs\$1map**
Si el registro binario está activado, el motor adquiere este mutex cuando agrega, elimina o busca en la lista de archivos binlog detrás del último.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1io\$1cache**
Si el registro binario está activado, el motor adquiere este mutex durante las operaciones de caché de E/S binlog de Aurora: asignar, cambiar el tamaño, liberar, escribir, leer, purgar y acceder a la información de la caché. Si este evento se produce con frecuencia, el motor accede a la caché donde se almacenan los eventos binlog. Para reducir los tiempos de espera, reduzca las confirmaciones. Intente agrupar varios estados de cuenta en una sola transacción.
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1log**
Ha activado el registro binario. Puede haber un alto rendimiento de confirmaciones, muchas transacciones que se comprometen o réplicas que leen binlogs. Considere utilizar instrucciones de varias filas o agrupar estados de cuenta en una transacción. En Aurora, utilice bases de datos globales en lugar de replicación de registros binarios o utilice los parámetros `aurora_binlog_*`.
**synch/mutex/sql/SERVER\$1THREAD::LOCK\$1sync**
El mutex `SERVER_THREAD::LOCK_sync` se adquiere durante la programación, el procesamiento o el lanzamiento de subprocesos para la escritura de archivos. La ocurrencia excesiva de este evento de espera indica una mayor actividad de escritura en la base de datos.
**synch/mutex/sql/TABLESPACES:lock**
El motor adquiere el mutex de `TABLESPACES:lock` durante las siguientes operaciones de espacio de tabla: crear, eliminar, truncar y extender. La ocurrencia excesiva de este evento de espera indica una alta frecuencia de operaciones de espacio de tabla. Un ejemplo es cargar una gran cantidad de datos en la base de datos.
**synch/rwlock/innodb/dict**
En este evento de espera, hay subprocesos esperando por un rwlock aplicado al diccionario de datos de InnoDB.
**synch/rwlock/innodb/dict\$1operation\$1lock**
En este evento de espera, hay subprocesos manteniendo bloqueos en operaciones del diccionario de datos de InnoDB.
**synch/rwlock/innodb/dict sys RW lock**
Al mismo tiempo se activan un gran número de declaraciones de lenguaje de control de datos (DCL) simultáneas en el código de lenguaje de definición de datos (DDL). Reduzca la dependencia de la aplicación de los DDL durante la actividad regular de la aplicación.
**synch/rwlock/innodb/index\$1tree\$1rw\$1lock**
Un gran número de instrucciones de lenguaje de manipulación de datos (DML) acceden al mismo objeto de base de datos al mismo tiempo. Intente usar instrucciones de varias filas. Además, distribuya la carga de trabajo sobre distintos objetos de base de datos. Por ejemplo, implementar particiones.
**synch/sxlock/innodb/dict\$1operation\$1lock**
Al mismo tiempo se activan un gran número de declaraciones de lenguaje de control de datos (DCL) simultáneas en el código de lenguaje de definición de datos (DDL). Reduzca la dependencia de la aplicación de los DDL durante la actividad regular de la aplicación.
**synch/sxlock/innodb/dict\$1sys\$1lock**
Al mismo tiempo se activan un gran número de declaraciones de lenguaje de control de datos (DCL) simultáneas en el código de lenguaje de definición de datos (DDL). Reduzca la dependencia de la aplicación de los DDL durante la actividad regular de la aplicación.
**synch/sxlock/innodb/hash\$1table\$1locks**
La sesión no ha encontrado páginas del grupo de búferes. El motor necesita leer un archivo o modificar la lista menos usada recientemente (LRU) para el grupo de búferes. Considere aumentar el tamaño de la caché del búfer y mejorar las rutas de acceso para las consultas pertinentes.
**synch/sxlock/innodb/index\$1tree\$1rw\$1lock**
Muchas instrucciones de lenguaje de manipulación de datos (DML) acceden al mismo objeto de base de datos al mismo tiempo. Intente usar instrucciones de varias filas. Además, distribuya la carga de trabajo sobre distintos objetos de base de datos. Por ejemplo, implementar particiones.
**synch/mutex/innodb/temp\$1pool\$1manager\$1mutex**
Este evento de espera se produce cuando una sesión está esperando para adquirir un mutex para administrar el grupo de espacios de tablas temporales de sesión.
Para obtener más información la solución de problemas de los eventos de espera de sincronización, consulte [¿Por qué mi instancia de base de datos MySQL muestra un gran número de sesiones activas esperando en eventos de espera SYNCH en Performance Insights?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/).
# Estados del subproceso Aurora MySQL
Los siguientes son algunos estados de subproceso frecuentes de Aurora MySQL.
**checking permissions**
El subproceso comprueba si el servidor tiene los privilegios necesarios para ejecutar la instrucción.
**checking query cache for query**
El servidor comprueba si la consulta actual está presente en la caché de consultas.
**cleaned up**
Este es el estado final de una conexión cuyo trabajo está completo pero que el cliente no ha cerrado. La mejor solución es cerrar explícitamente la conexión en código. O bien, puede establecer un valor inferior para `wait_timeout` en el grupo de parámetros.
**closing tables**
El subproceso está vaciando los datos de la tabla modificados en disco y cerrando las tablas usadas. Si no se trata de una operación rápida, verifique las métricas de consumo de ancho de banda de red con respecto al ancho de banda de red de clase de instancia. Además, verifique que los valores de los parámetros de `table_open_cache` y `table_definition_cache` permiten abrir simultáneamente suficientes tablas para que el motor no tenga que abrir y cerrar tablas con frecuencia. Estos parámetros influyen en el consumo de memoria de la instancia.
**converting HEAP to MyISAM**
La consulta está convirtiendo una tabla temporal de en memoria a en disco. Esta conversión es necesaria porque las tablas temporales creadas por MySQL en los pasos intermedios del procesamiento de consultas crecieron demasiado grandes para la memoria. Verifique los valores de `tmp_table_size` y `max_heap_table_size`. En versiones posteriores, el nombre del estado de este subproceso es `converting HEAP to ondisk`.
**converting HEAP to ondisk**
El subproceso está convirtiendo una tabla temporal interna de una tabla en memoria a una tabla en disco.
**copy to tmp table**
El subproceso está procesando una instrucción `ALTER TABLE`. Este estado se produce después de crear la tabla con la nueva estructura, pero antes de copiar las filas en ella. Para un subproceso en este estado, puede utilizar el esquema de rendimiento para obtener información sobre el progreso de la operación de copia.
**crear índice de ordenación**
Aurora MySQL está realizando una ordenación porque no puede utilizar un índice existente para satisfacer la cláusula `ORDER BY` o `GROUP BY` de una consulta. Para obtener más información, consulte [crear índice de ordenación](ams-states.sort-index.md).
**creación de tablas**
El subproceso está creando una tabla permanente o temporal.
**delayed commit ok done**
Una confirmación asíncrona en Aurora MySQL ha recibido un acuse de recibo y se ha completado.
**delayed commit ok initiated**
El subproceso de Aurora MySQL ha iniciado el proceso de confirmación asíncrona, pero está a la espera de confirmación. Por lo general, es el tiempo de confirmación genuino de una transacción.
**delayed send ok done**
Un subproceso de trabajo de Aurora MySQL vinculado a una conexión se puede liberar mientras se envía una respuesta al cliente. El subproceso puede comenzar otro trabajo. El estado `delayed send ok` significa que se ha completado el acuse de recibo asíncrono al cliente.
**delayed send ok initiated**
Un subproceso de trabajo de Aurora MySQL ha enviado una respuesta asíncrona a un cliente y ahora es libre de trabajar para otras conexiones. La transacción ha iniciado un proceso de confirmación asíncrono que aún no se ha confirmado.
**executing**
El subproceso ha comenzado a ejecutar una instrucción.
**freeing items**
El subproceso ha ejecutado un comando. Parte de la liberación de elementos realizada durante este estado implica la caché de consultas. Este estado suele ir seguido de una limpieza.
**init**
Este estado se produce antes de la inicialización de las instrucciones `ALTER TABLE`, `DELETE`, `INSERT`, `SELECT`, o bien `UPDATE`. Las acciones en este estado incluyen vaciar el registro binario o el registro InnoDB y una limpieza de la caché de consultas.
**El origen ha enviado todo el binlog a la réplica; esperando más actualizaciones**
El nodo principal ha finalizado su parte de la replicación. El subproceso está esperando que se ejecuten más consultas para poder escribir en el registro binario (binlog).
**opening tables**
El subproceso intenta abrir una tabla. Esta operación es rápida a menos que un `ALTER TABLE` o una instrucción `LOCK TABLE` tenga que finalizar o supera el valor de `table_open_cache`.
**optimizing**
El servidor está realizando optimizaciones iniciales para una consulta.
**preparing**
Este estado se produce durante la optimización de consultas.
**query end**
Este estado se produce después de procesar una consulta, pero antes del estado de liberación de elementos.
**removing duplicates**
Aurora MySQL no pudo optimizar una operación `DISTINCT` en la fase inicial de una consulta. Aurora MySQL debe eliminar todas las filas duplicadas antes de enviar el resultado al cliente.
**searching rows for update**
El subproceso encuentra todas las filas coincidentes antes de actualizarlas. Esta etapa es necesaria si el `UPDATE` está cambiando el índice que utiliza el motor para buscar las filas.
**sending binlog event to slave**
El subproceso lee un evento del registro binario y lo envía a la réplica.
**sending cached result to client**
El servidor está tomando el resultado de una consulta de la caché de consultas y lo envía al cliente.
**envío de datos**
El subproceso está leyendo y procesando filas para una instrucción `SELECT`, pero aún no ha comenzado a enviar datos al cliente. El proceso identifica qué páginas contienen los resultados necesarios para satisfacer la consulta. Para obtener más información, consulte [envío de datos](ams-states.sending-data.md).
**sending to client**
El servidor está escribiendo un paquete para el cliente. En versiones anteriores de MySQL, este evento de espera estaba etiquetado `writing to net`.
**starting**
Esta es la primera etapa al comienzo de la ejecución de la declaración.
**statistics**
El servidor está calculando estadísticas para desarrollar un plan de ejecución de consultas. Si un subproceso está en este estado durante mucho tiempo, es probable que el servidor esté vinculado al disco mientras realiza otro trabajo.
**storing result in query cache**
El servidor almacena el resultado de una consulta en la caché de consultas.
**system lock**
El subproceso ha llamado a `mysql_lock_tables`, pero el estado del subproceso no se ha actualizado desde la llamada. Este estado general se produce por muchas razones.
**actualización**
El subproceso se está preparando para comenzar a actualizar la tabla.
**updating**
El subproceso busca filas y las está actualizando.
**user lock**
El subproceso emitió una llamada a `GET_LOCK`. El subproceso solicitó un bloqueo de aviso y lo está esperando, o planea solicitarlo.
**waiting for more updates**
El nodo principal ha finalizado su parte de la replicación. El subproceso está esperando que se ejecuten más consultas para poder escribir en el registro binario (binlog).
**waiting for schema metadata lock**
Es una espera para bloquear metadatos.
**waiting for stored function metadata lock**
Es una espera para bloquear metadatos.
**waiting for stored procedure metadata lock**
Es una espera para bloquear metadatos.
**waiting for table flush**
El subproceso está ejecutando `FLUSH TABLES` y está esperando a que todos los subprocesos cierren sus tablas. O el subproceso recibió una notificación de que la estructura subyacente de una tabla ha cambiado, por lo que debe volver a abrir la tabla para obtener la nueva estructura. Para volver a abrir la tabla, el subproceso debe esperar hasta que todos los demás subprocesos hayan cerrado la tabla. Esta notificación se lleva a cabo si otro subproceso ha utilizado una de las siguientes instrucciones de la tabla: `FLUSH TABLES`, `ALTER TABLE`, `RENAME TABLE`, `REPAIR TABLE`, `ANALYZE TABLE`, o bien `OPTIMIZE TABLE`.
**waiting for table level lock**
Una sesión mantiene un bloqueo en una tabla mientras otra intenta adquirir el mismo bloqueo en la misma tabla.
**waiting for table metadata lock**
Aurora MySQL utiliza el bloqueo de metadatos para administrar el acceso simultáneo a los objetos de base de datos y garantizar la coherencia de los datos. En este evento de espera, una sesión mantiene un bloqueo de metadatos en una tabla mientras otra sesión intenta adquirir el mismo bloqueo en la misma tabla. Cuando Performance Schema está habilitado, este estado de subproceso se informa como evento de espera `synch/cond/sql/MDL_context::COND_wait_status`.
**writing to net**
El servidor está escribiendo un paquete para la red. En versiones posteriores de MySQL, este evento de espera está etiquetado `Sending to client`.
# Niveles de aislamiento de Aurora MySQL
Aprenda cómo las instancias de base de datos en un clúster de Aurora MySQL implementan la propiedad de aislamiento de la base de datos. Este tema le ayuda a comprender cómo el comportamiento predeterminado de Aurora MySQL encuentra un equilibrio entre la consistencia estricta y el alto rendimiento. Puede utilizar esta información para decidir cuándo cambiar la configuración predeterminada en función de las características de su carga de trabajo.
## Niveles de aislamiento disponibles para las instancias de escrituras
Puede utilizar los niveles de aislamiento `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITTED` y `SERIALIZABLE` en la instancia principal de un clúster de base de datos de Aurora MySQL. Estos niveles de aislamiento funcionan de la misma manera en Aurora MySQL que en RDS for MySQL.
## Nivel de aislamiento REPEATABLE READ para las instancias del lector
De manera predeterminada, las instancias de base de datos de Aurora MySQL que están configuradas como réplicas de Aurora de solo lectura siempre utilizan el nivel de aislamiento `REPEATABLE READ`. Estas instancias de base de datos ignoran cualquier instrucción `SET TRANSACTION ISOLATION LEVEL` y continúan utilizando el nivel de aislamiento `REPEATABLE READ`.
## Nivel de aislamiento READ COMMITTED para las instancias del lector
Si su aplicación incluye una carga de trabajo de escritura intensiva en la instancia principal y solicitudes de larga ejecución en las réplicas de Aurora, puede experimentar lag de purgado considerable. *El lag de purgado* se produce cuando la recogida de elementos no utilizados interna se bloquea debido a consultas de ejecución prolongada. El síntoma que ve es un valor alto para `history list length` en el resultado del comando `SHOW ENGINE INNODB STATUS`. Puede supervisar este valor utilizando la métrica `RollbackSegmentHistoryListLength` en CloudWatch. Un lag de purgado considerable puede reducir la eficacia de los índices secundarios, disminuir el rendimiento general de las consultas y provocar un desperdicio de espacio de almacenamiento.
Si experimenta esos problemas, puede utilizar una opción de configuración de nivel de sesión de Aurora MySQL, `aurora_read_replica_read_committed`, para utilizar el nivel de aislamiento de `READ COMMITTED` en réplicas de Aurora. Cuando utilice esta configuración, puede ayudar a reducir las ralentizaciones y el espacio desaprovechado que pueda derivarse de la realización de consultas de ejecución prolongada al mismo tiempo que las transacciones que modifican sus tablas.
Recomendamos que se asegure de que comprende el comportamiento específico de Aurora MySQL del aislamiento `READ COMMITTED` antes de utilizar esta configuración. La réplica de Aurora del comportamiento de `READ COMMITTED` cumple con el estándar ANSI SQL. Sin embargo, el aislamiento es menos estricto que el comportamiento `READ COMMITTED` de MySQL típico con el que puede que esté más familiarizado. Por lo tanto, puede ser que vea resultados de consultas diferentes en `READ COMMITTED` en una réplica de lectura de Aurora MySQL que para la misma consulta en `READ COMMITTED` en la instancia principal de Aurora MySQL o en RDS para MySQL. Puede considerar utilizar la configuración de `aurora_read_replica_read_committed` para esos casos de uso como un informe completo que analiza una base de datos muy grande. Por el contrario, puede evitarla para consultas breves con conjuntos de resultados pequeños, donde la precisión y la repetibilidad son importantes.
El nivel de aislamiento `READ COMMITTED` no está disponible para las sesiones de un clúster secundario de una base de datos global de Aurora que utilicen la función de reenvío de escritura. Para obtener información sobre el reenvío de escritura, consulte [Uso del reenvío de escritura en una base de datos Amazon Aurora global](aurora-global-database-write-forwarding.md).
### Uso de READ COMMITTED para lectores
Para utilizar el nivel de aislamiento `READ COMMITTED` para las réplicas de Aurora, establezca la opción de configuración `aurora_read_replica_read_committed` en `ON`. Utilice esta configuración en el nivel de sesión mientras esté conectado a una réplica de Aurora específica. Para ello, ejecute los comandos de SQL siguientes.
```
set session aurora_read_replica_read_committed = ON;
set session transaction isolation level read committed;
```
Puede utilizar esta opción de configuración de manera temporal para realizar consultas ad hoc únicas e interactivas. Puede que también desee ejecutar una aplicación de informes o de análisis de datos que se beneficie del nivel de aislamiento `READ COMMITTED`, mientras deja el predeterminado sin cambiar para otras aplicaciones.
Cuando la configuración `aurora_read_replica_read_committed` está activada, utilice el comando `SET TRANSACTION ISOLATION LEVEL` para especificar el nivel de aislamiento para las transacciones adecuadas.
```
set transaction isolation level read committed;
```
### Diferencias en el comportamiento READ COMMITTED en las réplicas de Aurora
La configuración `aurora_read_replica_read_committed` hace que el nivel de aislamiento `READ COMMITTED` esté disponible para una réplica de Aurora, con un comportamiento de consistencia que está optimizado para las transacciones de ejecución prolongada. El nivel de aislamiento `READ COMMITTED` en las réplicas de Aurora tiene un aislamiento menos estricto que en las instancias principales de Aurora. Por ese motivo, habilite esta configuración solo en las réplicas de Aurora en las que sabe que sus consultas pueden aceptar la posibilidad de ciertos tipos de resultados inconsistentes.
Sus consultas pueden experimentar ciertos tipos de anomalías de lectura cuando se enciende la configuración `aurora_read_replica_read_committed`. Dos tipos de anomalías son especialmente importantes para entender y manejar su código de aplicación. Una *lectura no repetible* se produce cuando otra transacción se confirma mientras su consulta está en ejecución. Una consulta de ejecución prolongada puede ver diferentes datos al principio de la consulta que los que ve al final. Una *lectura fantasma* se produce cuando otras transacciones hacen que las filas existentes se reorganicen mientras su consulta se ejecuta y su consulta lee dos veces una o más filas.
Sus consultas pueden experimentar recuentos de filas inconsistentes como resultado de las lecturas fantasmas. Puede que sus consultas también devuelvan resultados incompletos o inconsistentes debido a las lecturas no repetibles. Por ejemplo, suponga que una operación conjunta hace referencia a tablas que las instrucciones SQL modifican de forma simultánea como `INSERT` o `DELETE`. En este caso, la consulta conjunta puede leer una fila de una tabla pero no la fila correspondiente de otra tabla.
El estándar ANSI SQL permite a estos comportamientos el nivel de aislamiento `READ COMMITTED`. Sin embargo, estos comportamientos son diferentes de la implementación típica de MySQL de `READ COMMITTED`. Por lo tanto, antes de habilitar la configuración `aurora_read_replica_read_committed`, compruebe cualquier código existente de SQL para verificar si opera según lo esperado en el modelo de consistencia secundario.
Puede que los recuentos de filas y otros resultados no sean altamente consistentes en el nivel de aislamiento `READ COMMITTED` mientras se habilita este nivel de aislamiento. Por lo tanto, típicamente habilita la configuración solo mientras ejecuta consultas analíticas que agregan grandes cantidades de datos y no precisan una precisión absoluta. SI no tiene estos tipos de consultas de ejecución prolongada junto a una carga de trabajo de escritura intensiva, probablemente no necesite la configuración `aurora_read_replica_read_committed`. Sin la combinación de solicitudes de ejecución prolongada y una carga de trabajo de escritura intensiva, no es probable que tenga problemas con extensión de la lista del historial.
**Example Consultas que muestran un comportamiento de aislamiento para READ COMMITTED en las réplicas de Aurora**
El siguiente ejemplo le muestra cómo las consultas `READ COMMITTED` en una réplica de Aurora puede devolver resultados no repetibles si las transacciones modifican las tablas asociadas al mismo tiempo. La tabla `BIG_TABLE` contiene 1 millón de filas antes de que comience cualquier consulta. Otras instrucciones del lenguaje de manipulación de datos (DML) añaden, eliminan o cambian filas mientras se ejecutan.
Las consultas en la instancia principal de Aurora en el nivel de aislamiento `READ COMMITTED` producen resultados predecibles. Sin embargo, la sobrecarga de mantener la vista de lectura consistente durante la vida útil de cada consulta de ejecución prolongada puede llevar a una recopilación de elementos no utilizados cara más adelante.
Las consultas en la réplica de Aurora en el nivel de aislamiento `READ COMMITTED` se optimizan para minimizar esta sobrecarga de recopilación de elementos no utilizados. La desventaja es que los resultados pueden variar dependiendo de si las consultas recuperan filas que se han añadido, eliminado o reorganizado por transacciones que se confirman cuando la consulta se ejecuta. Las consultas pueden tener en cuenta estas filas pero no están obligadas a ello. Para fines demostrativos, las consultas comprueban solo el número de filas en la tabla utilizando la función `COUNT(*)`.
| Time | Instrucción DML en la instancia principal de Aurora | Consulta en la instancia principal de Aurora con READ COMMITTED | Consulta en la réplica de Aurora con READ COMMITTED |
| --- | --- | --- | --- |
| T1 | INSERT INTO big\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | |
| T2 | | C1: SELECT COUNT(\$1) FROM big\$1table; | C2: SELECT COUNT(\$1) FROM big\$1table; |
| T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | |
| T4 | | Si C1 termina ahora, el resultado es 1 000 000. | Si C2 termina ahora, el resultado es 1 000 000 o 1 000 001. |
| T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | |
| T6 | | Si C1 termina ahora, el resultado es 1 000 000. | Si C2 termina ahora, el resultado es 1 000 000 o 1 000 001, o 999 999 o 999 998. |
| T7 | UPDATE big\$1table SET c2 = CONCAT(c2,c2,c2); COMMIT; | | |
| T8 | | Si C1 termina ahora, el resultado es 1 000 000. | Si C2 termina ahora, el resultado es 1 000 000 o 1 000 001, o 999 999 o posiblemente algún número mayor. |
| T9 | | C3: SELECT COUNT(\$1) FROM big\$1table; | C4: SELECT COUNT(\$1) FROM big\$1table; |
| T10 | | Si C3 termina ahora, el resultado es 999 999. | Si C4 termina ahora, el resultado es 999 999. |
| T11 | | C5: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | C6: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; |
| T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (id, s) VALUES (1000, 'world'); COMMIT; | | |
| T13 | | Si C5 termina ahora, el resultado es 0. | Si C6 termina ahora, el resultado es 0 o 1. |
Si las consultas terminan rápidamente, antes de que cualquier otra transacción realice instrucciones DML y los envíe, los resultados son predecibles y lo mismo ocurre entre la instancia primaria y la réplica de Aurora. Examinemos las diferencias de comportamiento en detalle, empezando por la primera consulta.
Los resultados para C1 son muy predecibles, ya que `READ COMMITTED` en la instancia principal utiliza un modelo de coherencia alta similar al del nivel de aislamiento `REPEATABLE READ`.
Los resultados para C2 puede variar dependiendo de las transacciones que se confirman mientras esa consulta se ejecuta. Por ejemplo, suponga que otras transacciones realizan instrucciones DML y las confirman mientras las consultas se ejecutan. En este caso, la consulta en la réplica de Aurora con el nivel de aislamiento `READ COMMITTED` puede o no tener en cuenta los cambios, Los recuentos de filas no se pueden predecir de la misma manera que en el nivel de aislamiento `REPEATABLE READ`. Tampoco se pueden predecir como consultas que se ejecutan en el nivel de aislamiento `READ COMMITTED` en la instancia principal o en una instancia de RDS for MySQL.
El estándar `UPDATE` en T7 no cambia en realidad el número de filas en la tabla. Sin embargo, al cambiar la extensión de una columna de extensión variable, esta instrucción puede hacer que las filas se reorganicen de manera interna. Una transacción `READ COMMITTED` de ejecución prolongada puede observar la versión antigua de una fila y más adelante, en la misma consulta, observar la nueva versión de la misma fila. La consulta también puede omitir las versiones nueva y antigua de la fila, por lo que el recuento de filas puede ser diferente de lo esperado.
Los resultados de C5 y C6 pueden ser idénticos o ligeramente diferentes. La consulta C6 en la réplica de Aurora en `READ COMMITTED` puede observar, pero no está obligada a ello, las filas nuevas se confirman mientras que la consulta se ejecuta. También podría ver la fila de una tabla, pero no la de la otra. Si la consulta conjunta no encuentra una fila que coincida en ambas tablas, devuelve un recuento de cero. Si la consulta encuentra las dos filas en `PARENT_TABLE` y `CHILD_TABLE`, la consulta devuelve un recuento de uno. En una consulta de ejecución prolongada, las búsquedas de las tablas combinadas puede producirse en momentos muy separados.
Estas diferencias de comportamiento depende del momento en el que se confirmen las transacciones y el momento en el que las consultas procesan las filas subyacentes de la tabla. Por lo tanto, es muy probable que vea esas diferencias en consultas de informes que tardan minutos u horas y que se ejecutan en clústeres de Aurora que procesan transacciones de OLTP al mismo tiempo. Estos son los tipos de cargas de trabajo mixtas que más se benefician del nivel de aislamiento `READ COMMITTED` en las réplicas de Aurora.
# Sugerencias de Aurora MySQL
Puede utilizar consejos de SQL con consultas de Aurora MySQL para ajustar el rendimiento. También puede utilizar sugerencias para evitar que los planes de ejecución de consultas importantes cambien en función de condiciones impredecibles.
**sugerencia**
Para comprobar el efecto que tiene una sugerencia en una consulta, examine el plan de consulta producido por la instrucción `EXPLAIN`. Compare los planes de consulta con y sin la sugerencia.
En Aurora MySQL versión 3, puede utilizar todas las sugerencias disponibles en MySQL Community Edition 8.0. Para obtener detalles sobre estas sugerencias, consulte [Optimizer Hints](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) (Sugerencias del optimizador) en el *Manual de referencia de MySQL*.
Las siguientes sugerencias están disponibles en Aurora MySQL versión 2. Estas sugerencias se aplican a consultas que utilizan la característica de combinación hash de Aurora MySQL versión 2, especialmente a consultas que utilizan la optimización de consultas paralelas.
**PQ, NO\$1PQ**
Especifica si se debe obligar al optimizador a utilizar consultas paralelas por tabla o por consulta.
`PQ` obliga al optimizador a utilizar una consulta paralela para las tablas especificadas o para toda la consulta (bloque). `NO_PQ` impide que el optimizador utilice consultas paralelas para tablas especificadas o para toda la consulta (bloque).
Esta sugerencia está disponible en Aurora MySQL 2.11 y versiones posteriores. En los siguientes ejemplos se muestra cómo usar esta sugerencia.
Al especificar un nombre de tabla, el optimizador se ve obligado a aplicar la sugerencia `PQ/NO_PQ` solo en las tablas seleccionadas. Si no se especifica un nombre de tabla, se aplicará la sugerencia `PQ/NO_PQ` a todas las tablas afectadas por el bloque de consulta.
```
EXPLAIN SELECT /*+ PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
EXPLAIN SELECT /*+ NO_PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
```
**HASH\$1JOIN, NO\$1HASH\$1JOIN**
Activa o desactiva la capacidad del optimizador de consultas paralelas de elegir si desea usar el método de optimización de combinación hash para una consulta. `HASH_JOIN` permite al optimizador usar la combinación hash si ese mecanismo es más eficiente. `NO_HASH_JOIN` impide que el optimizador utilice la combinación hash para la consulta. Esta sugerencia está disponible en Aurora MySQL versión 2.08 y versiones posteriores. No tiene efecto en Aurora MySQL versión 3.
En los siguientes ejemplos se muestra cómo usar esta sugerencia.
```
EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1JOIN\$1PROBING, NO\$1HASH\$1JOIN\$1PROBING**
En una consulta de combinación hash, especifica si se va a utilizar la tabla especificada para el lado de sondeo de la combinación. La consulta comprueba si los valores de columna de la tabla de compilación existen en la tabla de sondeo, en lugar de leer todo el contenido de la tabla de sondeo. Puede utilizar `HASH_JOIN_PROBING` y `HASH_JOIN_BUILDING` para especificar cómo se procesan las consultas de combinación hash sin reordenar las tablas dentro del texto de la consulta. Esta sugerencia está disponible en Aurora MySQL versión 2.08 y versiones posteriores. No tiene efecto en Aurora MySQL versión 3.
En los siguientes ejemplos se muestra cómo usar esta sugerencia. Especificar la sugerencia `HASH_JOIN_PROBING` para la tabla `T2` tiene el mismo efecto que especificar `NO_HASH_JOIN_PROBING` para la tabla `T1`.
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1JOIN\$1BUILDING, NO\$1HASH\$1JOIN\$1BUILDING**
En una consulta de combinación hash, especifica si se va a utilizar la tabla especificada para el lado de compilación de la combinación. La consulta procesa todas las filas de esta tabla para crear la lista de valores de columna para hacer referencia cruzada con la otra tabla. Puede utilizar `HASH_JOIN_PROBING` y `HASH_JOIN_BUILDING` para especificar cómo se procesan las consultas de combinación hash sin reordenar las tablas dentro del texto de la consulta. Esta sugerencia está disponible en Aurora MySQL versión 2.08 y versiones posteriores. No tiene efecto en Aurora MySQL versión 3.
En el siguiente ejemplo se muestra cómo usar esta sugerencia. Especificar la sugerencia `HASH_JOIN_BUILDING` para la tabla `T2` tiene el mismo efecto que especificar `NO_HASH_JOIN_BUILDING` para la tabla `T1`.
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**JOIN\$1FIXED\$1ORDER**
Especifica que las tablas de la consulta se unen en función del orden en que aparecen en la consulta. Es útil con consultas que afectan a tres o más tablas. Sirve de reemplazo para la sugerencia de MySQL `STRAIGHT_JOIN` y es equivalente a la sugerencia de MySQL[JOIN\$1FIXED\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Esta sugerencia está disponible en Aurora MySQL versión 2.08 y versiones posteriores.
En el siguiente ejemplo se muestra cómo usar esta sugerencia.
```
EXPLAIN SELECT /*+ JOIN_FIXED_ORDER() */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1ORDER**
Especifica el orden de combinación de las tablas de la consulta. Es útil con consultas que afectan a tres o más tablas. Es equivalente a la sugerencia de MySQL [JOIN\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Esta sugerencia está disponible en Aurora MySQL versión 2.08 y versiones posteriores.
En el siguiente ejemplo se muestra cómo usar esta sugerencia.
```
EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1PREFIX**
Especifica las tablas que se van a poner primero en el orden de combinación. Es útil con consultas que afectan a tres o más tablas. Es equivalente a la sugerencia de MySQL [JOIN\$1PREFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Esta sugerencia está disponible en Aurora MySQL versión 2.08 y versiones posteriores.
En el siguiente ejemplo se muestra cómo usar esta sugerencia.
```
EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1SUFFIX**
Especifica las tablas que se van a poner en último lugar en el orden de combinación. Es útil con consultas que afectan a tres o más tablas. Es equivalente a la sugerencia de MySQL [JOIN\$1SUFFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Esta sugerencia está disponible en Aurora MySQL versión 2.08 y versiones posteriores.
En el siguiente ejemplo se muestra cómo usar esta sugerencia.
```
EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
Para obtener información sobre el uso de consultas de combinación hash, consulte [Optimización de grandes consultas combinadas de Aurora MySQL con combinaciones hash](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin).
# Referencia de procedimientos almacenados en Aurora MySQL
Para administrar el clúster de base de datos de Aurora MySQL, invoque los procedimientos almacenados integrados.
**Topics**
+ [Recopilación y mantenimiento del historial de estado global](mysql-stored-proc-gsh.md)
+ [Configuración, inicio y detención de la replicación del registro binario (binlog)](mysql-stored-proc-replicating.md)
+ [Finalización de una sesión o una consulta](mysql-stored-proc-ending.md)
+ [Replicación de transacciones mediante GTID](mysql-stored-proc-gtid.md)
+ [Rotación de los registros de consultas](mysql-stored-proc-logging.md)
+ [Establecimiento y muestra de la configuración del registro binario](mysql-stored-proc-configuring.md)
# Recopilación y mantenimiento del historial de estado global
Amazon RDS proporciona un conjunto de procedimientos que crean instantáneas de los valores de las variables de estado a lo largo del tiempo y los escriben en una tabla, junto con cualquier cambio desde la última instantánea. Esta infraestructura se denomina Historial de estado global. Para obtener más información, consulte [Managing the Global Status History](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH) (Administrar el historial de estado global).
Los siguientes procedimientos almacenados administran la forma en que se recopila y mantiene el historial de estado global.
**Topics**
+ [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history)
+ [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector)
+ [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation)
+ [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector)
+ [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation)
+ [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history)
+ [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector)
+ [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
Toma una instantánea bajo demanda para el historial de estado global.
### Sintaxis
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
Desactiva las instantáneas tomadas por el historial de estado global.
### Sintaxis
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
Desactiva la rotación de la tabla `mysql.global_status_history`.
### Sintaxis
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
Activa el historial de estado global para tomar instantáneas predeterminadas a los intervalos especificados por `rds_set_gsh_collector`.
### Sintaxis
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
Activa la rotación del contenido de la tabla `mysql.global_status_history` a `mysql.global_status_history_old` a los intervalos especificados por `rds_set_gsh_rotation`.
### Sintaxis
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
Rota el contenido de la tabla `mysql.global_status_history` a `mysql.global_status_history_old` a petición.
### Sintaxis
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
Especifica el intervalo, en minutos, entre las instantáneas tomadas por el historial de estado global.
### Sintaxis
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### Parámetros
*intervalPeriod*
El intervalo, en minutos, entre snapshots. El valor predeterminado es `5`.
## mysql.rds\$1set\$1gsh\$1rotation
Especifica el intervalo, en días, entre rotaciones de la tabla `mysql.global_status_history`.
### Sintaxis
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### Parámetros
*intervalPeriod*
El intervalo, en días, entre rotaciones de la tabla. El valor predeterminado es `7`.
# Configuración, inicio y detención de la replicación del registro binario (binlog)
Puede invocar los siguientes procedimientos almacenados cuando esté conectado a la instancia principal en un clúster de Aurora MySQL. Estos procedimientos controlan la forma en la que se replican las transacciones desde una base de datos externa en Aurora MySQL o desde Aurora MySQL a una base de datos externa.
**Topics**
+ [mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versión 2)](#mysql_rds_disable_session_binlog)
+ [mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versión 2)](#mysql_rds_enable_session_binlog)
+ [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)
+ [mysql.rds\$1next\$1master\$1log (Aurora MySQL versión 2)](#mysql_rds_next_master_log)
+ [mysql.rds\$1next\$1source\$1log (Aurora MySQL versión 3)](#mysql_rds_next_source_log)
+ [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material)
+ [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versión 2)](#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versión 3)](#mysql_rds_reset_external_source)
+ [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versión 3)](#mysql_rds_set_binlog_source_ssl)
+ [mysql.rds\$1set\$1external\$1master (Aurora MySQL versión 2)](#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (Aurora MySQL versión 3)](#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versión 2)](#mysql_rds_set_external_master_with_auto_position)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versión 3)](#mysql_rds_set_external_source_with_auto_position)
+ [mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL versión 2)](#mysql_rds_set_master_auto_position)
+ [mysql.rds\$1set\$1read\$1only (Aurora MySQL versión 3)](#mysql_rds_set_read_only)
+ [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versión 2)](#mysql_rds_set_session_binlog_format)
+ [mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL versión 3)](#mysql_rds_set_source_auto_position)
+ [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error)
+ [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)
+ [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versión 3)](#mysql_rds_start_replication_until)
+ [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versión 2)
Desactiva el registro binario de la sesión actual mediante la configuración de la variable `sql_log_bin` a `OFF`.
### Sintaxis
```
CALL mysql.rds_disable_session_binlog;
```
### Parameters
Ninguno
### Notas de uso
Para un clúster de bases de datos de Aurora MySQL, puede invocar este procedimiento almacenado cuando esté conectado a la instancia principal.
Para Aurora, este procedimiento se admite en la versión 2.12 de Aurora MySQL y versiones posteriores compatibles con MySQL 5.7.
**nota**
En la versión 3 de Aurora MySQL, puede usar el siguiente comando para deshabilitar el registro binario de la sesión actual si tiene el privilegio:`SESSION_VARIABLES_ADMIN`
```
SET SESSION sql_log_bin = OFF;
```
## mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versión 2)
Activa el registro binario de la sesión actual mediante la configuración de la variable `sql_log_bin` a `ON`.
### Sintaxis
```
CALL mysql.rds_enable_session_binlog;
```
### Parameters
Ninguno
### Notas de uso
Para un clúster de bases de datos de Aurora MySQL, puede invocar este procedimiento almacenado cuando esté conectado a la instancia principal.
Para Aurora, este procedimiento se admite en la versión 2.12 de Aurora MySQL y versiones posteriores compatibles con MySQL 5.7.
**nota**
En la versión 3 de Aurora MySQL, puede usar el siguiente comando para habilitar el registro binario de la sesión actual si tiene el privilegio:`SESSION_VARIABLES_ADMIN`
```
SET SESSION sql_log_bin = ON;
```
## mysql.rds\$1import\$1binlog\$1ssl\$1material
Importa el certificado de la entidad de certificación, el certificado de cliente y la clave de cliente a un clúster de base de datos de Aurora MySQL. La información es necesaria para la comunicación SSL y la replicación cifrada.
**nota**
Actualmente, este procedimiento es compatible con la versión 2: 2.09.2, 2.10.0, 2.10.1 y 2.11.0; y la versión 3: 3.01.1 y posteriores de Aurora MySQL.
### Sintaxis
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### Parámetros
*ssl\$1material*
Carga JSON que incluye el contenido de los siguientes archivos con formato .pem para un cliente MySQL:
+ "ssl\$1ca":"*certificado de la entidad de certificación*"
+ "ssl\$1cert":"*certificado cliente*"
+ "ssl\$1key":"*clave cliente*"
### Notas de uso
Prepare la replicación cifrada antes de ejecutar este procedimiento:
+ Si no tiene SSL habilitado en la instancia de base de datos de origen MySQL externa y no dispone de una clave cliente ni de un certificado cliente, habilite SSL en el servidor de base de datos de MySQL y genere la clave cliente y el certificado cliente necesarios.
+ Si SSL está habilitado en la instancia de base de datos de origen externa, proporcione una clave cliente y un certificado cliente para el clúster de base de datos de Aurora MySQL. Si no los tiene, genere una nueva clave y certificado para el clúster de base de datos Aurora MySQL. Para firmar el certificado cliente, debe tener la clave de la entidad de certificación que usó para configurar SSL en la instancia de base de datos de origen MySQL externa.
Para obtener más información, consulte [Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) en la documentación de MySQL.
**importante**
Después de preparar la replicación cifrada, use una conexión SSL para ejecutar este procedimiento. La clave cliente no se debe transferir en una conexión que no sea segura.
Este procedimiento importa la información de SSL de una base de datos MySQL externa a un clúster de base de datos Aurora MySQL. La información de SSL está en archivos con formato .pem que contienen la información de SSL del clúster de base de datos Aurora MySQL. Durante la replicación cifrada, el clúster de base de datos Aurora MySQL actúa como un cliente en el servidor de base de datos MySQL. Los certificados y las claves del cliente de Aurora MySQL son archivos con formato .pem.
Puede copiar la información de estos archivos en el parámetro `ssl_material` en la carga JSON correcta. Para permitir la replicación cifrada, importe esta información de SSL en el clúster de base de datos Aurora MySQL.
La carga JSON debe tener el siguiente formato.
```
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
ssl_ca_pem_body_code
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
ssl_cert_pem_body_code
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
ssl_key_pem_body_code
-----END RSA PRIVATE KEY-----\n"}'
```
### Ejemplos
En el siguiente ejemplo, se importa la información de SSL en Aurora MySQL. En los archivos con formato .pem, el código del cuerpo suele ser más grande que el que se muestra en el ejemplo.
```
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
```
## mysql.rds\$1next\$1master\$1log (Aurora MySQL versión 2)
Cambia la posición del registro de instancia de base de datos de origen al inicio del siguiente registro binario en la instancia de base de datos de origen. Use este procedimiento únicamente si aparece el error de E/S de replicación 1236 en una réplica de lectura.
### Sintaxis
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### Parámetros
*curr\$1master\$1log*
El índice del archivo de registro maestro actual. Por ejemplo, si el nombre del archivo actual es `mysql-bin-changelog.012345`, el índice es 12345. Para determinar el nombre del archivo de log maestro actual, ejecute el comando `SHOW REPLICA STATUS` y vea el campo `Master_Log_File`.
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_next_master_log`.
**aviso**
Llame a `mysql.rds_next_master_log` solo si la replicación deja de funcionar tras una conmutación por error de una instancia de base de datos Multi-AZ que es el origen de la replicación y el campo `Last_IO_Errno` de `SHOW REPLICA STATUS` muestra el error de E/S 1236.
La llamada a `mysql.rds_next_master_log` puede provocar una pérdida de datos en la réplica de lectura si las transacciones de la instancia de origen no se escribieron en el registro binario en el disco antes del evento de conmutación por error.
### Ejemplos
Supongamos que la replicación falla en una réplica de lectura de Aurora MySQL. La ejecución de `SHOW REPLICA STATUS\G` en la réplica de lectura devuelve el siguiente resultado:
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
El campo `Last_IO_Errno` muestra que la instancia ha recibido el error de E/S 1236. El campo `Master_Log_File` muestra que el nombre de archivo es `mysql-bin-changelog.012345`, lo que significa que el índice del archivo de registro es `12345`. Para resolver el error, puede llamar a `mysql.rds_next_master_log` con el siguiente parámetro:
```
CALL mysql.rds_next_master_log(12345);
```
## mysql.rds\$1next\$1source\$1log (Aurora MySQL versión 3)
Cambia la posición del registro de instancia de base de datos de origen al inicio del siguiente registro binario en la instancia de base de datos de origen. Use este procedimiento únicamente si aparece el error de E/S de replicación 1236 en una réplica de lectura.
### Sintaxis
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### Parameters
*curr\$1source\$1log*
El índice del archivo de registro de origen actual. Por ejemplo, si el nombre del archivo actual es `mysql-bin-changelog.012345`, el índice es 12345. Para determinar el nombre del archivo de registro de origen actual, ejecute el comando `SHOW REPLICA STATUS` y vea el campo `Source_Log_File`.
### Notas de uso
El usuario administrativo debe ejecutar el procedimiento `mysql.rds_next_source_log`.
**aviso**
Llame a `mysql.rds_next_source_log` solo si la replicación deja de funcionar tras una conmutación por error de una instancia de base de datos Multi-AZ que es el origen de la replicación y el campo `Last_IO_Errno` de `SHOW REPLICA STATUS` muestra el error de E/S 1236.
La llamada a `mysql.rds_next_source_log` puede provocar una pérdida de datos en la réplica de lectura si las transacciones de la instancia de origen no se escribieron en el registro binario en el disco antes del evento de conmutación por error. Puede reducir el riesgo de que esto ocurra configurando los parámetros de la instancia de origen `sync_binlog` y `innodb_support_xa` en `1`, aunque esto podría reducir el rendimiento.
### Ejemplos
Supongamos que la replicación falla en una réplica de lectura de Aurora MySQL. La ejecución de `SHOW REPLICA STATUS\G` en la réplica de lectura devuelve el siguiente resultado:
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
El campo `Last_IO_Errno` muestra que la instancia ha recibido el error de E/S 1236. El campo `Source_Log_File` muestra que el nombre de archivo es `mysql-bin-changelog.012345`, lo que significa que el índice del archivo de registro es `12345`. Para resolver el error, puede llamar a `mysql.rds_next_source_log` con el siguiente parámetro:
```
CALL mysql.rds_next_source_log(12345);
```
## mysql.rds\$1remove\$1binlog\$1ssl\$1material
Elimina el certificado de la entidad de certificación, el certificado cliente y la clave cliente para las comunicaciones SSL y la replicación cifrada. Esta información se importa mediante [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
### Sintaxis
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master (Aurora MySQL versión 2)
Vuelve a configurar una instancia de base de datos de Aurora MySQL para que deje de ser una réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
**importante**
Para ejecutar este procedimiento, `autocommit` debe estar habilitado. Para habilitarlo, establezca el parámetro `autocommit` en `1`. Para obtener información acerca de cómo modificar los parámetros, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxis
```
CALL mysql.rds_reset_external_master;
```
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_reset_external_master`. Este procedimiento se debe ejecutar en la instancia de base de datos de MySQL que se va a eliminar como réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
**nota**
Ofrecemos estos procedimientos almacenados principalmente para habilitar la replicación con las instancias de MySQL que se ejecutan fuera de Amazon RDS. Recomendamos que utilice réplicas de Aurora para administrar la replicación dentro de un clúster de base de datos de Aurora MySQL siempre que sea posible. Para obtener información sobre la administración de la replicación en clústeres de base de datos de Aurora MySQL, consulte [Uso de réplicas de Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Para obtener más información acerca del uso de la replicación para importar los datos desde una instancia de MySQL que se ejecuta fuera de Aurora MySQL, 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).
## mysql.rds\$1reset\$1external\$1source (Aurora MySQL versión 3)
Vuelve a configurar una instancia de base de datos de Aurora MySQL para que deje de ser una réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
**importante**
Para ejecutar este procedimiento, `autocommit` debe estar habilitado. Para habilitarlo, establezca el parámetro `autocommit` en `1`. Para obtener información acerca de cómo modificar los parámetros, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxis
```
CALL mysql.rds_reset_external_source;
```
### Notas de uso
El usuario administrativo debe ejecutar el procedimiento `mysql.rds_reset_external_source`. Este procedimiento se debe ejecutar en la instancia de base de datos de MySQL que se va a eliminar como réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
**nota**
Ofrecemos estos procedimientos almacenados principalmente para habilitar la replicación con las instancias de MySQL que se ejecutan fuera de Amazon RDS. Recomendamos que utilice réplicas de Aurora para administrar la replicación dentro de un clúster de base de datos de Aurora MySQL siempre que sea posible. Para obtener información sobre la administración de la replicación en clústeres de base de datos de Aurora MySQL, consulte [Uso de réplicas de Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versión 3)
Habilita el cifrado `SOURCE_SSL` para la replicación de binlog. Para obtener más información, consulte [CHANGE REPLICATION SOURCE TO statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) en la documentación de MySQL.
### Sintaxis
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### Parameters
*mode*
Valor que indica si está habilitado el cifrado:`SOURCE_SSL`
+ `0`: el cifrado `SOURCE_SSL` está deshabilitado. El valor predeterminado es `0`.
+ `1`: el cifrado `SOURCE_SSL` está habilitado. Puede configurar el cifrado mediante SSL o TLS.
### Notas de uso
Este procedimiento es compatible con la versión 3.06 y versiones posteriores de Aurora MySQL.
## mysql.rds\$1set\$1external\$1master (Aurora MySQL versión 2)
Configura una instancia de base de datos de Aurora MySQL para que sea una réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
El procedimiento `mysql.rds_set_external_master` está en desuso y se eliminará en la próxima versión. En su lugar, use `mysql.rds\$1set\$1external\$1source`.
**importante**
Para ejecutar este procedimiento, `autocommit` debe estar habilitado. Para habilitarlo, establezca el parámetro `autocommit` en `1`. Para obtener información acerca de cómo modificar los parámetros, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxis
```
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### Parámetros
*host\$1name*
El nombre de host o la dirección IP de la instancia de MySQL que se ejecuta fuera de Amazon RDS para convertirse en instancia de base de datos de origen.
*host\$1port*
El puerto usado por la instancia de MySQL que se ejecuta fuera de Amazon RDS que se configurará como instancia de base de datos de origen. Si la configuración de la red incluye la replicación de puertos SSH (Secure Shell) que convierte el número de puerto, especifique el número de puerto expuesto por SSH.
*replication\$1user\$1name*
El ID de un usuario con permisos `REPLICATION CLIENT` y `REPLICATION SLAVE` en la instancia de MySQL que se ejecuta fuera de Amazon RDS. Es recomendable que proporcione una cuenta que se use solo para la replicación con la instancia externa.
*replication\$1user\$1password*
La contraseña del ID de usuario especificado en `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
El nombre del registro binario de la instancia de base de datos de origen que contiene la información de replicación.
*mysql\$1binary\$1log\$1file\$1location*
La ubicación del registro binario `mysql_binary_log_file_name` en la que la replicación empieza a leer la información de la replicación.
Para determinar el nombre y la ubicación del archivo binlog, puede ejecutar `SHOW MASTER STATUS` en la instancia de base de datos de origen.
*ssl\$1encryption*
Valor que especifica si el cifrado de la capa de conexión segura (SSL) se usa en la conexión de reproducción. El 1 especifica que se usa el cifrado SSL; el 0 especifica que no se usa el cifrado. El valor predeterminado es 0.
La opción `MASTER_SSL_VERIFY_SERVER_CERT` no es compatible. Esta opción se establece en 0, lo que significa que la conexión está cifrada, pero los certificados no se verifican.
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_set_external_master`. Este procedimiento se debe ejecutar en la instancia de base de datos de MySQL que se va a configurar como réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
Antes de ejecutar `mysql.rds_set_external_master`, debe configurar la instancia de MySQL que se ejecuta fuera de Amazon RDS como instancia de base de datos de origen. Para conectarse a la instancia de MySQL que se ejecuta fuera de Amazon RDS, debe especificar los valores de `replication_user_name` y `replication_user_password` que indican un usuario de replicación que tiene los permisos `REPLICATION CLIENT` y `REPLICATION SLAVE` en la instancia externa de MySQL.
**Para configurar una instancia externa de MySQL como instancia de base de datos de origen**
1. Con el cliente de MySQL que prefiera, conéctese a la instancia externa de MySQL y cree una cuenta de usuario que se usará para la replicación. A continuación se muestra un ejemplo.
**MySQL 5.7**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
```
**nota**
Especifique una contraseña distinta de la que se muestra aquí como práctica recomendada de seguridad.
1. En la instancia externa de MySQL, conceda a `REPLICATION CLIENT` y a `REPLICATION SLAVE` privilegios para el usuario de replicación. En el siguiente ejemplo se conceden los privilegios `REPLICATION CLIENT` y `REPLICATION SLAVE` en todas las bases de datos al usuario “repl\$1user” de su dominio.
**MySQL 5.7**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Para utilizar la replicación cifrada, configure la instancia de base de datos de origen para que utilice conexiones SSL. Asimismo, importe el certificado de la entidad de certificación, el certificado cliente y la clave cliente en la instancia de base de datos o clúster de base de datos mediante el procedimiento [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
**nota**
Ofrecemos estos procedimientos almacenados principalmente para habilitar la replicación con las instancias de MySQL que se ejecutan fuera de Amazon RDS. Recomendamos que utilice réplicas de Aurora para administrar la replicación dentro de un clúster de base de datos de Aurora MySQL siempre que sea posible. Para obtener información sobre la administración de la replicación en clústeres de base de datos de Aurora MySQL, consulte [Uso de réplicas de Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Después de llamar a `mysql.rds_set_external_master` para configurar una instancia de base de datos de Amazon RDS como réplica de lectura, puede llamar a [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) en la réplica de lectura para iniciar el proceso de replicación. Puede llamar a [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versión 2)](#mysql_rds_reset_external_master) para eliminar la configuración de la réplica de lectura.
Cuando se llama a `mysql.rds_set_external_master`, Amazon RDS registra la hora, el usuario y una acción `set master` en las tablas `mysql.rds_history` y `mysql.rds_replication_status`.
### Ejemplos
Cuando se ejecuta en una instancia de base de datos de MySQL, el siguiente ejemplo configura la instancia de base de datos como réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
```
call mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1source (Aurora MySQL versión 3)
Configura una instancia de base de datos de Aurora MySQL para que sea una réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
**importante**
Para ejecutar este procedimiento, `autocommit` debe estar habilitado. Para habilitarlo, establezca el parámetro `autocommit` en `1`. Para obtener información acerca de cómo modificar los parámetros, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxis
```
CALL mysql.rds_set_external_source (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### Parámetros
*host\$1name*
El nombre de host o la dirección IP de la instancia de MySQL que se ejecuta fuera de Amazon RDS para convertirse en instancia de base de datos de origen.
*host\$1port*
El puerto usado por la instancia de MySQL que se ejecuta fuera de Amazon RDS que se configurará como instancia de base de datos de origen. Si la configuración de la red incluye la replicación de puertos SSH (Secure Shell) que convierte el número de puerto, especifique el número de puerto expuesto por SSH.
*replication\$1user\$1name*
El ID de un usuario con permisos `REPLICATION CLIENT` y `REPLICATION SLAVE` en la instancia de MySQL que se ejecuta fuera de Amazon RDS. Es recomendable que proporcione una cuenta que se use solo para la replicación con la instancia externa.
*replication\$1user\$1password*
La contraseña del ID de usuario especificado en `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
El nombre del registro binario de la instancia de base de datos de origen que contiene la información de replicación.
*mysql\$1binary\$1log\$1file\$1location*
La ubicación del registro binario `mysql_binary_log_file_name` en la que la replicación empieza a leer la información de la replicación.
Para determinar el nombre y la ubicación del archivo binlog, puede ejecutar `SHOW MASTER STATUS` en la instancia de base de datos de origen.
*ssl\$1encryption*
Valor que especifica si el cifrado de la capa de conexión segura (SSL) se usa en la conexión de reproducción. El 1 especifica que se usa el cifrado SSL; el 0 especifica que no se usa el cifrado. El valor predeterminado es 0.
Debe haber importado un certificado SSL personalizado mediante [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) para habilitar esta opción. Si no ha importado un certificado SSL personalizado, defina este parámetro en 0 y utilice [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versión 3)](#mysql_rds_set_binlog_source_ssl) para habilitar el SSL para la replicación de registros binarios.
La opción `SOURCE_SSL_VERIFY_SERVER_CERT` no es compatible. Esta opción se establece en 0, lo que significa que la conexión está cifrada, pero los certificados no se verifican.
### Notas de uso
El usuario administrativo debe ejecutar el procedimiento `mysql.rds_set_external_source`. Este procedimiento se debe ejecutar en la instancia de base de datos de Aurora MySQL que se va a configurar como réplica de lectura de una instancia de MySQL que se ejecute fuera de Amazon RDS.
Antes de ejecutar `mysql.rds_set_external_source`, debe configurar la instancia de MySQL que se ejecuta fuera de Amazon RDS como instancia de base de datos de origen. Para conectarse a la instancia de MySQL que se ejecuta fuera de Amazon RDS, debe especificar los valores de `replication_user_name` y `replication_user_password` que indican un usuario de replicación que tiene los permisos `REPLICATION CLIENT` y `REPLICATION SLAVE` en la instancia externa de MySQL.
**Para configurar una instancia externa de MySQL como instancia de base de datos de origen**
1. Con el cliente de MySQL que prefiera, conéctese a la instancia externa de MySQL y cree una cuenta de usuario que se usará para la replicación. A continuación se muestra un ejemplo.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**nota**
Especifique una contraseña distinta de la que se muestra aquí como práctica recomendada de seguridad.
1. En la instancia externa de MySQL, conceda a `REPLICATION CLIENT` y a `REPLICATION SLAVE` privilegios para el usuario de replicación. En el siguiente ejemplo se conceden los privilegios `REPLICATION CLIENT` y `REPLICATION SLAVE` en todas las bases de datos al usuario “repl\$1user” de su dominio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Para utilizar la replicación cifrada, configure la instancia de base de datos de origen para que utilice conexiones SSL. Asimismo, importe el certificado de la entidad de certificación, el certificado del cliente y la clave de cliente en la instancia de base de datos o clúster de base de datos mediante el procedimiento [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html).
**nota**
Ofrecemos estos procedimientos almacenados principalmente para habilitar la replicación con las instancias de MySQL que se ejecutan fuera de Amazon RDS. Recomendamos que utilice réplicas de Aurora para administrar la replicación dentro de un clúster de base de datos de Aurora MySQL siempre que sea posible. Para obtener información sobre la administración de la replicación en clústeres de base de datos de Aurora MySQL, consulte [Uso de réplicas de Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Después de llamar a `mysql.rds_set_external_source` para configurar una instancia de base de datos de Aurora MySQL como réplica de lectura, puede llamar a [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) en la réplica de lectura para iniciar el proceso de replicación. Puede llamar a [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versión 3)](#mysql_rds_reset_external_source) para eliminar la configuración de la réplica de lectura.
Cuando se llama a `mysql.rds_set_external_source`, Amazon RDS registra la hora, el usuario y una acción `set master` en las tablas `mysql.rds_history` y `mysql.rds_replication_status`.
### Ejemplos
Cuando se ejecuta en una instancia de base de datos de Aurora MySQL, el siguiente ejemplo configura la instancia de base de datos como réplica de lectura de una instancia de MySQL que se ejecuta fuera de Amazon RDS.
```
call mysql.rds_set_external_source(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versión 2)
Permite configurar una instancia principal de Aurora MySQL para aceptar la replicación entrante desde una instancia MySQL externa. Este procedimiento también configura la replicación basada en identificadores de transacciones globales (GTID).
Este procedimiento no configura la replicación retardada, porque Aurora MySQL no admite este tipo de replicación.
### Sintaxis
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### Parámetros
*host\$1name*
El nombre de host o la dirección IP de la instancia de MySQL que se ejecuta fuera de Aurora que se convertirá en el origen de replicación.
*host\$1port*
El puerto usado por la instancia de MySQL que se ejecuta fuera de Aurora que se configurará como origen de la replicación. Si la configuración de la red incluye la replicación de puertos Secure Shell (SSH) que convierte el número de puerto, especifique el número de puerto expuesto por SSH.
*replication\$1user\$1name*
ID de un usuario con permisos `REPLICATION CLIENT` y `REPLICATION SLAVE` en la instancia de MySQL que se ejecuta fuera de Aurora. Es recomendable que proporcione una cuenta que se use solo para la replicación con la instancia externa.
*replication\$1user\$1password*
La contraseña del ID de usuario especificado en `replication_user_name`.
*ssl\$1encryption*
Esta opción no está implementada actualmente. El valor predeterminado es 0.
### Notas de uso
Para un clúster de bases de datos de Aurora MySQL, puede invocar este procedimiento almacenado cuando esté conectado a la instancia principal.
El usuario maestro debe ejecutar el procedimiento `mysql.rds_set_external_master_with_auto_position`. El usuario maestro ejecuta este procedimiento en la instancia principal de un clúster de bases de datos de Aurora MySQL que funciona como un destino de replicación. Este puede ser el destino de replicación de una instancia de MySQL externa o un clúster de bases de datos de Aurora MySQL.
Este procedimiento se admite para la versión 2 de Aurora MySQL. Para Aurora MySQL versión 3, utilice el procedimiento [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versión 3)](#mysql_rds_set_external_source_with_auto_position) en su lugar.
Antes de ejecutar `mysql.rds_set_external_master_with_auto_position`, configure la instancia de base de datos de MySQL para que sea un origen de replicación. Para conectar la instancia de MySQL externa, especifique valores para `replication_user_name` y `replication_user_password`. Estos valores deben indicar a un usuario de replicación que tiene permisos `REPLICATION CLIENT` y `REPLICATION SLAVE` en la instancia externa de MySQL.
**Para configurar una instancia externa de MySQL como origen de replicación**
1. Con el cliente de MySQL que prefiera, conéctese a la instancia externa de MySQL y cree una cuenta de usuario que se usará para la replicación. A continuación se muestra un ejemplo.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. En la instancia de MySQL externa, conceda a `REPLICATION CLIENT` y a `REPLICATION SLAVE` privilegios para el usuario de replicación. En el siguiente ejemplo se conceden los privilegios `REPLICATION CLIENT` y `REPLICATION SLAVE` en todas las bases de datos al usuario `'repl_user'` de su dominio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Cuando invoque `mysql.rds_set_external_master_with_auto_position`, Amazon RDS registra determinada información. Esta información es la hora, el usuario y una acción de `"set master"` en las tablas de `mysql.rds_history` y `mysql.rds_replication_status`.
Para omitir una transacción específica basada en GTID que se sabe que causa un problema, puede usar el procedimiento almacenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versión 2 y 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obtener más información sobre el uso de la replicación basada en GTID, consulte [Uso de la replicación basada en GTID](mysql-replication-gtid.md).
### Ejemplos
Cuando se ejecuta en una instancia principal de Aurora, el siguiente ejemplo configura el clúster de Aurora para que actúe como réplica de lectura de una instancia de MySQL que se ejecuta fuera de Aurora.
```
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versión 3)
Permite configurar una instancia principal de Aurora MySQL para aceptar la replicación entrante desde una instancia MySQL externa. Este procedimiento también configura la replicación basada en identificadores de transacciones globales (GTID).
### Sintaxis
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### Parámetros
*host\$1name*
El nombre de host o la dirección IP de la instancia de MySQL que se ejecuta fuera de Aurora que se convertirá en el origen de replicación.
*host\$1port*
El puerto usado por la instancia de MySQL que se ejecuta fuera de Aurora que se configurará como origen de la replicación. Si la configuración de la red incluye la replicación de puertos Secure Shell (SSH) que convierte el número de puerto, especifique el número de puerto expuesto por SSH.
*replication\$1user\$1name*
ID de un usuario con permisos `REPLICATION CLIENT` y `REPLICATION SLAVE` en la instancia de MySQL que se ejecuta fuera de Aurora. Es recomendable que proporcione una cuenta que se use solo para la replicación con la instancia externa.
*replication\$1user\$1password*
La contraseña del ID de usuario especificado en `replication_user_name`.
*ssl\$1encryption*
Esta opción no está implementada actualmente. El valor predeterminado es 0.
Utilice [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versión 3)](#mysql_rds_set_binlog_source_ssl) para habilitar SSL para replicación de registros binarios.
### Notas de uso
Para un clúster de bases de datos de Aurora MySQL, puede invocar este procedimiento almacenado cuando esté conectado a la instancia principal.
El usuario administrativo debe ejecutar el procedimiento `mysql.rds_set_external_source_with_auto_position`. El usuario administrativo ejecuta este procedimiento en la instancia principal de un clúster de bases de datos de Aurora MySQL que funciona como un destino de replicación. Este puede ser el destino de replicación de una instancia de MySQL externa o un clúster de bases de datos de Aurora MySQL.
Este procedimiento se admite para Aurora MySQL versión 3. Este procedimiento no configura la replicación retardada, porque Aurora MySQL no admite este tipo de replicación.
Antes de ejecutar `mysql.rds_set_external_source_with_auto_position`, configure la instancia de base de datos de MySQL para que sea un origen de replicación. Para conectar la instancia de MySQL externa, especifique valores para `replication_user_name` y `replication_user_password`. Estos valores deben indicar a un usuario de replicación que tiene permisos `REPLICATION CLIENT` y `REPLICATION SLAVE` en la instancia externa de MySQL.
**Para configurar una instancia externa de MySQL como origen de replicación**
1. Con el cliente de MySQL que prefiera, conéctese a la instancia externa de MySQL y cree una cuenta de usuario que se usará para la replicación. A continuación se muestra un ejemplo.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. En la instancia de MySQL externa, conceda a `REPLICATION CLIENT` y a `REPLICATION SLAVE` privilegios para el usuario de replicación. En el siguiente ejemplo se conceden los privilegios `REPLICATION CLIENT` y `REPLICATION SLAVE` en todas las bases de datos al usuario `'repl_user'` de su dominio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Cuando invoque `mysql.rds_set_external_source_with_auto_position`, Amazon RDS registra determinada información. Esta información es la hora, el usuario y una acción de `"set master"` en las tablas de `mysql.rds_history` y `mysql.rds_replication_status`.
Para omitir una transacción específica basada en GTID que se sabe que causa un problema, puede usar el procedimiento almacenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versión 2 y 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obtener más información sobre el uso de la replicación basada en GTID, consulte [Uso de la replicación basada en GTID](mysql-replication-gtid.md).
### Ejemplos
Cuando se ejecuta en una instancia principal de Aurora, el siguiente ejemplo configura el clúster de Aurora para que actúe como réplica de lectura de una instancia de MySQL que se ejecuta fuera de Aurora.
```
call mysql.rds_set_external_source_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL versión 2)
Establece el modo de replicación en el que se debe basar ya sea en posiciones de archivos de registros binarios o en identificadores de transacciones globales (GTID).
### Sintaxis
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### Parámetros
*auto\$1position\$1mode*
Un valor que indicar si debe usarse la replicación de posición de los archivos de registro o la replicación basada en GTID:
+ `0`: utilice el método de replicación basado en la posición del archivo de registro binario. El valor predeterminado es `0`.
+ `1`: utilice el método de replicación basado en GTID.
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_set_master_auto_position`.
Este procedimiento se admite para la versión 2 de Aurora MySQL.
## mysql.rds\$1set\$1read\$1only (Aurora MySQL versión 3)
Activa o desactiva el modo `read_only` globalmente para la instancia de base de datos.
### Sintaxis
```
CALL mysql.rds_set_read_only(mode);
```
### Parameters
*mode*
Valor que indica si el modo `read_only` está activado o desactivado globalmente para la instancia de base de datos:
+ `0`: `OFF`. El valor predeterminado es `0`.
+ `1` – `ON`
### Notas de uso
El procedimiento almacenado `mysql.rds_set_read_only` modifica solo el parámetro `read_only`. El parámetro `innodb_read_only` no se puede cambiar en las instancias de bases de datos del lector.
El cambio del parámetro `read_only` no persiste al reiniciarse. Para realizar cambios permanentes en `read_only`, debe usar el parámetro de clúster de base de datos `read_only`.
Este procedimiento es compatible con la versión 3.06 y versiones posteriores de Aurora MySQL.
## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versión 2)
Establece el formato de registro binario de la sesión actual.
### Sintaxis
```
CALL mysql.rds_set_session_binlog_format(format);
```
### Parameters
*format*
Un valor que indica el formato de registro binario de la sesión actual:
+ `STATEMENT`: el origen de la replicación escribe los eventos en el registro binario en función de instrucciones SQL.
+ `ROW`: el origen de la replicación escribe los eventos en el registro binario que indican los cambios en las filas individuales de la tabla.
+ `MIXED`: el registro se basa generalmente en instrucciones SQL, pero cambia a filas en determinadas condiciones. Para obtener más información, consulte [Mixed Binary Logging Format](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html) en la documentación de MySQL.
### Notas de uso
Para un clúster de bases de datos de Aurora MySQL, puede invocar este procedimiento almacenado cuando esté conectado a la instancia principal.
Para utilizar este procedimiento almacenado, debe tener configurado el registro binario para la sesión actual.
Para Aurora, este procedimiento se admite en la versión 2.12 y versiones posteriores compatibles con MySQL 5.7 de Aurora MySQL.
## mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL versión 3)
Establece el modo de replicación en el que se debe basar, ya sea en posiciones de archivos de registros binarios o en identificadores de transacciones globales (GTID).
### Sintaxis
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### Parámetros
*auto\$1position\$1mode*
Un valor que indicar si debe usarse la replicación de posición de los archivos de registro o la replicación basada en GTID:
+ `0`: utilice el método de replicación basado en la posición del archivo de registro binario. El valor predeterminado es `0`.
+ `1`: utilice el método de replicación basado en GTID.
### Notas de uso
Para un clúster de bases de datos de Aurora MySQL, puede invocar este procedimiento almacenado cuando esté conectado a la instancia principal.
El usuario administrativo debe ejecutar el procedimiento `mysql.rds_set_source_auto_position`.
## mysql.rds\$1skip\$1repl\$1error
Omite y elimina un error de replicación en una réplica de lectura de base de datos de MySQL.
### Sintaxis
```
CALL mysql.rds_skip_repl_error;
```
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_skip_repl_error` en una réplica de lectura. Para obtener más información sobre este procedimiento, consulte [Skipping the current replication error](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError) (Omitir el error de replicación actual).
Para determinar si hay errores, ejecute el comando `SHOW REPLICA STATUS\G` de MySQL. Si un error de replicación no es crítico, puede ejecutar `mysql.rds_skip_repl_error` para omitir el error. Si hay varios errores, `mysql.rds_skip_repl_error` elimina el primer error y advierte de que hay otros presentes. A continuación, puede usar `SHOW REPLICA STATUS\G` para determinar la acción correcta para el siguiente error. Para obtener información acerca de los valores devueltos, consulte [la instrucción SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) en la documentación de MySQL.
Para obtener más información acerca de la resolución de problemas de replicación con Aurora MySQL, consulte [Diagnóstico y solución de un error de replicación de lectura de MySQL](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR).
#### Error de replicación detenida
Al llamar al procedimiento `mysql.rds_skip_repl_error`, es posible que reciba un mensaje de error en el que se indica que la réplica tiene un error o está deshabilitada.
Este mensaje de error aparece si ejecuta el procedimiento en la instancia principal en lugar de en la réplica de lectura. Debe ejecutar este procedimiento en la réplica de lectura para que funcione.
Este mensaje de error también puede aparecer si ejecuta el procedimiento en la réplica de lectura, pero la replicación no se puede reiniciar correctamente.
Si tiene que omitir un número de errores elevado, el retardo de réplica puede aumentar por encima del periodo de retención predeterminado para los archivos de log binarios (binlog). En este caso, puede producirse un error fatal porque los archivos binlog se están limpiando antes de reproducirse de nuevo en la réplica de lectura. Esta limpieza hace que la replicación se detenga y ya no se puede llamar al comando `mysql.rds_skip_repl_error` para omitir los errores de replicación.
Puede mitigar este problema incrementando el número de horas que los archivos binlog se retienen en la instancia de base de datos de origen. Después de incrementar el tiempo de retención de los archivos binlog, puede reiniciar la replicación y llamar al comando `mysql.rds_skip_repl_error` si es necesario.
Para definir el tiempo de retención de binlog, use el procedimiento [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) y especifique un parámetro de configuración de `'binlog retention hours'` junto con el número de horas para retener los archivos binlog en el clúster de base de datos. El ejemplo siguiente define el período de retención de los archivos binlog en 48 horas.
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
Inicia la replicación desde un clúster de base de datos de Aurora MySQL.
**nota**
Puede utilizar el procedimiento almacenado [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versión 3)](#mysql_rds_start_replication_until) o [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versión 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) para iniciar la replicación desde una instancia de base de datos de Aurora MySQL y detener la replicación en la ubicación del archivo de registro binario especificado.
### Sintaxis
```
CALL mysql.rds_start_replication;
```
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_start_replication`.
Para importar datos desde una instancia de MySQL fuera de Amazon RDS, llame a `mysql.rds_start_replication` en la réplica de lectura para iniciar el proceso de replicación después de llamar a [mysql.rds\$1set\$1external\$1master (Aurora MySQL versión 2)](#mysql_rds_set_external_master) o [mysql.rds\$1set\$1external\$1source (Aurora MySQL versión 3)](#mysql_rds_set_external_source) para crear la configuración de replicación. Para obtener más información, 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).
Para exportar datos a una instancia de MySQL externa a Amazon RDS, llame a `mysql.rds_start_replication` y a `mysql.rds_stop_replication` en la réplica de lectura para controlar algunas acciones de replicación, como la purga de registros binarios. Para obtener más información, 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).
Puede llamar a `mysql.rds_start_replication` en la réplica de lectura para reiniciar cualquier proceso de replicación que haya detenido previamente llamando a `mysql.rds_stop_replication`. Para obtener más información, consulte [Error de replicación detenida](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped).
## mysql.rds\$1start\$1replication\$1until(Aurora MySQL versión 3)
Inicia la replicación desde un clúster de base de datos de Aurora MySQL y detiene la replicación en la ubicación del archivo de registro binario especificado.
### Sintaxis
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### Parámetros
*replication\$1log\$1file*
El nombre del registro binario de la instancia de base de datos de origen que contiene la información de replicación.
*replication\$1stop\$1point *
La ubicación del registro binario `replication_log_file` en la que la replicación se detendrá.
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_start_replication_until`.
Este procedimiento es compatible con la versión 3.04 y versiones posteriores de Aurora MySQL.
El procedimiento almacenado `mysql.rds_start_replication_until` no es compatible con la replicación administrada, que incluye lo siguiente:
+ [Reproducción de clústeres de base de datos de Amazon Aurora MySQL entre Regiones de AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migración de datos desde una instancia de base de datos de RDS para MySQL a un clúster de base de datos de Amazon Aurora MySQL con una réplica de lectura de Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
El nombre de archivo especificado para el parámetro `replication_log_file` debe coincidir con el nombre del archivo binlog de instancia de base de datos de origen.
Cuando el parámetro `replication_stop_point` especifica una ubicación de parada correspondiente al pasado, la replicación se detiene de inmediato.
### Ejemplos
En el ejemplo siguiente se inicia la replicación y se replican los cambios hasta que alcanza la ubicación `120` del archivo registro binario `mysql-bin-changelog.000777`.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
## mysql.rds\$1stop\$1replication
Detiene la replicación desde una instancia de base de datos de MySQL.
### Sintaxis
```
CALL mysql.rds_stop_replication;
```
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_stop_replication`.
Si desea configurar la replicación para importar datos desde una instancia de MySQL que se ejecuta fuera de Amazon RDS, llame a `mysql.rds_stop_replication` en la réplica de lectura para detener el proceso de replicación una vez completada la importación. Para obtener más información, 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).
Si desea configurar la replicación para exportar datos a una instancia de MySQL externa a Amazon RDS, llame a `mysql.rds_start_replication` y a `mysql.rds_stop_replication` en la réplica de lectura para controlar algunas acciones de replicación, como la limpieza de registros binarios. Para obtener más información, 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).
El procedimiento almacenado `mysql.rds_stop_replication` no es compatible con la replicación administrada, que incluye lo siguiente:
+ [Reproducción de clústeres de base de datos de Amazon Aurora MySQL entre Regiones de AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migración de datos desde una instancia de base de datos de RDS para MySQL a un clúster de base de datos de Amazon Aurora MySQL con una réplica de lectura de Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
# Finalización de una sesión o una consulta
Los siguientes procedimientos almacenados finalizan una sesión o una consulta.
**Topics**
+ [mysql.rds\$1kill](#mysql_rds_kill)
+ [mysql.rds\$1kill\$1query](#mysql_rds_kill_query)
## mysql.rds\$1kill
Finaliza una conexión al servidor de MySQL.
### Sintaxis
```
CALL mysql.rds_kill(processID);
```
### Parámetros
*processID*
La identidad del subproceso de conexión que se va a finalizar.
### Notas de uso
Cada conexión al servidor de MySQL se ejecuta en un subproceso independiente. Para finalizar una conexión, use el procedimiento `mysql.rds_kill` y transfiera el ID de subproceso de esa conexión. Para obtener el ID del subproceso, use el comando [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) de MySQL.
### Ejemplos
El siguiente ejemplo finaliza una conexión con el ID de subproceso 4243:
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
Finaliza una consulta que se ejecuta en el servidor de MySQL.
### Sintaxis
```
CALL mysql.rds_kill_query(processID);
```
### Parámetros
*processID*
La identidad del proceso o subproceso que ejecuta la consulta que se va a finalizar.
### Notas de uso
Para detener una consulta que se ejecuta en el servidor MySQL, utilice el procedimiento `mysql_rds_kill_query` y pase el ID de conexión del subproceso que está ejecutando la consulta. A continuación, el procedimiento finaliza la conexión.
Para obtener el ID, consulte la [tabla INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) o utilice el comando MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). El valor de la columna ID de `SHOW PROCESSLIST` o `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` es el *ID del proceso*.
### Ejemplos
El siguiente ejemplo detiene una consulta con el ID de subproceso 230040:
```
CALL mysql.rds_kill_query(230040);
```
# Replicación de transacciones mediante GTID
Los siguientes procedimientos almacenados controlan cómo se replican las transacciones mediante identificadores de transacciones globales (GTID) con Aurora MySQL. Para conocer cómo utilizar la replicación basada en GTID con Aurora MySQL, consulte [Uso de la replicación basada en GTID](mysql-replication-gtid.md).
**Topics**
+ [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versión 3)](#mysql_assign_gtids_to_anonymous_transactions)
+ [mysql.rds\$1gtid\$1purged (Aurora MySQL versión 3)](#mysql_rds_gtid_purged)
+ [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versión 2 y 3)](#mysql_rds_skip_transaction_with_gtid)
+ [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versión 3)](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versión 3)
Configura la opción `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` de la instrucción `CHANGE REPLICATION SOURCE TO`. Hace que el canal de replicación asigne un GTID a las transacciones replicadas que no tienen uno. De esta forma, puede realizar la replicación de registros binarios desde un origen que no utiliza la replicación basada en GTID en una réplica que sí. Para obtener más información, consulte la [instrucción CHANGE REPLICATION SOURCE TO](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) y [Replicación desde un origen sin GTID a una réplica con GTID](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html) en el *Manual de referencia de MySQL*.
### Sintaxis
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### Parameters
*gtid\$1option*
Valor de cadena. Los valores permitidos son `OFF`, `LOCAL` o un UUID especificado.
### Notas de uso
Este procedimiento tiene el mismo efecto que la emisión de la instrucción `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` en la comunidad MySQL.
El GTID debe dirigirse a `ON` para *gtid\$1option* que se configurará en `LOCAL` o un UUID específico.
El valor predeterminado es `OFF`, lo que significa que la característica no se utiliza.
`LOCAL` asigna un GTID que incluye el UUID de la réplica (la configuración `server_uuid`).
Al pasar un parámetro que es UUID se asigna un GTID que incluye el UUID especificado, como la configuración `server_uuid` para el servidor de origen de replicación.
### Ejemplos
Para desactivar esta característica:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF');
+-------------------------------------------------------------+
| Message |
+-------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF |
+-------------------------------------------------------------+
1 row in set (0.07 sec)
```
Para utilizar el UUID de la réplica:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL');
+---------------------------------------------------------------+
| Message |
+---------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL |
+---------------------------------------------------------------+
1 row in set (0.07 sec)
```
Para utilizar un UUID especificado:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e');
+----------------------------------------------------------------------------------------------+
| Message |
+----------------------------------------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e |
+----------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)
```
## mysql.rds\$1gtid\$1purged (Aurora MySQL versión 3)
Establece el valor global de la variable de sistema `gtid_purged` a un conjunto de identificadores de transacciones globales (GTID) determinado. La variable de sistema `gtid_purged` es un conjunto de GTID que consta de los GTID de todas las transacciones que se han confirmado en el servidor, pero que no existen en ningún archivo de registro binario del servidor.
Hay dos maneras de establecer el valor de `gtid_purged` para que sea compatible con MySQL 8.0:
+ Reemplace el valor de `gtid_purged` con el conjunto de GTID especificado.
+ Anexe el conjunto de GTID especificado al conjunto de GTID que ya contiene `gtid_purged`.
### Sintaxis
Para reemplazar el valor de `gtid_purged` con el conjunto de GTID especificado:
```
CALL mysql.rds_gtid_purged (gtid_set);
```
Para anexar el valor de `gtid_purged` al conjunto de GTID especificado:
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### Parameters
*gtid\$1set*
El valor de *gtid\$1set* debe ser un superconjunto del valor actual de `gtid_purged`, y no puede cruzarse con `gtid_subtract(gtid_executed,gtid_purged)`. Es decir, el nuevo conjunto de GTID debe incluir todos los GTID que ya estuvieron en `gtid_purged`, y no puede incluir ningún GTID en `gtid_executed` que aún no se haya purgado. El parámetro *gtid\$1set* tampoco puede incluir ningún GTID que esté en el conjunto `gtid_owned` global, los GTID de las transacciones que se están procesando actualmente en el servidor.
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_gtid_purged`.
Este procedimiento es compatible con la versión 3.04 y versiones posteriores de Aurora MySQL.
### Ejemplos
En el siguiente ejemplo, se asigna el GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` a la variable global `gtid_purged`.
```
CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versión 2 y 3)
Omite la replicación de una transacción con el identificador de transacción global (GTID) especificado en una instancia principal de Aurora.
Puede utilizar este procedimiento para la recuperación ante desastres cuando se sabe que una transacción de GTID específica causa un problema. Utilice este procedimiento almacenado para omitir la transacción problemática. Entre los ejemplos de transacciones problemáticas se incluyen transacciones que inhabilitan la replicación, eliminan datos importantes o provocan que la instancia de base de datos no esté disponible.
### Sintaxis
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### Parameters
*gtid\$1to\$1skip*
El GTID de la transacción de replicación que se debe omitir.
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_skip_transaction_with_gtid`.
Este procedimiento se admite para Aurora MySQL versión 2 y 3.
### Ejemplos
En el ejemplo siguiente se omite la replicación de la transacción con el GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versión 3)
Inicia la replicación desde un clúster de base de datos de Aurora MySQL y detiene la replicación inmediatamente después del identificador de transacción global (GTID) especificado.
### Sintaxis
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### Parameters
*gtid*
El GTID después del cual debe detenerse la replicación.
### Notas de uso
El usuario maestro debe ejecutar el procedimiento `mysql.rds_start_replication_until_gtid`.
Este procedimiento es compatible con la versión 3.04 y versiones posteriores de Aurora MySQL.
El procedimiento almacenado `mysql.rds_start_replication_until_gtid` no es compatible con la replicación administrada, que incluye lo siguiente:
+ [Reproducción de clústeres de base de datos de Amazon Aurora MySQL entre Regiones de AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migración de datos desde una instancia de base de datos de RDS para MySQL a un clúster de base de datos de Amazon Aurora MySQL con una réplica de lectura de Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
Cuando el parámetro `gtid` especifica una transacción que ya ha ejecutado la réplica, la replicación se detiene de inmediato.
### Ejemplos
En el ejemplo siguiente se inicia la replicación y se replican los cambios hasta que alcanza el GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# Rotación de los registros de consultas
Los siguientes procedimientos almacenados rotan los registros de MySQL en tablas de copia de seguridad. Para obtener más información, consulte [Archivos de registro de base de datos de Aurora MySQL](USER_LogAccess.Concepts.MySQL.md).
**Topics**
+ [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log)
+ [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
Rota la tabla `mysql.general_log` a una tabla de copia de seguridad.
### Sintaxis
```
CALL mysql.rds_rotate_general_log;
```
### Notas de uso
Para rotar la tabla `mysql.general_log` a una tabla de copia de seguridad, llame al procedimiento `mysql.rds_rotate_general_log`. Cuando se rotan las tablas de registro, la tabla de registro actual se copia en una tabla de registro de copia de seguridad y las entradas de la tabla de registro actual se eliminan. Si ya existe una tabla de registro de copia de seguridad, se elimina antes de copiar la tabla del registro actual en el copia de seguridad. Puede consultar la tabla de registro de copia de seguridad si es necesaria. La tabla de registro de copia de seguridad para la tabla `mysql.general_log` se llama `mysql.general_log_backup`.
Puede ejecutar este procedimiento solo cuando el parámetro `log_output` se establezca en`TABLE`.
## mysql.rds\$1rotate\$1slow\$1log
Rota la tabla `mysql.slow_log` a una tabla de copia de seguridad.
### Sintaxis
```
CALL mysql.rds_rotate_slow_log;
```
### Notas de uso
Para rotar la tabla `mysql.slow_log` a una tabla de copia de seguridad, llame al procedimiento `mysql.rds_rotate_slow_log`. Cuando se rotan las tablas de registro, la tabla de registro actual se copia en una tabla de registro de copia de seguridad y las entradas de la tabla de registro actual se eliminan. Si ya existe una tabla de registro de copia de seguridad, se elimina antes de copiar la tabla del registro actual en el copia de seguridad.
Puede consultar la tabla de registro de copia de seguridad si es necesaria. La tabla de registro de copia de seguridad para la tabla `mysql.slow_log` se llama `mysql.slow_log_backup`.
# Establecimiento y muestra de la configuración del registro binario
Los siguientes procedimientos almacenados establecen y muestran los parámetros de configuración, por ejemplo, para la retención de archivos de registro binario.
**Topics**
+ [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration)
+ [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
Especifica el número de horas que se deben conservar los registros binarios o el número de segundos que se retrasará la replicación.
### Sintaxis
```
CALL mysql.rds_set_configuration(name,value);
```
### Parameters
*name*
El nombre del parámetro de configuración que se va a definir.
*value*
El valor del parámetro de configuración.
### Notas de uso
El procedimiento `mysql.rds_set_configuration` admite los parámetros de configuración siguientes:
+ [binlog retention hours](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
Los parámetros de configuración se almacenan de forma permanente y sobreviven a cualquier reinicio o conmutación por error de una instancia de base de datos.
#### binlog retention hours
El parámetro `binlog retention hours` se usa para especificar la cantidad de horas que se deben retener los archivos de registro binario. Por lo general, Amazon Aurora limpia un registro binario lo antes posible, pero el registro binario podría seguir siendo necesario para la replicación con una base de datos MySQL externa a Aurora.
El valor predeterminado de `binlog retention hours` es `NULL`. Para Aurora MySQL, `NULL` significa que los registros binarios se limpian en diferido. Los registros binarios de Aurora MySQL pueden permanecer en el sistema durante un cierto periodo, que generalmente no es más de un día.
Para especificar el número de horas que se deben retener los registros binarios en un clúster de base de datos, utilice el procedimiento almacenado `mysql.rds_set_configuration` y especifique un periodo lo bastante largo como para realizar la replicación, como se muestra en el siguiente ejemplo.
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**nota**
No puede utilizar el valor `0` para `binlog retention hours`.
El valor máximo de `binlog retention hours` para los clústeres de bases de datos de las versiones 2.11.0 y superiores y 3 de Aurora MySQL es 2160 (90 días).
Una vez que haya definido el periodo de retención, monitorice el uso del almacenamiento para la instancia de base de datos con el fin de asegurarse de que los logs binarios conservados no consuman demasiado almacenamiento.
## mysql.rds\$1show\$1configuration
El número de horas que se conservan los registros binarios.
### Sintaxis
```
CALL mysql.rds_show_configuration;
```
### Notas de uso
Para verificar el número de horas que Amazon RDS conserva los registros binarios, use el procedimiento almacenado `mysql.rds_show_configuration`.
### Ejemplos
El ejemplo siguiente muestra el periodo de retención:
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```
# Aurora MySQL: tablas de information\$1schema específica
Aurora MySQL tiene ciertas tablas `information_schema` que son específicas de Aurora.
## information\$1schema.aurora\$1global\$1db\$1instance\$1status
La tabla `information_schema.aurora_global_db_instance_status` contiene información sobre el estado de todas las instancias de base de datos en los clústeres de base de datos principales y secundarios de una base de datos global. La siguiente tabla muestra las columnas que puede utilizar. Las columnas restantes son solo para uso interno de Aurora.
**nota**
Esta tabla de esquema de información solo está disponible con bases de datos globales de la versión 3.04.0 de Aurora MySQL y versiones posteriores.
| Columna | Tipo de datos | Descripción |
| --- | --- | --- |
| SERVER\$1ID | varchar(100) | El identificador de la instancia de base de datos. |
| SESSION\$1ID | varchar(100) | Un identificador único de la sesión actual. Un valor MASTER\$1SESSION\$1ID identifica la instancia de base de datos de Writer (principal). |
| AWS\$1REGION | varchar(100) | La Región de AWS en la que se ejecuta esta instancia de base de datos global. Para obtener una lista de regiones, consulte [Disponibilidad por región](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). |
| DURABLE\$1LSN | bigint unsigned | El número de secuencia de registro (LSN) hecho duradero en el almacenamiento. Un número de secuencia de registro (LSN) es un número secuencial único que identifica un registro en el registro de transacciones de la base de datos. Los LSN se ordenan de tal manera que un LSN más grande representa una transacción posterior. |
| HIGHEST\$1LSN\$1RCVD | bigint unsigned | El LSN más alto recibido por la instancia de base de datos de la instancia de base de datos del escritor. |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | El ID de la transacción más antigua a la que puede purgar la instancia de base de datos del escritor. |
| OLDEST\$1READ\$1VIEW\$1LSN | bigint unsigned | El LSN más antiguo utilizado por la instancia de base de datos para leer desde el almacenamiento. |
| VISIBILITY\$1LAG\$1IN\$1MSEC | float(10,0) unsigned | Para los lectores del clúster de base de datos principal, cuánto se está retrasando esta instancia de base de datos con respecto a la instancia de base de datos del escritor en milisegundos. En el caso de los lectores de un clúster de base de datos secundario, cuánto se está retrasando esta instancia de base de datos respecto al volumen secundario en milisegundos. |
## information\$1schema.aurora\$1global\$1db\$1status
La tabla `information_schema.aurora_global_db_status` contiene información sobre varios aspectos del retraso de la base de datos global de Aurora, específicamente, el retraso del almacenamiento de Aurora subyacente (llamado retraso en la durabilidad) y el retraso entre el objetivo de punto de recuperación (RPO). La siguiente tabla muestra las columnas que puede utilizar. Las columnas restantes son solo para uso interno de Aurora.
**nota**
Esta tabla de esquema de información solo está disponible con bases de datos globales de la versión 3.04.0 de Aurora MySQL y versiones posteriores.
| Columna | Tipo de datos | Descripción |
| --- | --- | --- |
| AWS\$1REGION | varchar(100) | La Región de AWS en la que se ejecuta esta instancia de base de datos global. Para obtener una lista de regiones, consulte [Disponibilidad por región](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). |
| HIGHEST\$1LSN\$1WRITTEN | bigint unsigned | El número de secuencia de registro (LSN) más alto que existe actualmente en este clúster de base de datos. Un número de secuencia de registro (LSN) es un número secuencial único que identifica un registro en el registro de transacciones de la base de datos. Los LSN se ordenan de tal manera que un LSN más grande representa una transacción posterior. |
| DURABILITY\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | La diferencia en los valores de marca temporal entre el HIGHEST\$1LSN\$1WRITTEN del clúster de base de datos secundario y el HIGHEST\$1LSN\$1WRITTEN del clúster de base de datos principal. Este valor es siempre 0 en el clúster de base de datos principal de la base de datos global de Aurora. |
| RPO\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | El retraso del objetivo de punto de recuperación (RPO). El retardo de RPO es el tiempo que tarda la transacción de usuario más reciente en almacenarse en un clúster de base de datos secundario después de almacenarse en el clúster de base de datos principal de una base de datos global de Aurora. Este valor es siempre 0 en el clúster de base de datos principal de la base de datos global de Aurora. En términos sencillos, esta métrica calcula el objetivo de punto de recuperación de cada clúster de base de datos de Aurora MySQL de una base de datos global de Aurora, es decir, cuántos datos podrían perderse si se produce una interrupción. Al igual que con el retraso, el RPO se mide en tiempo. |
| LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | La marca temporal que especifica cuándo se calcularon por última vez los valores para DURABILITY\$1LAG\$1IN\$1MILLISECONDS y RPO\$1LAG\$1IN\$1MILLISECONDS. Un valor temporal como 1970-01-01 00:00:00\$100 significa que este es el clúster de base de datos principal. |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | El ID de la transacción más antigua a la que puede purgar la instancia de base de datos del escritor. |
## information\$1schema.replica\$1host\$1status
La tabla `information_schema.replica_host_status` contiene información de replicación. Las columnas que puede utilizar se muestran en la tabla a continuación. Las columnas restantes son solo para uso interno de Aurora.
| Columna | Tipo de datos | Descripción |
| --- | --- | --- |
| CPU | double | El porcentaje de uso de la CPU del host de la réplica. |
| IS\$1CURRENT | tinyint | Si la réplica está actualizada. |
| LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | Hora en la que se produjo la última actualización. Se usa para determinar si un registro está obsoleto. |
| REPLICA\$1LAG\$1IN\$1MILLISECONDS | double | El retraso de réplica en milisegundos. |
| SERVER\$1ID | varchar(100) | El ID del servidor de base de datos. |
| SESSION\$1ID | varchar(100) | El ID de la sesión de la base de datos. Se utiliza para determinar si una instancia de base de datos es una instancia de escritor o de lectura. |
**nota**
Cuando una instancia de réplica se retrasa, la información consultada en su tabla `information_schema.replica_host_status` puede estar desactualizada. En este caso, te recomendamos que consultes desde la instancia del escritor.
Si bien la`mysql.ro_replica_status` tabla contiene información similar, no es recomendable utilizarla.
## information\$1schema.aurora\$1forwarding\$1processlist
La tabla `information_schema.aurora_forwarding_processlist` contiene información sobre los procesos involucrados en el reenvío de escritura.
El contenido de esta tabla solo está visible en la instancia de base de datos del escritor de un clúster de base de datos que tiene activado el reenvío de escritura global o en el clúster. Se devuelve un conjunto de resultados vacío en las instancias de base de datos del lector.
| Campo | Tipo de datos | Descripción |
| --- | --- | --- |
| ID | bigint | El identificador de la conexión en la instancia de base de datos del escritor. Este identificador es el mismo valor que se muestra en la columna Id de la instrucción SHOW PROCESSLIST y que es devuelto por la función CONNECTION\$1ID() dentro del subproceso. |
| USER | varchar (32) | El usuario de MySQL que emitió la instrucción. |
| HOST | varchar (255) | El cliente MySQL que emitió la instrucción. En el caso de instrucciones reenviadas, este campo muestra la dirección host del cliente de la aplicación que estableció la conexión en la instancia de base de datos del lector de reenvío. |
| DB | varchar (64) | La base de datos predeterminada para el subproceso. |
| COMMAND | varchar (16) | El tipo de comando que el subproceso ejecuta en nombre del cliente, o Sleep si la sesión está inactiva. Para obtener descripciones de los comandos de los subprocesos, consulte [Thread Command Values](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html) en la documentación de MySQL. |
| HORA | int | El tiempo en segundos que el subproceso ha estado en su estado actual. |
| STATE | varchar (64) | Una acción, evento o estado que indica lo que está haciendo el subproceso. Para obtener descripciones de los valores de estado, consulte [General Thread States](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) en la documentación de MySQL. |
| INFO | longtext | La instrucción que se está ejecutando el subproceso, o NULL si no está ejecutando una instrucción. La instrucción puede ser la que se envía al servidor o una instrucción más interna si ejecuta otras instrucciones. |
| IS\$1FORWARDED | bigint | Indica si el subproceso se reenvía desde una instancia de base de datos del lector. |
| REPLICA\$1SESSION\$1ID | bigint | El identificador de conexión de la réplica de Aurora. Este identificador es el mismo valor que se muestra en la columna Id de la instrucción SHOW PROCESSLIST en la instancia de base de datos de Aurora Reader de reenvío. |
| REPLICA\$1INSTANCE\$1IDENTIFIER | varchar (64) | El identificador de la instancia de base de datos del subproceso de reenvío. |
| REPLICA\$1clúster\$1NAME | varchar (64) | El identificador del clúster de base de datos del subproceso de reenvío. Para el reenvío de escritura en el clúster, este identificador es el mismo clúster de base de datos que la instancia de base de datos del escritor. |
| REPLICA\$1REGION | varchar (64) | La Región de AWS desde donde se origina el subproceso de reenvío. Para el reenvío de escritura en el clúster, esta región es la misma Región de AWS que la instancia de base de datos del escritor. |