Confiabilidad en Azure Cosmos DB for MongoDB vCore
SE APLICA A: 
núcleo virtual de MongoDB
Este artículo contiene información detallada sobre la resistencia regional con zonas de disponibilidad y recuperación ante desastres entre regiones y continuidad empresarial para Azure Cosmos DB for MongoDB vCore.
Para obtener información arquitectónica general sobre la fiabilidad de Azure, consulte Fiabilidad de Azure.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad son grupos físicamente separados de centros de datos dentro de cada región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.
Para más información sobre las zonas de disponibilidad en Azure, consulte ¿Qué son las zonas de disponibilidad?.
Para obtener compatibilidad con zonas de disponibilidad, debe habilitar alta disponibilidad (ALTA DISPONIBILIDAD).
La alta disponibilidad evita el tiempo de inactividad de la base de datos manteniendo las réplicas en espera de todas las particiones de un clúster. Si una extensión deja de funcionar, el núcleo virtual de Azure Cosmos DB for MongoDB cambiará las conexiones entrantes de la extensión fallida a su réplica en espera.
Cuando la alta disponibilidad está habilitada en una región que admite zonas de disponibilidad, las particiones de réplica de alta disponibilidad se aprovisionan en una zona de disponibilidad diferente de sus particiones principales. Las réplicas de alta disponibilidad no reciben solicitudes de los clientes a menos que su extensión principal falle.
Si la alta disponibilidad está deshabilitada, cada partición tiene su propio almacenamiento con redundancia local (LRS) con tres réplicas sincrónicas mantenidas por el servicio Azure Storage. Si hay un error de una sola réplica, el servicio Azure Storage detecta el error y vuelve a crear de forma transparente los datos relevantes. Para obtener durabilidad del almacenamiento LRS, consulte Resumen de las opciones de redundancia. Sin embargo, en el caso de un error de región, se corre el riesgo de un tiempo de inactividad extenso y posible pérdida de datos.
Creación de un recurso con zonas de disponibilidad habilitadas
Para habilitar las zonas de disponibilidad, debe habilitar alta disponibilidad (HA) al Crear un clúster o en la secciónEscalado de un clúster existente en Azure Portal.
Recuperación ante desastres entre regiones y continuidad empresarial
La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.
En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, es responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.
El núcleo virtual de Azure Cosmos DB for MongoDB no proporciona conmutación automática por error integrada ni recuperación ante desastres. La planificación de la alta disponibilidad es un paso fundamental a medida que se escala la solución.
Recuperación ante desastres en una sola región geográfica
Para maximizar el tiempo de actividad, planee con antelación la continuidad empresarial y prepare todo lo necesario para la recuperación ante desastres con un núcleo virtual de Azure Cosmos DB for MongoDB.
Aunque los servicios de Azure están diseñados para maximizar el tiempo de actividad, es posible que se produzcan interrupciones de servicio no planeadas. Un plan de recuperación ante desastres garantiza que tiene una estrategia para abordar las interrupciones de servicio en regiones.
El núcleo virtual de Azure Cosmos DB for MongoDB crea automáticamente copias de seguridad de los datos a intervalos regulares. Las copias de seguridad automáticas se crean sin afectar al rendimiento o a la disponibilidad de las operaciones de las bases de datos. Todas las copias de seguridad se realizan de forma automática en segundo plano y se almacenan por separado de los datos de origen en un servicio de almacenamiento. Estas copias de seguridad automáticas son útiles en escenarios en los que se eliminan o modifican recursos de manera accidental y, posteriormente, se necesitan las versiones originales.
Las copias de seguridad automáticas se conservan en varios intervalos en función de si el clúster está activo o se ha eliminado recientemente.
| Período de retención | |
|---|---|
| Clústeres activos | 35 días |
| Clústeres eliminados | 7 días |
Diseño para lograr alta disponibilidad
La alta disponibilidad (HA) debe estar habilitada para clústeres críticos de núcleo virtual de Azure Cosmos DB for MongoDB que ejecutan cargas de trabajo de producción. En un clúster habilitado para alta disponibilidad, cada partición actúa como principal junto con una partición en espera activa aprovisionada en otra zona de disponibilidad. La replicación entre la partición principal y la secundaria es sincrónica de forma predeterminada. Cualquier modificación de la base de datos se conserva en las particiones principal y secundaria (en espera activa) antes de recibir una respuesta de la base de datos.
El servicio mantiene comprobaciones de estado y latidos en cada partición principal y secundaria del clúster. Si una partición principal deja de estar disponible debido a una interrupción regional o de zona, la partición secundaria se promueve automáticamente para convertirse en la nueva principal y se crea una partición secundaria posterior para la nueva principal. Además, si una partición secundaria deja de estar disponible, el servicio crea automáticamente una nueva partición secundaria con una copia completa de datos de la principal.
Si el servicio desencadena una conmutación por error de la partición principal a la secundaria, las conexiones se enrutan sin problemas en segundo plano a la nueva partición principal.
La replicación sincrónica entre las particiones principal y secundaria garantiza ninguna pérdida de datos si hay una conmutación por error.
Pasos siguientes
- Obtenga más información sobre la compatibilidad de características con MongoDB.
- Revise las opciones para migrar de MongoDB a un núcleo virtual de Azure Cosmos DB for MongoDB.
- Para empezar, cree una cuenta.