Alta disponibilidad (fiabilidad) en Azure Cosmos DB for NoSQL
Este artículo describe la compatibilidad con la alta disponibilidad (fiabilidad) en Azure Cosmos DB for NoSQL y abarca tanto zonas de disponibilidad, como recuperación ante desastres y continuidad empresarial entre regiones.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad son grupos de centros de datos separados físicamente dentro de cada región Azure. Cuando falla una zona, los servicios pueden pasar a una de las zonas restantes.
Para obtener más información sobre las zonas de disponibilidad en Azure, consulte ¿Qué son las zonas de disponibilidad?.
Azure Cosmos DB es un servicio multiinquilino que controla todos los detalles de los nodos de ejecución individuales de forma transparente. No tiene que preocuparse de ningún tipo de revisión o plan de mantenimiento. Azure Cosmos DB garantiza los acuerdos de nivel de servicio para la disponibilidad y la latencia de P99 a través de todas las operaciones de mantenimiento automático realizadas por el sistema.
Azure Cosmos DB ofrece:
Resistencia a las interrupciones de los nodos individuales. Azure Cosmos DB mitiga automáticamente las interrupciones de réplica al garantizar al menos tres réplicas de los datos en cada región de Azure para su cuenta dentro de un cuórum de cuatro réplicas. Esta garantía da como resultado un RTO y un RPO de 0 para interrupciones de nodo individuales, sin necesidad de cambios o configuraciones de la aplicación.
Resistencia a las interrupciones de zona. Cuando implementa una cuenta de Azure Cosmos DB con zonas de disponibilidad, Azure Cosmos DB proporciona unos valores de RTO y RPO de 0 incluso en una interrupción de zona. Para más información sobre RTO, consulte Objetivos de recuperación.
Con zonas de disponibilidad habilitadas, Azure Cosmos DB for NoSQL es compatible con una configuración con redundancia de zona.
Requisitos previos
Las réplicas deben implementarse en una región de Azure que admita zonas de disponibilidad. Para ver qué regiones admiten zonas de disponibilidad, consulte la lista de regiones admitidas.
Determine si las zonas de disponibilidad agregan suficiente valor a su configuración actual en Impacto del uso de zonas de disponibilidad.
Impacto del uso de zonas de disponibilidad
El impacto de las zonas de disponibilidad en la alta disponibilidad de su base de datos de Cosmos DB for NoSQL depende del nivel de consistencia de la cuenta y de las regiones que tengan habilitadas zonas de disponibilidad. En muchos casos, las zonas de disponibilidad no agregan valor o agregan un valor mínimo si la cuenta es multirregión (a menos que se configure con una fuerte coherencia).
Consulte la tabla siguiente para estimar el impacto de usar zonas de disponibilidad en la configuración actual de su cuenta:
| Nivel de coherencia de la cuenta | Regiones con zonas de disponibilidad habilitadas | Impacto del uso de zonas de disponibilidad |
|---|---|---|
| Asincrónico (obsolescencia limitada o débil) | Cualquier número de regiones de lectura secundarias. | Proporciona un valor mínimo porque el SDK ya proporciona redirecciones sin problemas para las lecturas cuando se produce un error en una región de lectura. |
| Sincrónico (fuerte) | Dos o más regiones de lectura secundarias | Proporciona un valor marginal porque el sistema puede aprovechar el cuórum dinámico si una región de lectura pierde disponibilidad, lo que permite que las escrituras continúen. |
| Sincrónico (fuerte) | Una región de lectura secundaria | Proporciona un valor mayor porque la pérdida de una región de lectura en este escenario puede afectar a la disponibilidad de escritura. |
| All | Regiones de escritura y cualquier número de regiones secundarias | Garantiza una mayor disponibilidad para las operaciones de escritura para errores zonales. |
| All | Región única | Una sola región no se puede beneficiar de la funcionalidad de conmutación por error de varias regiones. El uso de zonas de disponibilidad protege contra la pérdida total de disponibilidad debido a un error zonal. |
Mejoras de SLA
Dado que las zonas de disponibilidad son físicamente independientes y proporcionan una fuente de alimentación, una red y una refrigeración distintas, los SLA (acuerdos de nivel de servicio) de disponibilidad son mayores (99,995 %) que en las cuentas con una sola región (99,99 %). Las regiones donde se habilitan las zonas de disponibilidad se cobran con un 25 % de recargo, mientras que aquellas sin zonas de disponibilidad no incurren en el recargo. Además, no se aplican precios adicionales por zonas de disponibilidad a las cuentas configuradas con escrituras multirregión y/o a las colecciones configuradas con el modo de escalabilidad automática.
Añadir una región adicional a la cuenta de Cosmos DB suele incrementar la factura existente en un 100 % (de forma aditiva, no multiplicativa), aunque existen pequeñas variaciones de coste entre regiones. Para más información, consulte la página de precios.
La habilitación de las zonas de disponibilidad, la adición de regiones adicionales o la activación de las escrituras multirregión pueden considerarse como un enfoque por capas que aumenta la resistencia y la disponibilidad de una cuenta de Cosmos DB determinada en cada paso del camino: desde 4 nueves de disponibilidad para una configuración de una sola región sin zonas de disponibilidad, pasando por 4 nueves y medio para una región única con zonas de disponibilidad, hasta llegar a 5 nueves de disponibilidad para una configuración multirregión con la opción de escritura multirregión habilitada. Consulte la tabla siguiente para obtener un resumen de los Acuerdos de Nivel de Servicio para cada configuración.
| KPI | Escrituras en una sola región sin zonas de disponibilidad | Escrituras en una sola región con zonas de disponibilidad | Escrituras en varias regiones y en una sola sin zonas de disponibilidad | Escrituras en varias regiones y en una sola con zonas de disponibilidad | Escrituras en varias regiones con o sin zonas de disponibilidad |
|---|---|---|---|---|---|
| Contrato de Nivel de Servicio de disponibilidad de escritura | 99,99% | 99,995 % | 99,99% | 99,995 % | 99,999 % |
| Contrato de Nivel de Servicio de disponibilidad de lectura | 99,99% | 99,995 % | 99,999 % | 99,999 % | 99,999 % |
| Errores de zona: pérdida de datos | Pérdida de datos | No se produce pérdida de datos | No se produce pérdida de datos | No se produce pérdida de datos | No se produce pérdida de datos |
| Errores de zona: disponibilidad | Pérdida de disponibilidad | Sin pérdida de disponibilidad | Sin pérdida de disponibilidad | Sin pérdida de disponibilidad | Sin pérdida de disponibilidad |
| Interrupción regional: pérdida de datos | Pérdida de datos | Pérdida de datos | Depende del nivel de coherencia. Para obtener más información, consulte Inconvenientes de la coherencia, disponibilidad y rendimiento. | Depende del nivel de coherencia. Para obtener más información, consulte Inconvenientes de la coherencia, disponibilidad y rendimiento. | Depende del nivel de coherencia. Para obtener más información, consulte Inconvenientes de la coherencia, disponibilidad y rendimiento. |
| Interrupción regional: disponibilidad | Pérdida de disponibilidad | Pérdida de disponibilidad | No hay pérdida de disponibilidad en caso de error de la región de lectura y temporal en caso de error de la región de escritura | No hay pérdida de disponibilidad en caso de error de la región de lectura y temporal en caso de error de la región de escritura | Sin pérdida de disponibilidad de lectura, pérdida temporal de disponibilidad de escritura en la región afectada |
| Precio (1) | No aplicable | Unidades de solicitud aprovisionadas x 1,25 | Unidades de solicitud aprovisionadas x N regiones | Unidades de solicitud aprovisionadas x velocidad de 1,25 x N regiones (2) | Velocidad de escritura en varias regiones x N regiones |
1 En el caso de las cuentas sin servidor, las unidades de solicitud se multiplican por un factor de 1,25.
2 La tasa de 1,25 solo se aplica a las regiones en las que habilita las zonas de disponibilidad.
Creación de un recurso con zonas de disponibilidad habilitadas
Solo puede configurar zonas de disponibilidad cuando agrega una nueva región a una cuenta de Azure Cosmos DB for NoSQL.
Para habilitar la compatibilidad con zonas de disponibilidad, puede usar:
Soporte técnico para la migración a la zona de disponibilidad
Para obtener información sobre cómo migrar la cuenta de Cosmos DB a la compatibilidad con zona de disponibilidad, consulte Migración de Azure Cosmos DB for NoSQL a compatibilidad con zonas de disponibilidad).
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, usted es el 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.
Las interrupciones de región son interrupciones que afectan a todos los nodos de Azure Cosmos DB de una región de Azure, en todas las zonas de disponibilidad. Para los raros casos de interrupciones en la región, puede configurar Azure Cosmos DB para que admita varios resultados de durabilidad y disponibilidad.
Durabilidad.
Cuando una cuenta de Azure Cosmos DB se implementa en una única región, generalmente no se produce ninguna pérdida de datos. El acceso a los datos se restaura tras la recuperación de los servicios de Azure Cosmos DB en la región afectada. La pérdida de datos podría producirse únicamente con un desastre irrecuperable en la región de Azure Cosmos DB.
Para ayudarle a protegerse contra la pérdida total de datos que podría resultar de desastres catastróficos en una región, Azure Cosmos DB proporciona dos modos de copia de seguridad:
- Las copias de seguridad continuas realiza una copia de seguridad de cada región cada 100 segundos. Le permiten restaurar sus datos a cualquier punto en el tiempo con una granularidad de 1 segundo. En cada región, la copia de seguridad depende de los datos confirmados en esa región. Si la región tiene habilitadas las zonas de disponibilidad, la copia de seguridad se almacena en cuentas de almacenamiento con redundancia de zona.
- Las copias de seguridad periódicas realizan copias de seguridad completas de todas las particiones de todos los contenedores de su cuenta, sin sincronización entre particiones. El intervalo mínimo de la copia de seguridad es una hora.
Cuando una cuenta de Azure Cosmos DB se implementa en varias regiones, la durabilidad de los datos depende del nivel de coherencia que se configure en la cuenta. En la siguiente tabla se detalla, para todos los niveles de coherencia, el RPO de una cuenta de Azure Cosmos DB implementada en al menos dos regiones.
| Nivel de coherencia | RPO para la interrupción de la región |
|---|---|
| Sesión, prefijo coherente, eventual | Menos de 15 minutos |
| Uso vinculado | K y T |
| Alta | 0 |
K = el número de versiones (es decir, actualizaciones) de un elemento.
T = intervalo de tiempo desde la última actualización.
En el caso de cuentas de varias regiones, el valor mínimo de K y T es de 100 000 operaciones de escritura o de 300 segundos. Este valor define el RPO mínimo para los datos cuando se utiliza la obsolescencia limitada.
Para obtener más información sobre las diferencias entre los niveles de coherencia, consulte Niveles de coherencia en Azure Cosmos DB.
Conmutación por error administrada por el servicio
Si su solución requiere un tiempo de actividad continuo durante las interrupciones de la región, puede configurar Azure Cosmos DB para replicar sus datos en varias regiones y conmutar por error de forma transparente a las regiones operativas cuando sea necesario.
Las cuentas de una sola región pueden perder accesibilidad tras una interrupción regional. Para garantizar la continuidad del negocio en todo momento, le recomendamos que configure su cuenta de Azure Cosmos DB con una única región de escritura y al menos una segunda región (lectura) y habilite la conmutación por error administrada por el servicio.
La conmutación por error administrada por el servicio permite a Azure Cosmos DB conmutar por error la región de escritura de una cuenta de varias regiones para preservar la a continuidad del negocio a costa de la pérdida de datos, como se ha descrito anteriormente en la sección Durabilidad. Las conmutaciones por error regionales se detectan y controlan en el cliente de Azure Cosmos DB. No requieren ningún cambio de la aplicación. Para obtener instrucciones sobre cómo habilitar varias regiones de lectura y la conmutación por error administrada por el servicio, consulte Administrar una cuenta de Azure Cosmos DB mediante Azure Portal.
Importante
Si ha elegido la configuración de escritura de una sola región con varias regiones de lectura, se recomienda encarecidamente configurar las cuentas de Azure Cosmos DB usadas para cargas de trabajo de producción para habilitar la conmutación por error administrada por el servicio. Esta configuración permite que Azure Cosmos DB conmute por error las bases de datos de la cuenta a las regiones disponibles. En ausencia de esta configuración, la cuenta experimentará una pérdida de disponibilidad de escritura durante toda la duración de la interrupción de la región de escritura. La conmutación por error manual no tendrá éxito debido a la falta de conectividad de la región.
Advertencia
Incluso con la conmutación por error administrada por el servicio habilitada, la interrupción parcial puede requerir la intervención manual para el equipo de servicio de Azure Cosmos DB. En estos escenarios, la conmutación por error puede tardar hasta 1 hora (o más) en surtir efecto. Para mejorar la disponibilidad de escritura durante las interrupciones parciales, se recomienda habilitar zonas de disponibilidad además de la conmutación por error administrada por el servicio.
Varias regiones de escritura
Puede configurar Azure Cosmos DB para que acepte escrituras en varias regiones. Esta configuración es útil para reducir la latencia de escritura en aplicaciones distribuidas geográficamente.
Cuando se configura una cuenta de Azure Cosmos DB para varias regiones de escritura, no se admite la coherencia fuerte y pueden surgir conflictos de escritura. Para obtener más información sobre cómo resolver estos conflictos, consulte Tipos de conflictos y directivas de resolución al utilizar varias regiones de escritura.
Importante
Actualizar el mismo id. de documento con frecuencia (o volver a crear el mismo identificador de documento con frecuencia después de TTL o eliminarlo) tendrá un efecto en el rendimiento de la replicación debido a un mayor número de conflictos generados en el sistema.
Región de resolución de conflictos
Cuando una cuenta de Azure Cosmos DB se configura con escrituras de varias regiones, una de las regiones actuará como árbitro en los conflictos de escritura.
Procedimientos recomendados para escritura en varias regiones
Estas son algunos de los procedimientos recomendados que debe tener en cuenta al escribir en varias regiones.
Mantener el tráfico local como local
Cuando se utilizan escrituras en varias regiones, la aplicación debe emitir el tráfico de lectura y escritura que se origina en la región local estrictamente a la región local de Cosmos DB. Para un rendimiento óptimo, evite las llamadas entre regiones.
Es importante que la aplicación minimice los conflictos evitando los siguientes antipatrones:
Enviar la misma operación de escritura a todas las regiones para aumentar las probabilidades de obtener un tiempo de respuesta rápido.
Determinar aleatoriamente la región de destino para una operación de lectura o escritura en función de cada solicitud.
Utilizar una directiva round-robin para determinar la región de destino de una operación de lectura o escritura en función de cada solicitud.
Evitar la dependencia del retraso de replicación
No se pueden configurar cuentas de escritura de varias regiones para una coherencia fuerte. La región en la que se está escribiendo responde inmediatamente después de que Azure Cosmos DB replique los datos localmente mientras replica los datos globalmente de forma asíncrona.
Aunque es poco frecuente, se puede producir un retraso de replicación en una o varias particiones al replicar datos geográficamente. Aunque es poco frecuente, puede producirse un retraso en la replicación en una o varias particiones cuando se replican geográficamente.
Por ejemplo, una arquitectura en la que la aplicación escriba en la región A, pero lea de la región B, introducirá una dependencia del retraso de replicación entre las dos regiones. Sin embargo, si la aplicación leyera y escribiera en la misma región, el rendimiento permanecerá constante incluso en presencia de retraso de replicación.
Evaluar el uso de la coherencia de sesión para las operaciones de escritura
En la consistencia de sesión, se utiliza el token de sesión tanto para operaciones de lectura como de escritura.
Para las operaciones de lectura, Azure Cosmos DB envía el token de sesión almacenado en caché al servidor con la garantía de recibir los datos que corresponden al token de sesión especificado (o a uno más reciente).
Para las operaciones de escritura, Azure Cosmos DB envía el token de sesión a la base de datos con la garantía de persistir los datos solo si el servidor ha alcanzado el token de sesión proporcionado. En las cuentas de escritura de una sola región, siempre se garantizará que la región de escritura se haya detectado para el token de sesión. Sin embargo, en las cuentas de escritura de varias regiones, es posible que la región en la que se escribe no haya alcanzado a las escrituras emitidas a otra región. Si el cliente escribe en la Región A con un token de sesión de la Región B, la Región A no podrá persistir los datos hasta que se ponga al día con los cambios realizados en la Región B.
Es mejor usar tokens de sesión solo para operaciones de lectura y no para operaciones de escritura al pasar tokens de sesión entre instancias de cliente.
Mitigar las actualizaciones rápidas de un mismo documento
Las actualizaciones del servidor para resolver o confirmar la ausencia de conflictos pueden entrar en conflicto con las escrituras desencadenadas por la aplicación cuando el mismo documento se actualice repetidamente. Las actualizaciones repetidas en sucesión rápida del mismo documento experimentarán latencias más altas durante la resolución de conflictos.
Aunque es inevitable que se produzcan ráfagas ocasionales de actualizaciones repetidas del mismo documento, podría considerar la posibilidad de explorar una arquitectura en la que se creen nuevos documentos en su lugar si el tráfico de estado estable detecta actualizaciones rápidas del mismo documento durante un período prolongado.
Interrupciones de lectura y escritura
Los clientes de cuentas de una sola región experimentarán una pérdida de disponibilidad de lectura y escritura hasta que se restablezca el servicio.
Las cuentas de varias regiones experimentan diferentes comportamientos en función de las siguientes configuraciones y tipos de interrupción.
| Configuración | Interrupción | Impacto en la disponibilidad | Impacto de durabilidad | Qué hacer |
|---|---|---|---|---|
| Una región de escritura | Interrupción de la región de lectura | Todos los clientes redirigen automáticamente las lecturas a otras regiones. No hay pérdida de disponibilidad de lectura o escritura para todas las configuraciones. La excepción es una configuración de dos regiones con consistencia fuerte, que pierde la disponibilidad de escritura hasta la restauración del servicio. O si activa la conmutación por error administrada por el servicio, el servicio marca la región como con errores y se produce una conmutación por error. | No se produce pérdida de datos. | Durante la interrupción, asegúrese de que hay suficientes unidades de solicitud (RU) aprovisionadas en las regiones restantes para admitir el tráfico de lectura. Cuando termine la interrupción, reajuste las unidades de solicitud aprovisionadas según corresponda. |
| Una región de escritura | Interrupción de la región de escritura | Los clientes redirigen las lecturas a otras regiones. Sin conmutación por error administrada por el servicio, los clientes experimentan pérdida de disponibilidad de escritura. El restablecimiento de la disponibilidad de escritura se produce automáticamente cuando finaliza la interrupción. Con la conmutación por error administrada por el servicio, los clientes experimentan una pérdida de disponibilidad de escritura hasta que el servicio administra una conmutación por error a una nueva región de escritura que seleccione. |
Si no selecciona el nivel de consistencia fuerte, es posible que el servicio no replique algunos datos a las regiones activas restantes. Esta replicación depende del nivel de coherencia que seleccione. Si la región afectada sufriera una pérdida de datos permanente, podría perder los datos no duplicados. | Durante la interrupción, asegúrese de que haya suficientes unidades de solicitud aprovisionadas en las regiones restantes para admitir el tráfico de lectura. No desencadene una conmutación por error manual durante la interrupción, ya que no se realizará correctamente. Cuando termine la interrupción, reajuste las unidades de solicitud aprovisionadas según corresponda. Las cuentas que utilizan la API para NoSQL también podrían recuperar los datos no replicados en la región con errores de su fuente de conflictos. |
| Varias regiones de escritura | Cualquier interrupción regional | Existe la posibilidad de una pérdida temporal de disponibilidad de escritura, que es análoga a una única región de escritura con conmutación por error administrada por el servicio. La conmutación por error de la región de resolución de conflictos también puede causar una pérdida de disponibilidad de escritura si se produce un gran número de escrituras en conflicto en el momento de la interrupción. | Es posible que los datos actualizados recientemente en la región con errores no estén disponibles en el resto de las regiones activas, según el nivel de coherencia seleccionado. Si la región afectada sufre una pérdida de datos permanente, podría perder datos no replicados. | Durante la interrupción, asegúrese de que haya suficientes unidades de solicitud aprovisionadas en las regiones restantes para admitir más tráfico. Cuando finalice la interrupción, puede reajustar las RU aprovisionadas según proceda. Si es posible, Azure Cosmos DB recupera automáticamente los datos no replicados en la región con error. Esta recuperación automática usa el método de resolución de conflictos que configura para las cuentas que usan la API para NoSQL. Para las cuentas que usan otras API, esta recuperación automática utiliza los últimos casos de escritura correcta. |
Información adicional sobre interrupciones de la región de lectura
La región afectada se desconecta y se marca como sin conexión. Los SDK de Azure Cosmos DB redirigen las llamadas de lectura a la siguiente región disponible en la lista de regiones preferidas.
Si ninguna de las regiones de la lista de las regiones preferidas está disponible, las llamadas se devuelven automáticamente a la región actual de escritura.
No es necesario realizar ningún cambio en el código de su aplicación para administrar la interrupción de la región de lectura. Cuando la región de lectura afectada vuelve a estar en línea, se sincroniza con la región de escritura actual y vuelve a estar disponible para atender solicitudes de lectura una vez que se ha puesto al día por completo.
Las siguientes lecturas se redirigen a la región recuperada sin necesidad de realizar cambios en el código de la aplicación. Tanto durante la conmutación por error como durante el restablecimiento de una región con errores anteriores, Azure Cosmos DB sigue respetando las garantías de coherencia de lectura.
Incluso en un caso raro y desafortunado en el que una región de escritura de Azure sea irrecuperable de forma permanente, no hay pérdida de datos si su cuenta Azure Cosmos DB de varias regiones está configurada con una coherencia fuerte. Una cuenta de Azure Cosmos DB de varias regiones tiene las características de durabilidad especificadas anteriormente en la sección Durabilidad.
Información adicional sobre interrupciones de la región de lectura
Durante una interrupción de la región de escritura, la cuenta de Azure Cosmos DB promueve una región secundaria para que sea la nueva región de escritura principal cuando la conmutación por error administrada por el servicio está configurada en la cuenta de Azure Cosmos DB. La conmutación por error se produce a otra región en el orden de prioridad de región que especifique.
La conmutación por error manual no debe desencadenarse y no tendrá éxito en presencia de una interrupción de la región de origen o de destino. La razón es que el procedimiento de conmutación por error incluye una comprobación de coherencia que requiere conectividad entre las regiones.
Cuando la región afectada anteriormente vuelve a estar en línea, los datos de escritura que no se replicaron cuando la región presentó el error vuelven a estar disponibles a través de la fuente de conflictos. Las aplicaciones pueden leer la fuente de conflictos, resolver los conflictos de acuerdo con la lógica específica de la aplicación y escribir los datos actualizados de nuevo en el contenedor de Azure Cosmos DB según corresponda.
Una vez recuperada la región de escritura afectada anteriormente, se mostrará como "en línea" en Azure Portal y estará disponible como región de lectura. En este momento, es seguro volver a la región recuperada como región de escritura mediante [PowerShell, la CLI de Azure o Azure Portal](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account. No hay pérdida de datos ni de disponibilidad antes, mientras o después de cambiar la región de escritura. La aplicación sigue teniendo alta disponibilidad.
Advertencia
En caso de interrupción de una región de escritura, donde la cuenta de Azure Cosmos DB promueve una región secundaria para que sea la nueva región de escritura primaria a través de conmutación por error administrada por el servicio, la región de escritura original no se volverá a promover como la región de escritura automáticamente una vez que se recupere. Es su responsabilidad asignar la región recuperada de nuevo como la región de escritura mediante PowerShell, la CLI de Azure o Azure Portal (una vez que sea seguro hacerlo, como se ha descrito anteriormente).
Detección, notificación y administración de interrupciones
Para las cuentas de región única, los clientes experimentan una pérdida de disponibilidad de lectura y escritura durante una interrupción de la región de Azure Cosmos DB. Las cuentas de varias regiones experimentan comportamientos diferentes, como se describe en la siguiente tabla.
| Regiones de escritura | Conmutación por error administrada por el servicio | Qué esperar | Qué hacer |
|---|---|---|---|
| Una región de escritura | no habilitado. | Si se produce una interrupción en una región de lectura cuando no se utiliza la coherencia fuerte, todos los clientes se redirigirán a otras regiones. No hay pérdida de disponibilidad de lectura o escritura, y no hay pérdida de datos. Cuando se utiliza la coherencia fuerte, una interrupción en una región de lectura puede afectar a la disponibilidad de escritura si quedan menos de dos regiones de lectura. Si se produce una interrupción en la región de escritura, los clientes experimentarán una pérdida de disponibilidad de escritura. Si no seleccionó la coherencia fuerte, es posible que el servicio no replique algunos datos a las regiones activas restantes. Esta replicación depende del nivel de coherencia seleccionado. Si la región afectada sufre una pérdida de datos permanente, podría perder datos no replicados. Azure Cosmos DB restaura la disponibilidad de escritura cuando finaliza la interrupción. |
Durante la interrupción, asegúrese de que haya suficientes unidades de solicitud aprovisionadas en las regiones restantes para admitir el tráfico de lectura. No desencadene una conmutación por error manual durante la interrupción, ya que no se realizará correctamente. Cuando termine la interrupción, reajuste las unidades de solicitud aprovisionadas según corresponda. |
| Una región de escritura | habilitado | Si se produce una interrupción en una región de lectura cuando no se utiliza la coherencia fuerte, todos los clientes se redirigirán a otras regiones. No hay pérdida de disponibilidad de lectura o escritura, y no hay pérdida de datos. Cuando se utiliza la coherencia fuerte, la interrupción de una región de lectura puede afectar a la disponibilidad de escritura si quedan menos de dos regiones de lectura. Si hay una interrupción en la región de escritura, los clientes experimentan una pérdida de disponibilidad de escritura hasta que Azure Cosmos DB elige una nueva región como la nueva región de escritura según tus preferencias. Si no seleccionó la coherencia fuerte, es posible que el servicio no replique algunos datos a las regiones activas restantes. Esta replicación depende del nivel de coherencia seleccionado. Si la región afectada sufre una pérdida de datos permanente, podría perder datos no replicados. |
Durante la interrupción, asegúrese de que haya suficientes unidades de solicitud aprovisionadas en las regiones restantes para admitir el tráfico de lectura. No desencadene una conmutación por error manual durante la interrupción, ya que no se realizará correctamente. Cuando finalice la interrupción, puede volver a trasladar la región de escritura a la región original y reajustar las RU aprovisionadas según corresponda. Las cuentas que utilizan la API para NoSQL también pueden recuperar los datos no replicados en la región con errores desde su fuente de conflictos. |
| Varias regiones de escritura | No aplicable | Los datos actualizados recientemente en la región con errores podrían no estar disponibles en el resto de regiones activas. Los niveles de prefijo eventual y coherente y de coherencia de sesión garantizan un estancamiento inferior a 15 minutos. La obsolescencia limitada garantiza menos de K actualizaciones o T segundos, dependiendo de la configuración. Si la región afectada sufre una pérdida de datos permanente, podría perder datos no replicados. | Durante la interrupción, asegúrese de que haya suficientes unidades de solicitud aprovisionadas en las regiones restantes para admitir más tráfico. Cuando finalice la interrupción, puede reajustar las RU aprovisionadas según proceda. Si es posible, Azure Cosmos DB recupera los datos no replicados en la región con error. Esta recuperación usa el método de resolución de conflictos que configura para las cuentas que usan la API para NoSQL. Para las cuentas que usan otras API, esta recuperación utiliza los últimos casos de escritura correcta. |
Pruebas de alta disponibilidad
Incluso si su cuenta de Azure Cosmos DB es de alta disponibilidad, es posible que su aplicación no se haya diseñado correctamente para seguir teniendo alta disponibilidad. Para probar la alta disponibilidad de extremo a extremo de su aplicación como parte de sus pruebas de aplicaciones o simulacros de recuperación ante desastres (DR), deshabilite temporalmente la conmutación por error administrada por el servicio para la cuenta. Invoque la conmutación por error manual mediante PowerShell, la CLI de Azure o Azure Portal y, a continuación, supervise la aplicación. Después de completar la prueba, puede volver a la región primaria y restaurar la conmutación por error administrada por el servicio para la cuenta.
Importante
No invoque la conmutación por error manual durante una interrupción de Azure Cosmos DB en la región de origen o de destino. La conmutación por error manual requiere conectividad regional para mantener la coherencia de los datos, por lo que no se realizará correctamente.