# Ajuste de Aurora MySQL con información proactiva de Amazon DevOps Guru
La información proactiva de DevOps Guru detecta condiciones problemáticas conocidas en sus clústeres de bases de datos de Aurora MySQL antes de que se produzcan. DevOps Guru puede hacer lo siguiente:
+ Evitar muchos problemas comunes en las bases de datos cotejando la configuración de la base de datos con la configuración habitual recomendada.
+ Alertar sobre problemas críticos en su flota que, si no se comprueban, pueden provocar problemas mayores en el futuro.
+ Avisarle de los problemas que acaban de descubrirse.
Cada información proactiva contiene un análisis de la causa del problema y recomendaciones para las acciones correctivas.
**Topics**
+ [La longitud de la lista de historial de InnoDB ha aumentado de forma significativa](proactive-insights.history-list.md)
+ [La base de datos está creando tablas temporales en el disco](proactive-insights.temp-tables.md)
# La longitud de la lista de historial de InnoDB ha aumentado de forma significativa
A partir de *fecha*, la lista de su historial de cambios en las filas aumentó de forma significativa, hasta *longitud* en *db-instance*. Este aumento afecta al rendimiento de cierre de consultas y bases de datos.
**Topics**
+ [Versiones del motor admitidas](#proactive-insights.history-list.context.supported)
+ [Contexto](#proactive-insights.history-list.context)
+ [Causas probables de este problema](#proactive-insights.history-list.causes)
+ [Acciones](#proactive-insights.history-list.actions)
+ [Métricas relevantes](#proactive-insights.history-list.metrics)
## Versiones del motor admitidas
Esta información es compatible con todas las versiones de Aurora MySQL.
## Contexto
El sistema de transacciones InnoDB mantiene el control de simultaneidad multiversión (MVCC). Cuando se modifica una fila, la versión previa a la modificación de los datos que se están modificando se almacena como registro de deshacer en un registro de deshacer. Cada registro de deshacer tiene una referencia a su registro de rehacer anterior, lo que da lugar a una lista enlazada.
La lista del historial de InnoDB es una lista global de los registros de deshacer de las transacciones confirmadas. MySQL usa la lista del historial para purgar registros y páginas de registro cuando las transacciones ya no necesitan el historial. La longitud de la lista del historial es el número total de registros de deshacer que contienen modificaciones en la lista del historial. Cada registro contiene una o varias modificaciones. Si la longitud de la lista del historial de InnoDB aumenta demasiado, eso indica que hay un gran número de versiones de filas antiguas, y las consultas y los cierres de bases de datos se ralentizan.
## Causas probables de este problema
Las causas típicas de que la lista del historial sea larga son, entre otras, las siguientes:
+ Transacciones de larga duración, ya sean de lectura o escritura
+ Una carga de escritura pesada
## Acciones
Recomendamos diferentes acciones en función de las causas.
**Topics**
+ [No inicie ninguna operación que implique el cierre de la base de datos hasta que la lista del historial de InnoDB se reduzca.](#proactive-insights.history-list.actions.no-shutdown)
+ [Identifique y finalice las transacciones de larga duración](#proactive-insights.history-list.actions.long-txn)
+ [Utilice Información sobre rendimiento para verificar los principales hosts y usuarios.](#proactive-insights.history-list.actions.top-PI)
### No inicie ninguna operación que implique el cierre de la base de datos hasta que la lista del historial de InnoDB se reduzca.
Si la lista del historial de InnoDB es muy larga, los cierres de la base de datos se ralentizan, por lo que debe reducir el tamaño de la lista antes de iniciar operaciones que impliquen el cierre de la base de datos. Estas operaciones incluyen las actualizaciones de la versión principal de la base de datos.
### Identifique y finalice las transacciones de larga duración
Para encontrar transacciones de larga duración, consulte `information_schema.innodb_trx`.
**nota**
Asegúrese también de buscar transacciones de larga duración en las réplicas de lectura.
**Identificación y facilitación de transacciones de larga duración**
1. En su cliente SQL, ejecute la siguiente consulta:
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. Finalice cada transacción de larga duración con el procedimiento [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) almacenado.
### Utilice Información sobre rendimiento para verificar los principales hosts y usuarios.
Optimice las transacciones para que se confirmen inmediatamente un gran número de filas modificadas.
## Métricas relevantes
Las siguientes métricas están relacionadas con esta información:
+ `trx_rseg_history_len`: esta métrica del contador se puede consultar en la información de rendimiento, así como en la tabla `INFORMATION_SCHEMA.INNODB_METRICS`. Para obtener más información, consulte [la tabla de métricas de InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) en la documentación de MySQL.
+ `RollbackSegmentHistoryListLength`: esta métrica de Amazon CloudWatch mide los registros undo que registran transacciones confirmadas con registros marcados para su eliminación. Estos registros están programados para ser procesados por la operación de depuración de InnoDB. La métrica `trx_rseg_history_len` tiene el mismo valor que `RollbackSegmentHistoryListLength`.
+ `PurgeBoundary`: el número de transacción hasta el que se permite la depuración de InnoDB. Si esta métrica de CloudWatch no aumenta durante periodos de tiempo prolongados, es una buena indicación de que las transacciones de larga duración bloquean la depuración de InnoDB. Para investigar, compruebe las transacciones activas en el clúster de base de datos de Aurora MySQL. Esta métrica solo está disponible para Aurora MySQL versión 2.11 y posteriores, además de la versión 3.08 y posteriores.
+ `PurgeFinishedPoint`: el número de transacción hasta el que se realiza la depuración de InnoDB. Esta métrica de CloudWatch puede ser de utilidad para evaluar la rapidez con la que avanza la depuración de InnoDB. Esta métrica solo está disponible para Aurora MySQL versión 2.11 y posteriores, además de la versión 3.08 y posteriores.
+ `TransactionAgeMaximum`: es la antigüedad de la transacción en ejecución más antigua. Esta métrica de CloudWatch está disponible solo para la versión 3.08 y posteriores de Aurora MySQL.
+ `TruncateFinishedPoint`: el número de transacción hasta el que se realiza la operación de deshacer el truncado. Esta métrica de CloudWatch solo está disponible para Aurora MySQL versión 2.11 y posteriores, además de la versión 3.08 y posteriores.
Para obtener más información sobre las métricas de CloudWatch, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
# La base de datos está creando tablas temporales en el disco
El uso reciente de la tabla temporal en el disco ha aumentado de forma significativa hasta el *porcentaje*. La base de datos está creando alrededor de *número* tablas temporales por segundo. Esto podría afectar al rendimiento y aumentar las operaciones de disco en *db-instance*.
**Topics**
+ [Versiones del motor admitidas](#proactive-insights.temp-tables.context.supported)
+ [Contexto](#proactive-insights.temp-tables.context)
+ [Causas probables de este problema](#proactive-insights.temp-tables.causes)
+ [Acciones](#proactive-insights.temp-tables.actions)
+ [Métricas relevantes](#proactive-insights.temp-tables.metrics)
## Versiones del motor admitidas
Esta información es compatible con todas las versiones de Aurora MySQL.
## Contexto
A veces es necesario que el servidor MySQL cree una tabla temporal interna mientras procesa una consulta. Aurora MySQL puede contener una tabla temporal interna en la memoria, donde puede procesarla TempTable o el motor de almacenamiento MEMORY, o bien InnoDB puede almacenarla en disco. Para obtener más información, consulte [Internal Temporary Table Use in MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) (Uso de tablas temporales internas en MySQL) en *MySQL Reference Manual* (Manual de referencia de MySQL).
## Causas probables de este problema
El aumento de las tablas temporales en disco indica el uso de consultas complejas. Si la memoria configurada no es suficiente para almacenar tablas temporales en la memoria, Aurora MySQL crea las tablas en el disco. Esto puede afectar al rendimiento y aumentar las operaciones en disco.
## Acciones
Recomendamos diferentes acciones en función de las causas.
+ En Aurora MySQL versión 3, le recomendamos que utilice el motor de almacenamiento TempTable.
+ Optimice sus consultas para devolver menos datos. Para ello, seleccione solo las columnas necesarias.
Si activa el esquema de rendimiento con todos los instrumentos `statement` habilitados y cronometrados, puede realizar consultas a `SYS.statements_with_temp_tables` para recuperar la lista de consultas que utilizan tablas temporales. Para obtener más información, consulte [Prerequisites for Using the sys Schema](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) (Requisitos previos para utilizar el esquema sys) en la documentación de MySQL.
+ Considere la posibilidad de indexar las columnas que participan en las operaciones de clasificación y agrupación.
+ Reescriba sus consultas para evitar columnas `BLOB` y `TEXT`. Estas columnas siempre usan el disco.
+ Ajuste los siguientes parámetros de la base de datos: `tmp_table_size` y `max_heap_table_size`.
El valor predeterminado para este parámetro es 16 MiB. Cuando se utiliza el motor de almacenamiento MEMORY para tablas temporales en memoria, su tamaño máximo se define mediante el valor `tmp_table_size` o `max_heap_table_size`, el que sea menor. Cuando se alcanza este tamaño máximo, MySQL convierte automáticamente la tabla temporal interna en memoria en una tabla temporal interna en disco de InnoDB. Para obtener más información, consulte [Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/) (Utilice el motor de almacenamiento TempTable en Amazon RDS para MySQL y Amazon Aurora MySQL).
**nota**
Al crear tablas MEMORY de forma explícita con CREATE TABLE, solo la variable `max_heap_table_size` determina el tamaño al que puede crecer una tabla. Tampoco hay ninguna conversión a un formato en disco.
## Métricas relevantes
Las siguientes métricas de Información sobre el rendimiento están relacionadas con esta información:
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
Para obtener más información, consulte [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) en la documentación de MySQL.