Read Replicas para escalar las lecturas

Las réplicas de lectura son copias de su instancia principal de RDS que reciben actualizaciones mediante replicación asíncrona. A diferencia de la instancia en espera Multi-AZ, las réplicas de lectura están disponibles para consultas SELECT, lo que permite distribuir el tráfico de lectura y reducir la carga de la base de datos principal.

Las réplicas de lectura son compatibles con MySQL, PostgreSQL, MariaDB, Oracle (con Active Data Guard) y todas las ediciones de Aurora. Puede tener hasta 15 réplicas de lectura para Aurora MySQL y Aurora PostgreSQL, y hasta 5 para RDS MySQL/PostgreSQL estándar.

Para crear una réplica de lectura, la instancia de origen debe tener los backups automatizados habilitados (el período de retención debe ser superior a 0). AWS toma una instantánea de la instancia principal, la restaura en una nueva instancia de DB y establece la replicación asíncrona desde la instancia principal.

Cada réplica de lectura obtiene su propio endpoint DNS. Debe actualizar la aplicación para dirigir las lecturas a los endpoints de las réplicas. Los gestores de grupos de conexiones o los frameworks de aplicaciones con separación de lecturas y escrituras pueden dirigir automáticamente las consultas SELECT a las réplicas.

Como la replicación es asíncrona, las réplicas de lectura pueden llevar un retraso de unos milisegundos a varios segundos respecto a la instancia principal, según el volumen de escrituras. Esto se denomina retraso de replicación. Puede supervisarlo mediante la métrica de CloudWatch ReplicaLag.

Las aplicaciones deben diseñarse para tolerar la coherencia eventual al leer desde las réplicas. Por ejemplo, después de insertar un registro, es posible que una lectura inmediata desde una réplica todavía no devuelva la nueva fila. Para garantizar la coherencia de lectura posterior a escritura, esa lectura concreta debe dirigirse de nuevo a la instancia principal.

RDS permite crear réplicas de lectura en una Región de AWS diferente, lo que habilita la escalabilidad de lectura global y la recuperación ante desastres. La replicación entre Regiones utiliza Internet pública o AWS Global Accelerator, y el retraso de replicación es mayor que dentro de una Región debido a la latencia de red.

Las réplicas entre Regiones son útiles cuando desea atender las lecturas más cerca de los usuarios de otra zona geográfica, necesita una copia de recuperación ante desastres activa en otra Región lista para promocionarse o quiere descargar las consultas analíticas de la producción.

Promover una réplica de lectura rompe el vínculo de replicación y la convierte en una instancia de DB principal independiente y con capacidad de escritura. Esto se utiliza en escenarios de recuperación ante desastres cuando la instancia principal original no está disponible, o cuando desea actualizar la réplica a una versión de motor diferente y utilizarla como nueva instancia principal.

La promoción es irreversible: una vez promocionada, la instancia ya no puede volver a ser una réplica. Antes de promoverla, asegúrese de que la réplica esté lo más actualizada posible (con un retraso mínimo) para minimizar la pérdida de datos. Después de la promoción, actualice la cadena de conexión de su aplicación para que apunte al nuevo endpoint principal.

En el examen SAA-C03, es fundamental distinguir las réplicas de lectura de Multi-AZ:

• Si el escenario solicita mejor rendimiento de lectura o escalabilidad de lectura → Read Replicas
• Si el escenario solicita conmutación por error automática o alta disponibilidad → Multi-AZ
• Si el escenario solicita ambas cosas → Multi-AZ en la instancia principal más Read Replicas

Recuerde también: las instancias en espera Multi-AZ NO atienden lecturas; las Read Replicas NO proporcionan conmutación por error automática (para las réplicas que no son de Aurora, debe promoverlas manualmente).

Aurora gestiona las réplicas de lectura de forma diferente a RDS estándar. Aurora utiliza una capa de almacenamiento distribuido compartido, por lo que las réplicas acceden a las mismas páginas de datos subyacentes que la instancia principal. Esto significa que las réplicas de Aurora tienen un retraso de replicación mínimo (normalmente inferior a 100 ms) y que cada una puede atender tráfico de lectura.

Aurora proporciona un Reader Endpoint que distribuye las conexiones entre todas las instancias de réplica disponibles. La aplicación se conecta al Reader Endpoint y Aurora distribuye las lecturas automáticamente. Si una réplica falla, se elimina del grupo de lectores sin afectar al endpoint.

En Aurora, si la instancia principal (de escritura) falla, Aurora promueve automáticamente una de las réplicas de lectura a instancia principal en aproximadamente 30 segundos, mucho más rápido que la conmutación por error Multi-AZ de RDS estándar. La réplica promocionada empieza a aceptar escrituras inmediatamente a través del Cluster Writer Endpoint.

Aurora admite niveles de prioridad de conmutación por error (0–15), para que pueda controlar qué réplica se promociona primero. Asigne una prioridad más alta (nivel 0) a las réplicas que utilicen clases de instancia más grandes o que estén en las AZ preferidas.

Una arquitectura típica de escalabilidad de lectura dirige el tráfico mediante un Application Load Balancer o mediante la lógica de la aplicación:

• Todas las operaciones de escritura (INSERT, UPDATE, DELETE) → endpoint de la DB principal
• Todas las operaciones de lectura (SELECT) → endpoints de las réplicas de lectura o Aurora Reader Endpoint
• Caché de sesión y caché de resultados → ElastiCache (reduce aún más las lecturas en las réplicas)

Para consultas analíticas extremadamente pesadas, considere promover una réplica o utilizar la función parallel query de Aurora para trasladar el procesamiento a la capa de almacenamiento y evitar afectar al clúster de producción.

Entre las métricas clave de CloudWatch para las réplicas de lectura se incluyen:

• ReplicaLag — segundos de retraso respecto a la instancia principal; genere una alerta si aumenta inesperadamente
• ReadIOPS — garantiza que el almacenamiento de la réplica pueda seguir el ritmo de la carga de consultas
• DatabaseConnections — garantiza que la réplica no esté saturada de conexiones
• CPUUtilization — un uso elevado de CPU en la réplica indica que es necesario optimizar las consultas

RDS Performance Insights está disponible en las réplicas de lectura y muestra las principales instrucciones SQL que consumen más tiempo de DB, lo que le ayuda a identificar y optimizar las consultas de lectura costosas.

Casos de uso habituales de las réplicas de lectura de RDS en el examen SAA-C03:

• Informes y análisis: ejecute consultas SELECT pesadas en una réplica para evitar ralentizar las escrituras de producción
• Distribución geográfica: las réplicas entre Regiones atienden a usuarios de otros continentes con menor latencia
• Recuperación ante desastres: una réplica entre Regiones puede promocionarse si falla la Región principal
• Desarrollo y pruebas: promueva una réplica para crear un entorno de pruebas con una copia actual de los datos de producción

Las réplicas de lectura no sustituyen a los backups: mantenga siempre los backups automatizados y las instantáneas manuales de forma independiente.

Ponga a prueba su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que las Read Replicas utilizan replicación asíncrona para distribuir el tráfico de lectura; que el retraso de replicación significa que las réplicas pueden estar ligeramente desfasadas respecto a la instancia principal; y que las réplicas de Aurora tienen un retraso mínimo y admiten la promoción automática. Las réplicas entre Regiones proporcionan tanto escalabilidad de lectura global como una opción de recuperación ante desastres. A continuación, exploraremos la seguridad de RDS mediante el cifrado y los grupos de parámetros.