¿Por qué la réplica de lectura de mi Amazon Aurora se ha retrasado y se ha reiniciado?

Descripción corta

AuroraReplicaLag es una medida del retraso en milisegundos al replicar los cambios de la instancia de escritura de base de datos de Aurora en las instancias del lector del clúster de base de datos de Aurora. Las réplicas de Aurora se conectan al mismo volumen de almacenamiento que la instancia de escritura. Para medir el retraso entre las instancias de escritor y lector, utilice la métrica AuroraReplicalAg en Amazon CloudWatch.

Para un clúster de base de datos de Aurora, la métrica AuroraReplicalAg indica el retraso de la caché de datos de la réplica de Aurora en comparación con la instancia de base de datos de escritura. La memoria caché de datos incluye el grupo de búferes o la memoria caché de la página. Los cambios se escriben de forma sincrónica en el volumen de almacenamiento compartido. Sin embargo, los cambios se replican de forma asincrónica en las instancias del lector, donde cualquier dato almacenado en la memoria que esté relacionado con el cambio se invalida para garantizar la coherencia de la lectura. En algunos casos, puede haber un retraso al propagar los cambios entre las instancias del lector. Este retraso aparece como un aumento en la métrica AuroraReplicalAg en CloudWatch, lo que puede provocar reinicios eventuales.

Puede medir los metadatos casi en tiempo real sobre AuroraReplicalag:

Para la edición compatible con Amazon Aurora MySQL, seleccione una opción de la tabla INFORMATION_SCHEMA.REPLICA_HOST_STATUS:

mysql> 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;

+---------------------+--------+-------------------+
| 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 compatible con Amazon Aurora PostgreSQL, llame a la función aurora_replica_status() y filtre los resultados:

postgres=> 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();

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

Nota: La solución que se proporciona en este artículo se aplica a los clústeres principales de Global Database y a los de una sola región de Amazon Aurora, pero no a los clústeres secundarios de Global Database.

Resolución

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

Si una instancia de lector tiene una configuración de clase de instancia de base de datos más débil que la instancia de base de datos de escritor, el volumen de cambios puede ser demasiado grande. En ese caso, la instancia de lector no puede invalidarse en la memoria caché y luego ponerse al día. Por lo tanto, se recomienda que todas las instancias de base de datos del clúster de Aurora tengan la misma especificación.

Supervisar las sesiones mediante métricas y supervisión mejorada

Una instancia de lector puede experimentar un retraso cuando se ejecutan varias sesiones al mismo tiempo. Una réplica de Aurora puede tardar en aplicar los cambios necesarios por parte del escritor porque no hay recursos disponibles. Puede ver este retraso en métricas como CPUUtilization, DBConnections y NetworkReceiveThroughput. También puede activar la supervisión mejorada con una granularidad de 1 o 5 segundos para comprender el uso de los recursos en el lector. Además, puede utilizar Información sobre rendimientopara visualizar su carga de trabajo. Además, solo para la edición compatible con Aurora PostgreSQL, utilice la métrica ReadIOPS.

Consultar la actividad de escritura con CloudWatch

Un aumento repentino de la actividad de escritura en un clúster de producción que ya tiene muchas escrituras puede provocar una sobrecarga en la instancia de base de datos del escritor. El estrés adicional provocado por el aumento puede provocar que una o más instancias del lector se retrasen. Puede verlo en CloudWatch, que muestra ráfagas repentinas de las métricas DMLThroughput, DDLThroughput y Queries.

Para Aurora PostgreSQL, puede consultar la métrica WriteThroughput.

Investigar el aumento de lista de historial (HLL) (compatibles con Aurora MySQL-Compatible)

El motor InnoDB de MySQL incorpora un control de concurrencia multiversión (MVCC) de forma predeterminada. Esto significa que debe realizar un seguimiento de todos los cambios que se hayan producido en todas las filas afectadas a lo largo de una transacción. Una vez finalizadas las transacciones de larga duración, comienza un aumento en la actividad de los subprocesos de purga. Debido al volumen de atrasos generado por transacciones de larga duración, la purga repentina puede provocar que una réplica de Aurora se quede atrasada.

En las versiones 1.19.2, 2.06 y superiores, Aurora MySQL incluye la métrica RollbackSegmentHistoryListLength. Puede usar esta métrica en CloudWatch para ver esta purga. Esto también se puede ver en el resultado de SHOW ENGINE INNODB STATUS o consultando el esquema de información de la siguiente manera:

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

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

Configure alarmas de CloudWatch para supervisar esta métrica de modo que no alcance un número excesivamente alto. Es una práctica recomendada en las bases de datos relacionales para evitar transacciones de larga duración.

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 quedarse atrás debido a la saturación del ancho de banda de la red de la instancia debido a un gran volumen de cambios. Para evitar este problema, se recomienda tener en cuenta el tamaño de la instancia de base de datos y, por lo tanto, sus capacidades de red.

---

Información relacionada

Agregar réplicas de Aurora a un clúster de base de datos

Replicación de un usuario maestro único con Amazon Aurora MySQL

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