¿Por qué mi instancia de base de datos de Amazon RDS for MySQL está atascada en “Reiniciar”?

Última actualización: 28/10/2021

Intento reiniciar mi instancia de base de datos Amazon Relational Database Service (Amazon RDS) para MySQL. Sin embargo, mi instancia de base de datos está atascada en el estado “Reiniciar” o el reinicio tarda más de lo esperado. ¿Por qué sucede esto y cómo puedo resolverlo?

Descripción corta

Antes de reiniciar, asegúrese de detener todas las transacciones entrantes o en curso en la instancia de base de datos. Las transacciones en curso se detendrán y las transacciones no comprometidas se revertirán.

Nota: La restauración de transacciones no comprometidas puede ser una operación costosa. Las transacciones no comprometidas también pueden tardar mucho en completarse antes de que la instancia de Amazon RDS for MySQL vuelva a estar disponible.

Una vez iniciado el reinicio, el proceso no se puede cancelar y el reinicio continuará hasta que se complete. Si el reinicio tarda más de lo esperado, investigue la causa principal y considere los siguientes enfoques de solución de problemas:

  • Verifique si hay consultas en curso.
  • Verifique si hay transacciones sin purgar.
  • Revise el archivo de registros de errores de MySQL.

Resolución

Verifique si hay consultas en curso

Utilice el comando SHOW FULL PROCESSLIST para verificar si hay consultas activas en la instancia de Amazon RDS for MySQL:

mysql> SHOW FULL PROCESSLIST;

A continuación se muestra un resultado de ejemplo que indica que una consulta UPDATE todavía está en curso:

+-----+---------------+---------------------+------+---------+------+----------+-----------------------+
| Id  | User          | Host                | db   | Command | Time | State    | Info                  |
+-----+---------------+---------------------+------+---------+------+----------+-----------------------+
|   2 | rdsadmin      | localhost:30662     | NULL | Sleep   |    4 |          | NULL                  |
| 101 | admin         | 172.31.28.252:58288 | NULL | Query   |  111 | updating |UPDATE tutorials SET tu|
+-----+---------------+---------------------+------+---------+------+----------+-----------------------+

El resultado proporciona información sobre los subprocesos de MySQL que se ejecutan en la base de datos. Si hay consultas que todavía se están ejecutando, permita que se completen antes de reiniciar el sistema.

Nota: Ejecute la consulta SHOW FULL PROCESSLIST como usuario maestro. Si no es el usuario maestro, debe tener privilegios de administración del servidor MySQL para ver todos los subprocesos activos en la instancia de MySQL. De lo contrario, el resultado solo muestra los ID de subprocesos activos en la cuenta MySQL del usuario. Para obtener más información, consulte la instrucción SHOW PROCESSLIST y la administración del servidor MySQL en el sitio web de MySQL.

Verifique si hay transacciones sin purgar

El motor InnoDB de MySQL utiliza el control de concurrencia multiversión (MVCC) que mantiene una lista de versiones antiguas de filas modificadas durante una transacción. Si se debe revertir una transacción, InnoDB puede realizar cualquier operación de deshacer durante este proceso. Las versiones antiguas de las filas se capturan dentro del espacio de deshacer. Estas versiones antiguas se purgan cuando ya no se les llama durante una transacción. Si los cambios capturados no se purgan porque una transacción sigue haciendo referencia a ellos, la longitud de la lista del historial puede aumentar. Para obtener más información, consulte Control de versiones múltiples de InnoDB en el sitio web de MySQL.

Las transacciones sin purgar se representan como el valor de la longitud de la lista del historial. Este valor se encuentra en “TRANSACTIONS” en el resultado del comando SHOW ENGINE INNODB STATUS. Tenga en cuenta que la longitud de la lista del historial suele ser de un valor bajo, aunque una carga de trabajo con mucha escritura o transacciones de larga duración pueden hacer que el valor aumente. Para obtener más información sobre el valor de la longitud de la lista del historial, consulte Configuración de purga en el sitio web de MySQL.

Para verificar si hay transacciones sin purgar dentro de la longitud de la lista del historial, utilice el comando SHOW ENGINE INNODB STATUS. El resultado de este comando también le permite ver el tamaño de la longitud de la lista del historial y de cualquier transacción en curso que aparezca en la sección “TRANSACTIONS”. Para obtener más información sobre cómo revisar las transacciones listadas, consulte el resultado del monitoreo estándar y del monitoreo de bloqueo de InnoDB en el sitio web de MySQL.

Por ejemplo:

------------
TRANSACTIONS
------------
Trx id counter 105746959
Purge done for trx's n:o < 105746958 undo n:o < 0 state: running but idle
History list length 32
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 328605240396520, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 328605240395600, not started
0 lock struct(s), heap size 1136, 0 row lock(s)

Nota: Si la longitud de la lista del historial tiene un valor elevado y hay transacciones activas, no es una práctica recomendada reiniciar el sistema.

Para obtener más información, consulte SHOW ENGINE INNODB STATUS en el sitio web de MySQL.

Revise el archivo de registros de errores de MySQL

En Amazon RDS, el archivo de registros de errores de MySQL está habilitado de forma predeterminada. Si sospecha que la instancia de RDS está tardando demasiado en volver a estar disponible, revise el contenido del archivo de registros de errores de MySQL. MySQL escribe en el archivo de registros de errores cuando se inicia, se apaga o cuando encuentra algún error.

Por ejemplo, InnoDB podría tener que revertir cualquier transacción no comprometida como parte del proceso de recuperación de fallos de InnoDB. Si se revierten transacciones sin consignar, el registro de errores de MySQL documenta este evento. Para obtener más información, consulte Recuperación de fallos de InnoDB en el sitio web de MySQL.

Soluciones de problemas adicionales

Nota: Si decide realizar una recuperación a un momento dado (PITR) o restaurar a partir de una instantánea, es posible que la nueva instancia de Amazon RDS no esté disponible de inmediato. Para obtener más información, consulte los siguientes artículos:

Si la instancia de base de datos de Amazon RDS for MySQL se reinicia durante un tiempo, pruebe estos consejos adicionales para la solución de problemas:

  • Si la instancia de base de datos tiene habilitadas las copias de seguridad automatizadas, realice un PITR para restaurar en una nueva instancia de Amazon RDS a partir de un momento determinado. Puede restaurar en cualquier momento durante el periodo de retención de copia de seguridad.
    Nota: De forma predeterminada, las instancias de base de datos restauradas están asociadas al parámetro de base de datos y a los grupos de opciones predeterminados. Sin embargo, puede utilizar un grupo de parámetros y un grupo de opciones personalizados si los especifica durante una restauración.
  • Restaure su instancia de base de datos desde la instantánea de base de datos más reciente creando una nueva instancia de base de datos. Puede utilizar la instancia de base de datos restaurada tan pronto como su estado esté disponible.
  • Si su instancia de base de datos tiene una réplica de lectura, promueva la réplica de lectura para que se convierta en una instancia de base de datos independiente. Al promover una réplica de lectura, la instancia de base de datos se reinicia automáticamente antes de que esté disponible.

También es una práctica recomendada monitorear regularmente la actividad de la base de datos. Puede monitorear la instancia de base de datos de Amazon RDS for MySQL mediante las siguientes herramientas:

  • Amazon CloudWatch: con Amazon CloudWatch, puede monitorear cualquier carga de trabajo de base de datos en curso. Si observa valores altos en las conexiones de base de datos, la utilización de la CPU o las IOPS de escritura y lectura, es posible que haya una actividad en curso en la instancia de base de datos.
  • Monitoreo mejorado: el monitoreo mejorado requiere permiso para enviar información de métricas del sistema operativo a CloudWatch Logs. Puede conceder permisos de monitoreo mejorado mediante un rol de AWS Identity and Access Management (IAM). Antes de habilitar el monitoreo mejorado, primero debe crear un rol de IAM.
  • Información sobre rendimiento: Performance Schema es una herramienta de rendimiento opcional utilizada por Amazon RDS for MySQL (o MariaDB). Si habilita o desactiva Información sobre rendimiento, no tendrá que reiniciar la instancia de base de datos. Tampoco experimentará ningún tiempo de inactividad ni conmutación por error.

¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?