Alta disponibilidad en los núcleos virtuales de Azure Cosmos DB for MongoDB
SE APLICA A: 
núcleo virtual de MongoDB
La alta disponibilidad (HA) dentro de la región evita el tiempo de inactividad de la base de datos al mantener réplicas en espera de todas las extensiones de un clúster. Si una extensión deja de responder por cualquier motivo, el núclo virtual de Azure Cosmos DB for MongoDB cambia las conexiones entrantes de la extensión con errores a su 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 extensiones principales de un clúster se aprovisionan en una zona de disponibilidad (AZ) para mejorar la latencia entre ellas. Las extensiones en espera se aprovisionan en otra zona de disponibilidad.
Incluso sin la opción de alta disponibilidad habilitada, cada extensión tiene su propio almacenamiento con redundancia local (LRS), con tres réplicas sincrónicas que mantiene 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 una sola réplica, el servicio Azure Storage lo detecta y vuelve a crear de forma transparente la réplica con errores. Para conocer la durabilidad del almacenamiento de LRS, consulte las métricas de esta página.
Cuando la alta disponibilidad está habilitada, el núcleo virtual de Azure Cosmos DB for MongoDB ejecuta una extensión en espera para cada extensión principal del clúster. Cada extensión principal y en espera tiene la misma configuración de proceso y almacenamiento. La extensión principal y en espera usan la replicación sincrónica. Este tipo de replicación permite tener siempre los mismos datos en las extensiones principal y en espera del clúster. En pocas palabras, nuestro servicio detecta un error en las particiones principales y conmuta por error a particiones en espera con cero pérdidas 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 extensiones físicas que atienden solicitudes de aplicaciones.
Cuando la alta disponibilidad en la región está habilitada en el clúster, cada partición del clúster está cubierta 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 núcleo virtual de Azure Cosmos DB for MongoDB existente. No hay tiempo de inactividad de la base de datos cuando está habilitada o deshabilitada la alta disponibilidad en un clúster de núcleo virtual de Azure Cosmos DB for MongoDB.
¿Qué ocurre durante la 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 extensión en espera. La replicación sincrónica entre cada extensión principal y en espera garantiza que la extensión en espera siempre tenga el mismo conjunto de datos que su principal. Esto permite que todas las conmutaciones por error se realicen sin pérdida de datos. El cambio al modo de espera se realiza sin tiempo de inactividad para 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 crear de nuevo la extensión en espera. Esta nueva creación de la partición en espera se realiza sin tiempo de inactividad ni impacto en el rendimiento en la extensión principal.