amazon web services - pricing - ¿Por qué AWS RDS Aurora tiene la opción de "Implementación Multi-AZ" cuando ya se realiza la replicación en diferentes zonas de forma predeterminada?
price amazon aurora (2)
Aurora replica sus datos en tres zonas de disponibilidad, en la capa de almacenamiento ... pero la instancia del servidor de la base de datos, en sí misma, sigue siendo una máquina virtual que se ejecuta en una sola máquina física que se encuentra en una única zona de disponibilidad.
La capa de almacenamiento de Aurora está fuera de esa instancia y puede permitir que el acceso continúe sin interrupciones sin pérdida de datos, incluso en el caso de la pérdida de hasta dos AZ, pero la pérdida de la zona que contiene la instancia de db todavía causará una interrupción usted, si solo tiene una única instancia de Aurora en su grupo (1 maestro, 0 réplicas). La pérdida de una zona de disponibilidad completa es una de esas cosas que es altamente improbable pero no imposible. Su instancia de db sigue siendo un único punto de error cuando solo tiene uno.
Multi-AZ permite una instancia de base de datos redundante completa, en una AZ diferente, que automáticamente asumirá el control de la primaria en un minuto, si funciona según lo diseñado, en caso de pérdida de la AZ que aloja la instancia primaria o un evento catastrófico. fallo de la instancia primaria. Es una segunda máquina virtual, en una segunda máquina física, en una segunda zona de disponibilidad. Siempre se está ejecutando, pero no se puede acceder. Está en segundo plano, gestionado y supervisado por la infraestructura RDS, pero solo es accesible para usted en caso de error de la instancia principal. La máquina secundaria también se puede usar para reducir el tiempo de inactividad en el caso de una actualización de software o un evento de mantenimiento en el primario. Cuando se produce la conmutación por error, si está utilizando DNS para conectarse a su base de datos (como debería), encontrará que la entrada de DNS se apunta automáticamente a la secundaria.
Contraste esto con una réplica de lectura, que es accesible todo el tiempo y, por lo tanto, puede proporcionar un beneficio significativo en el rendimiento, al permitir la descarga de lecturas. Pasar por una réplica implica promocionarla para que se convierta en un maestro independiente (que la separa permanentemente de su propio maestro anterior) y reconfigurar su aplicación para usar el punto final alternativo. Esto, por supuesto, es aún más rápido que recuperarse de una falla en el maestro al usar una instantánea de un punto en el tiempo para crear una instancia maestra de reemplazo.
Al iniciar una instancia de Aurora, tengo la opción de "Implementación Multi-AZ", que se describe como "Especifica si la instancia de base de datos debe tener un modo de espera desplegado en otra zona de disponibilidad".
Sin embargo, la documentación de Aurora indica que Aurora ya distribuye automáticamente la base de datos en diferentes zonas de disponibilidad.
Además, ¿cuál es la diferencia entre un standby Aurora Multi-AZ y una réplica Aurora normal? ¿Es eso que una réplica ordinaria puede leerse al aumentar el rendimiento, mientras que no se puede leer desde un modo de espera?
El almacenamiento en Aurora se replica en tres zonas de disponibilidad. El nodo principal de la base de datos es una sola instancia. Entonces, mientras sus datos se distribuyen en múltiples objetivos, el nodo principal no lo está.
Cuando habilita una implementación de varios AZ, creamos una réplica de lectura Aurora que está disponible como un destino de conmutación por error. Las réplicas de lectura Aurora que cree (hasta un máximo de 15 en este momento) también están disponibles como destinos de conmutación por error.
No hay ninguna diferencia significativa entre Multi-AZ y otras réplicas de Aurora. Esto es principalmente una simplificación en la interfaz de usuario para los clientes acostumbrados a usar Multi-AZ para otros motores RDS.