Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La alta disponibilidad dentro de la región (HA) evita el tiempo de inactividad de la base de datos manteniendo réplicas de respaldo de cada fragmento en un clúster. Si un fragmento deja de responder por cualquier motivo, Azure DocumentDB redirige las conexiones entrantes del fragmento caído a su fragmento en espera. Cuando se produce la conmutación por error, las particiones promocionadas siempre tienen datos nuevos a través de la replicación sincrónica.
Todas las particiones principales de un clúster se aprovisionan en una zona de disponibilidad (AZ) para mejorar la latencia entre las particiones. Las particiones en espera se aprovisionan en otra zona de disponibilidad.
Incluso sin alta disponibilidad habilitada, cada partición tiene su propio almacenamiento con redundancia local (LRS) con tres réplicas sincrónicas mantenidas por el servicio Azure Storage. Las tres réplicas se encuentran en la región de Azure del clúster. Si se produce un error de réplica única, el servicio Azure Storage lo detecta y vuelve a crear de forma transparente la réplica con errores. Consulte las métricas de esta página para obtener durabilidad del almacenamiento LRS.
Cuando la alta disponibilidad está habilitada, Azure DocumentDB ejecuta una partición en espera para cada partición principal del clúster. Cada partición principal y en espera tiene la misma configuración de proceso y almacenamiento. El primario y su reserva usan replicación sincrónica. Este tipo de replicación permite tener siempre los mismos datos en las particiones principal y en espera del clúster. En pocas palabras, nuestro servicio detecta un fallo en los fragmentos principales y cambia automáticamente a los fragmentos en espera sin pérdida de datos.
La cadena de conexión del clúster siempre permanece igual independientemente de las conmutaciones por error. Esto permite al servicio abstraer los cambios en las particiones físicas que atienden solicitudes de aplicaciones.
Cuando la alta disponibilidad regional está habilitada en el clúster, cada fragmento de clúster está cubierto por el acuerdo de nivel de servicio (SLA) del 99,99 % para la disponibilidad.
La alta disponibilidad se puede habilitar en el momento de creación del clúster. La alta disponibilidad también se puede habilitar y deshabilitar en cualquier momento en un clúster de Azure DocumentDB existente. No hay tiempo de inactividad de la base de datos cuando la alta disponibilidad está habilitada o deshabilitada en un clúster de Azure DocumentDB.
¿Qué ocurre durante una conmutación por error?
Cada conmutación por error de extensiones consta de tres fases: detección de falta de disponibilidad, cambio a la extensión en espera y nueva creación de la extensión en espera. El servicio realiza una supervisión continua de la disponibilidad de cada extensión principal y en espera en el clúster mediante comprobaciones de estado periódicas. Cuando la comprobación de estado indica de forma confiable que la extensión no responde y debe declararse errónea, se inicia la conmutación por error real (cambio) a la extensión en espera.
Durante la fase de cambio, las lecturas y escrituras de la base de datos se redirigen a la partición en espera. La replicación sincrónica entre cada partición principal y en espera garantiza que la partición en espera siempre tenga el mismo conjunto de datos que su principal. Esto permite que todas las conmutaciones se realicen sin pérdida de datos. El cambio a modo de espera se realiza sin causar interrupción en las lecturas. Las operaciones de escritura pueden requerir reintentos de servicio internos durante la fase de cambio. Estos reintentos pueden verse como lentitud de escritura en la aplicación.
Una vez completada la conmutación por error de extensiones, el clúster está totalmente operativo. El último paso para volver a la configuración original de alta disponibilidad es volver a crear la partición en espera. Esta nueva creación de particiones en espera se realiza sin tiempo de inactividad ni impacto en el rendimiento en la partición principal.