¿Cómo soluciono los problemas que provocan que mi réplica de lectura de Aurora se retrase y se reinicie?

Solución

Nota: La siguiente resolución se aplica a los clústeres de Aurora en un único clúster principal de base de datos regional y global de AWS, no a los clústeres secundarios de bases de datos globales.

Medición de AuroraReplicaLag

Las réplicas de Aurora se conectan al mismo volumen de almacenamiento que la instancia de escritura. Aurora escribe de forma sincrónica los cambios en el volumen de almacenamiento compartido, pero replica de forma asincrónica los cambios en las instancias del lector. Para mantener la coherencia de lectura, Aurora invalida los datos que están en caché en la memoria relacionados con el cambio. La memoria caché de datos incluye el grupo de búferes o la memoria caché de la página.

En algunos casos, puede producirse un retraso al propagar los cambios entre las instancias del lector. El retraso aparece como un aumento en la métrica AuroraReplicaLag en Amazon CloudWatch que puede provocar reinicios, y es posible que recibas el siguiente mensaje de error:

"Read Replica has fallen behind the master too much. Restarting".

Para la edición de Amazon Aurora compatible con MySQL, ejecuta la siguiente consulta en la tabla INFORMATION_SCHEMA.REPLICA_HOST_STATUS para medir AuroraReplicaLag:

select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID', 'writer', 'reader') as Role, replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

Resultado de ejemplo:

+---------------------+--------+-------------------+  
| Instance_Identifier | Role   | AuroraReplicaLag  |  
+---------------------+--------+-------------------+  
| myamscluster-aza-1  | writer |                 0 |  
| myamscluster-azb-1  | reader | 5.150000095367432 |  
| myamscluster-aza-2  | reader | 5.033999919891357 |  
+---------------------+--------+-------------------+

Para la edición de Amazon Aurora compatible con PostgreSQL, ejecuta la siguiente consulta para obtener la función aurora_replica_status() y filtrar los resultados:

select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

Resultado de ejemplo:

server_id          | role   | aurorareplicalag  
-------------------+--------+------------------  
myapgcluster-aza-1 | Reader | 19.641  
myapgcluster-azb-1 | Reader | 19.752  
myapgcluster-aza-2 | Writer |  
(3 rows)

Asegurarse de que todas las instancias del clúster tienen la misma especificación

Si una instancia de lector tiene una configuración de clases de instancia de base de datos inferior a la de una instancia de base de datos de escritor, es posible que la cantidad de cambios sea demasiado grande. En ese caso, la instancia del lector no se puede invalidar en la caché. Para evitar este problema, se recomienda mantener la misma especificación para todas las instancias de base de datos del clúster de Aurora.

Supervisión de las sesiones con métricas y supervisión mejorada

Cuando ejecutas varias sesiones al mismo tiempo, una instancia de lector puede retrasarse. Una réplica de Aurora puede aplicar lentamente los cambios necesarios desde el escritor debido a la falta de recursos disponibles. Para comprobar el retraso, consulta las métricas CPUUtilization, DBConnections y NetworkReceiveThroughput. También puedes activar la supervisión mejorada con una granularidad de 1 o 5 segundos para obtener el uso de los recursos en el lector. También puedes activar Información de rendimiento y usar Database Insights para visualizar la carga de trabajo del lector. En el caso de Aurora compatible con PostgreSQL, puedes usar la métrica ReadIOPS.

Importante: Información de rendimiento llegará al final de su ciclo de vida el 30 de junio de 2026. Puedes actualizar al modo avanzado de Database Insights antes del 30 de junio de 2026. Si no actualizas, los clústeres de bases de datos que utilizan Información de rendimiento adoptarán de forma predeterminada el modo estándar de Database Insights. Solo el modo avanzado de Database Insights admitirá los planes de ejecución y el análisis bajo demanda. Si los clústeres utilizan el modo estándar de forma predeterminada, es posible que no puedas usar estas características en la consola. Para activar el modo avanzado, consulta Activación del modo avanzado de Database Insights para Amazon RDS y Activación del modo avanzado de Database Insights para Amazon Aurora.

Uso de CloudWatch para visualizar la actividad de escritura

Un aumento repentino de la actividad de escritura en un clúster de producción que ya tiene muchas escrituras puede sobrecargar la instancia de base de datos del escritor. La sobrecarga puede provocar que las instancias del lector se retrasen. Utiliza CloudWatch para ver las métricas DMLThroughput, DDLThroughput y Queries que muestran ráfagas repentinas. En el caso de Aurora compatible con PostgreSQL, consulta la métrica WriteThroughput.

Solución de problemas de transacciones de larga duración de Aurora compatible con MySQL

El motor InnoDB de MySQL usa un control de simultaneidad multiversión (MVCC) de forma predeterminada. Por lo tanto, debes realizar un seguimiento de todos los cambios en las filas que se hayan producido durante la duración de una transacción. Una vez finalizadas las transacciones de larga duración, comienza un aumento en la actividad de los subprocesos de purga. La purga repentina puede provocar que una réplica de Aurora se retrase debido al volumen de trabajo atrasado que crean las transacciones de larga duración.

En el caso de Aurora compatible con MySQL, consulta la métrica RollbackSegmentHistoryListLength en CloudWatch para ver el aumento de la purga. Puedes ejecutar el comando SHOW ENGINE INNODB STATUS para ver la purga. O bien ,ejecuta la siguiente consulta:

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

Resultado de ejemplo:

+----------------------------------+-------+  
| RollbackSegmentHistoryListLength | COUNT |  
+----------------------------------+-------+  
| trx_rseg_history_len             |   358 |  
+----------------------------------+-------+  
1 row in set (0.00 sec)

Configura las alarmas de CloudWatch para supervisar RollbackSegmentHistoryListLength y asegurarte de que no alcance un número elevado. Es una práctica recomendada para evitar transacciones de larga duración en las bases de datos relacionales.

Evitar breves interrupciones de la red

Aunque son poco frecuentes, pueden producirse errores transitorios en la comunicación de red entre las instancias del escritor y el lector, o entre una instancia y la capa de almacenamiento de Aurora. Las instancias del lector pueden retrasarse o reiniciarse debido a una breve interrupción en la red. La réplica de Aurora también puede retrasarse debido a que una gran cantidad de cambios sobrecargaron el ancho de banda de la red de la instancia. Para evitar este problema, se recomienda modificar el tamaño de la instancia de base de datos a un tamaño que pueda soportar la cantidad de cambios.

Información relacionada

Adición de réplicas de Aurora a un clúster de base de datos

Replicación con Amazon Aurora compatible con MySQL

Supervisión de métricas en un clúster de Amazon Aurora

Métricas de nivel de instancia para Amazon Aurora