Hola a todos.
Y bienvenidos de nuevo.
Ahora en este video en una visión general de alto nivel, vamos a discutir acerca de las ideas de Amazon despliegues de
zonas de disponibilidad múltiples también se conoce como despliegues múltiples.
Ahora, antes de hablar con más detalle sobre ello, veamos un desafío típico.
Supongamos que tienes una base de datos que se ejecuta en la zona de disponibilidad, número uno.
Ahora, debido a alguna razón, si esta zona de disponibilidad uno se cae o tal vez el hardware en el que se ejecuta la base
de datos se cae, entonces toda su aplicación se caerá porque el corazón de la aplicación donde
los datos se almacenan principalmente es la base de datos.
Si la base de datos se cae, entonces todo el sitio web puede caer.
Y esto es algo que no se quiere realmente para los entornos de producción.
Y esta es la razón por la que es muy importante que, siempre que se utilicen ideas para la producción,
se eviten los despliegues basados en una sola zona de disponibilidad.
Y la mejor arquitectura es utilizar un despliegue de zonas de disponibilidad múltiple.
Así que en una arquitectura de despliegue basada en múltiples AC, lo que sucede es que tienes la base de datos
primaria aquí y tienes una base de datos secundaria que se está ejecutando en una zona de disponibilidad diferente
de la misma región y hay una replicación que ocurre entre estas dos bases de datos.
Ahora, debido a alguna razón, digamos que la base de datos primaria se cae en estos casos, las ideas redirigirán todas
las peticiones a la instancia stand by.
Muy bien.
Así que este es el proceso automatizado.
Como usuario o como aplicación, no tienes que preocuparte por eso.
Ahora bien, una de las preguntas que se plantea aquí es que en qué escenario tiene lugar esta conmutación por error automatizada
de la instancia primaria a la instancia en espera.
Ahora, antes de mirar en el campo de la condición, vamos a revisar rápidamente que en caso de que haya una interrupción
planificada o no planificada de su instancia de base de datos, entonces esto cambia automáticamente a la réplica en espera en otra
zona de disponibilidad en los despliegues multi AC.
Esto es algo que hemos visto.
Ahora veamos algunas de las condiciones.
La primera es que si hay una pérdida de disponibilidad en la zona de disponibilidad primaria.
En segundo lugar, si hay una pérdida de conectividad de red a la instancia primaria, si hay un fallo de la unidad de cálculo
en la instancia primaria, de nuevo, la condición de conmutación por error tiene lugar.
Si hay un fallo de almacenamiento en la instancia primaria de la base de datos en estos casos, también tiene lugar la conmutación por error
automatizada.
Y cuando miramos el tiempo de conmutación por error, suele oscilar entre 60 y 1 y 20 segundos.
Ahora, hagamos una cosa.
Vamos a entender esto desde la perspectiva de la demostración para que nuestro concepto sea claro.
Ahora, para la demostración de hoy, tengo una base de datos que se crea sobre la base de la implementación de multi AC.
El nombre de la base de datos es Demo DB, Multi AC.
Ahora, si miras en esta base de datos específica, déjame ir a la configuración.
Bajemos un poco.
Se ve que dice que el multi AC está habilitado por lo que está indicando que sí.
Así que vamos a ver cómo funciona exactamente.
Así que vamos a ir a la conectividad aquí.
Permítanme copiar el punto final de la instancia de IDs.
Y vamos a hacer rápidamente una búsqueda para ver cuál es la dirección IP que se devuelve aquí.
La dirección IP es una 7231 37. 32.
Así que en esta etapa, si tengo que mostrarte esto en términos de diagrama, puedes considerar que esta dirección
IP que ha sido devuelta es la de la instancia primaria aquí.
Ahora, para la perspectiva de la demostración, vamos a hacer una conmutación por error y vamos a ver cómo la dirección IP cambia a la de
la instancia secundaria.
Así que vamos a hacer una cosa.
Sigamos adelante y reiniciemos la instancia de la base de datos.
Ahora, cada vez que reinicie, tendrá la opción de reiniciar con Failover.
Así que vamos a hacer una confirmación.
Así que esto es sólo una forma sencilla de identificar cómo funciona el despliegue de CA múltiple en escenarios del mundo real.
En caso de que haya un problema relacionado con la red y toda la conmutación por error se produzca automáticamente, no tiene
que preocuparse por ello.
Así que déjame hacer una confirmación rápida.
Muy bien.
Así que la reconstrucción se está llevando a cabo.
Así que esperemos rápidamente un momento aquí.
Así que en la actualización, nuestro estado está ahora disponible.
Ahora, en esta etapa, si usted realiza la búsqueda de NSS de nuevo para encontrar la dirección IP asociada con la instancia
de la base de datos, esta vez verá que la dirección IP es diferente.
Antes era un 7231 3732 ahora es un 7231 79. 1 47.
Así que detrás de las escenas RDC ha redirigido automáticamente la solicitud a la instancia de espera aquí.
Ahora, una cosa importante que hay que señalar es que la URL del punto final que estamos discutiendo
aquí, esto sigue siendo el mismo.
Así que incluso si la base de datos primaria se cae y si las peticiones van a este punto final, las ideas dirigirán
automáticamente la petición a la instancia en espera.
Y esta es la razón por la que la alta disponibilidad oral funciona en una arquitectura basada en multi AC.