¿Cómo soluciono los problemas cuando uso réplicas de lectura en mi instancia de base de datos compatible con Aurora MySQL?

Resolución

Promoción de una réplica de lectura compatible con Aurora MySQL

Si la instancia de escritor requiere un reinicio o mantenimiento, realiza una conmutación por error manual para promover una réplica de lectura como instancia de escritor.

Para realizar una conmutación por error manual, sigue estos pasos:

1. Abre la consola de Amazon Aurora y RDS.
2. En el panel de navegación, selecciona Bases de datos.
3. Selecciona la instancia de escritor para tu clúster de base de datos de Aurora.
4. Selecciona Acciones y, a continuación, Conmutación por error.

La instancia compatible con Aurora MySQL conmuta por error automáticamente a una instancia de réplica de lectura si la instancia de escritor deja de estar disponible. Una instancia de escritor puede dejar de estar disponible por varios motivos, como la contención de recursos o la actividad de mantenimiento.

Si tienes varios lectores, puedes especificar un nivel de prioridad de promoción para cada instancia que se encuentra en tu clúster. Cuando se produce un error en la instancia de escritor, la instancia compatible con Aurora MySQL promociona la réplica con la máxima prioridad como nuevo escritor.

También puedes promocionar una réplica de Aurora entre regiones de AWS como clúster de base de datos independiente. La replicación entre regiones se detiene cuando se inicia el proceso de promoción. El clúster promocionado funciona como clúster de base de datos independiente y administra tanto las operaciones de lectura como las de escritura.

Medición del retraso en la replicación

Dado que todas las instancias de base de datos de Aurora en un clúster de base de datos comparten un volumen de datos común, el retraso en la replicación es mínimo. Sin embargo, es posible que experimentes un retraso ligeramente mayor en los lectores en algunos casos.

Nota: Las réplicas entre regiones utilizan la replicación de registros binarios. Las velocidades de modificación y aplicación, así como los retrasos en la comunicación de red entre las regiones seleccionadas, pueden afectar a las réplicas entre regiones. Las réplicas entre regiones que utilizan bases de datos de Aurora MySQL tienen un retraso típico de menos de 1 segundo.

Utiliza las siguientes métricas de Amazon CloudWatch para medir el retraso en la replicación:

• La métrica AuroraReplicaLag mide el retraso de la réplica entre el nodo escritor y el lector en la misma región en milisegundos.
• La métrica AuroraBinlogReplicaLag mide el retraso de la réplica entre los clústeres de base de datos de Aurora que utilizan registros binarios.

Para obtener más información sobre las métricas anteriores, consulta Métricas de nivel de instancia para Amazon Aurora.

Mejora del rendimiento de la replicación

Haz lo siguiente:

• Para evitar cargas de trabajo pesadas en las instancias del lector, se recomienda que todas las instancias de un clúster tengan el mismo tamaño. Si la instancia del lector es más pequeña que la del escritor, el volumen de cambios es excesivo para que el lector pueda ponerse al día.
  Nota: Si la instancia del escritor soporta una gran carga de trabajo, es posible que observes un retraso temporal de la réplica de lectura. El retraso se reduce cuando la instancia del lector alcanza la instancia del escritor.
• Para evitar retrasos en la replicación cuando hay transacciones de larga duración en curso, ejecuta las transacciones en lotes más pequeños y ejecuta confirmaciones con frecuencia.

Para obtener información sobre cómo usar la replicación de MySQL basada en registros binarios nativos para solucionar el retraso de la réplica, consulta Problemas de replicación de Amazon Aurora MySQL.

Solución de problemas por un retraso elevado en la replicación

Utiliza la métrica AuroraReplicaLag de CloudWatch para comprobar si el retraso en la replicación es elevado. Un retraso elevado en la replicación puede provocar el reinicio de una instancia de lector. Para resolver este problema, consulta ¿Por qué mi réplica de lectura de Amazon Aurora se ha retrasado y reiniciado?

Configuración de la replicación basada en GTID

Aurora no utiliza la replicación nativa basada en registros binarios para replicar datos en las instancias de réplica de lectura. No puedes usar un identificador de transacción global (GTID) para replicar datos entre instancias en el mismo clúster. Sin embargo, puedes configurar la replicación basada en GTID en algunos casos. Para obtener más información sobre cómo usar la replicación basada en GTID de forma compatible con Aurora MySQL, consulta Amazon Aurora for MySQL compatibility now supports global transaction identifiers (GTIDs) replication (La compatibilidad de Amazon Aurora para MySQL ya admite la replicación de identificadores de transacciones globales [GTID]).

Para las versiones 3.04 y posteriores compatibles con Aurora MySQL, la replicación de registros binarios de varios procesos está activada y replica_parallel_workers se establece en 4 de forma predeterminada. Como la replicación de registros binarios de varios procesos está activada, debes aumentar la resiliencia de la base de datos ante una parada inesperada. Se recomienda activar la replicación de GTID en el origen y permitir GTID en la réplica.

Nota: Puedes configurar la replicación basada en GTID entre Amazon Relational Database Service (Amazon RDS) para MySQL y un clúster de Aurora y entre clústeres de Aurora. El origen debe ser un servidor principal externo. Antes de iniciar el proceso de replicación, asegúrate de activar el registro binario en el origen.

Para obtener más información sobre los GTID, consulta GTID format and storage (Formato y almacenamiento de GTID) en el sitio web de MySQL.

Información relacionada

Replicación de clústeres de base de datos de Amazon Aurora MySQL en Regiones de AWS

Replicación con Amazon Aurora