¿Cómo puedo resolver problemas comunes al utilizar réplicas de lectura en Amazon Aurora?

Descripción corta

Amazon Aurora MySQL admite réplicas de lectura que comparten un volumen subyacente común con una instancia de base de datos del escritor en la misma región de AWS. Si cambia la instancia de base de datos del escritor, las actualizaciones estarán visibles para las instancias de réplica en el clúster de base de datos. También puede crear réplicas de lectura de MySQL entre regiones. Estas se implementan mediante el motor de replicación basado en registros binarios de MySQL.

Se recomienda utilizar réplicas de Aurora al escalar las operaciones de lectura. Para ello, reduzca la carga de trabajo de lectura del escritor. A continuación, aumente la disponibilidad para gestionar los eventos que ralentizan o bloquean el escalamiento.

Resolución

¿Cómo puedo promocionar una réplica de lectura de Aurora?

Conmutación por error manual: realice una conmutación por error manual para promover otra instancia de réplica de lectura como instancia de escritura siguiendo estos pasos:

1. Inicie sesión en la consola de Amazon Relational Database Service (Amazon RDS).
2. En el panel de navegación, seleccione Bases de datos.
3. Elija la instancia de escritor para su clúster de base de datos de Aurora.
4. Elija Acciones y, a continuación, Conmutación por error.

Conmutación por error automática: Aurora conmuta por error automáticamente a una instancia de réplica de lectura si la instancia del escritor deja de estar disponible. Esto puede ocurrir por varias razones, incluida la contención de recursos y la actividad de mantenimiento. Si tiene varios lectores, puede asignar un nivel de prioridad de promoción a cada instancia de su clúster. Cuando se produce un error en la instancia del escritor, Aurora promociona la réplica con la máxima prioridad como nuevo escritor.

También puede promocionar una réplica de Aurora entre regiones como un clúster de base de datos independiente. La replicación entre regiones se detiene después de iniciar el proceso de promoción. El clúster recién promocionado funciona como un clúster de base de datos independiente y gestiona las operaciones de lectura y escritura.

¿Cómo puedo medir el retraso de replicación?

Dado que todas las instancias de base de datos de Aurora de un único clúster de base de datos comparten un volumen de datos común, el retraso en la replicación es mínimo. Por lo general, los retrasos oscilan alrededor de los 10 milisegundos. Sin embargo, es posible que observe un ligero aumento del retraso en los lectores en algunas circunstancias específicas.

Nota: Las réplicas entre regiones utilizan la replicación lógica y se verán afectadas por la tasa de cambios o aplicaciones y por los retrasos en la comunicación de red entre las regiones específicas seleccionadas. Las réplicas entre regiones que utilizan bases de datos de Aurora suelen tener un retraso de menos de un segundo.

Puede usar las siguientes métricas de Amazon CloudWatch para medir el retraso de replicación:

• Utilice AuroraReplicaLag para medir el retraso de la réplica del nodo entre el escritor y el lector en milisegundos (misma región).
• Utilice AuroraBinLogReplicalAg para medir el retraso de la réplica entre los clústeres de base de datos de Aurora mediante registros binarios.

¿Cómo puedo mejorar el rendimiento de la replicación?

Siga estas recomendaciones para mejorar el retraso de la réplica:

• Si la instancia del lector es más pequeña que la del escritor, es posible que el volumen de cambios sea excesivo para que el lector pueda ponerse al día. Se recomienda que todas las instancias de un clúster tengan el mismo tamaño para evitar cualquier sobrecarga de trabajo en las instancias del lector.
• Si el escritor tiene una gran carga de trabajo, es posible que observe un retraso temporal en la lectura de la réplica. El retraso se reduce cuando la instancia del lector alcanza la instancia del escritor.
• Si hay transacciones de larga duración en curso, puede observar un retraso de la réplica en los lectores. Para evitar el retraso de la réplica, ejecute las transacciones en lotes más pequeños y ejecute las confirmaciones con más frecuencia.

Para obtener más información sobre la solución de problemas con los retrasos de réplica elevados mediante la replicación nativa de MySQL basada en registros binarios, consulte Descripción general del proceso de copia de seguridad y restauración de un clúster de base de datos de Aurora.

¿Puedo usar un identificador de transacción global (GTID)?

Un identificador de transacción global es una cadena única que se asocia a una transacción en su confirmación. Cada GTID es único en todos los servidores y los cambios se aplican en destino en función del valor del GTID. Para obtener más información, consulte la documentación de MySQL sobre los conceptos de GTID.

Aurora no utiliza la replicación nativa basada en registros binarios para replicar datos con el fin de leer las instancias de réplica. No se puede usar GTID para replicar datos entre instancias del mismo clúster. Sin embargo, puede configurar la replicación basada en GTID en ciertos escenarios. Para obtener más información sobre el uso de la replicación basada en GTID en Aurora MySQL, consulte el blog de AWS sobre GTID.

Nota: Puede configurar la replicación basada en GTID entre una Amazon RDS MySQL y un clúster de Aurora, así como entre clústeres de Aurora (al asumir que el origen es un maestro externo). Asegúrese de habilitar los registros binarios en origen antes de iniciar el proceso de replicación.

---

Información relacionada

Replicación con Amazon Aurora

¿Qué es Amazon Aurora?