Consiga alta disponibilidad con Azure Cosmos DB
SE APLICA A: 
NoSQL MongoDB Cassandra Gremlin Table
Para crear una solución con alta disponibilidad, debe evaluar las características de confiabilidad de todos sus componentes. Azure Cosmos DB proporciona características y opciones de configuración para ayudarle a lograr una alta disponibilidad para su solución.
En este artículo se usan los términos siguientes:
- Objetivo de tiempo de recuperación (RTO): tiempo transcurrido entre el inicio de una interrupción que afecta a Azure Cosmos DB y la recuperación de la plena disponibilidad.
- Objetivo de punto de recuperación (RPO): el tiempo transcurrido entre la última escritura que se restauró correctamente y el momento del inicio de la interrupción que afecta a Azure Cosmos DB.
Nota:
Los valores de RPO y RTO esperados y máximos dependen del tipo de interrupción que Azure Cosmos DB esté experimentando. Por ejemplo, la interrupción de un solo nodo tiene un RTO y un RPO esperados diferentes que la interrupción de toda una región.
En este artículo se detallan los eventos que pueden afectar a la disponibilidad de Azure Cosmos DB y las correspondientes opciones de configuración de Azure Cosmos DB.
Mantenimiento de réplicas
Azure Cosmos DB es un servicio multiinquilino que controla todos los detalles de los nodos de ejecución individuales de forma transparente. Los usuarios no tienen que preocuparse por ningún tipo de aplicación de revisión y mantenimiento planeado. 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.
Interrupciones de réplica
Interrupciones de réplica son interrupciones de los nodos individuales en un clúster de Azure Cosmos DB implementado en una región de Azure.
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.
En muchas regiones de Azure, es posible distribuir su clúster de Azure Cosmos DB entre zonas de disponibilidad. Las zonas de disponibilidad pueden aumentar los Acuerdos de nivel de servicio porque son físicamente independientes y proporcionan una fuente de alimentación, una red y una refrigeración distintas. 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.
Cuando realiza la implementación en una única región de Azure, sin entradas de usuario adicionales, Azure Cosmos DB es resistente a las interrupciones de nodo. Habilitar la redundancia en todas las zonas de disponibilidad hace que Azure Cosmos DB sea resistente a las interrupciones de zona a costa de un aumento de los cargos.
Puede configurar la redundancia de zona solo cuando agregue una nueva región a una cuenta de Azure Cosmos DB. En el caso de las regiones existentes, puede habilitar la redundancia de zona quitando la región y, después, volviéndola a agregar con la redundancia de zona habilitada. En el caso de una cuenta de una sola región, este enfoque requiere que agregue una región a la que poder realizar la conmutación por error de forma temporal y, después, quitar y agregar la región deseada con la redundancia de zona habilitada.
De forma predeterminada, una cuenta de Azure Cosmos DB no usa varias zonas de disponibilidad. Puede habilitar la implementación en varias zonas de disponibilidad de las siguientes maneras:
Si su cuenta de Azure Cosmos DB se distribuye entre N regiones de Azure, habrá Nx 4 copias de todos los datos. Para obtener más información sobre cómo Azure Cosmos DB replica datos en cada región, consulte Distribución global con Azure Cosmos DB. Tener una cuenta de Azure Cosmos DB en más de dos regiones mejora la disponibilidad de su aplicación y proporciona una latencia baja en las regiones asociadas.
Interrupciones de la región
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.
- 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.
Disponibilidad
Si su solución requiere una disponibilidad continua 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 disponibles cuando sea necesario.
Las cuentas de una sola región pueden perder disponibilidad tras una interrupción regional. Para garantizar una alta disponibilidad 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 disponibilidad 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.
Qué cabe esperar durante una interrupción de región
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. 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).
SLA
La siguiente tabla resume las capacidades de alta disponibilidad de varias configuraciones de cuenta.
| 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.
Consejos para compilar aplicaciones de alta disponibilidad
Revise el comportamiento esperado de los SDK de Azure Cosmos DB durante los eventos y qué configuraciones lo afectan.
Para garantizar una alta disponibilidad de escritura y lectura, configure su cuenta de Azure Cosmos DB para que abarque al menos dos regiones (o tres, si utiliza coherencia fuerte). Para obtener más información, consulte Tutorial: Configuración de la distribución global de Azure Cosmos DB con SQL API.
Para las cuentas de varias regiones de Azure Cosmos DB configuradas con una única región de escritura, habilite la conmutación por error administrada por el servicio mediante la CLI de Azure o Azure Portal. Después de habilitar la conmutación por error administrada por el servicio, siempre que se produzca un desastre regional, Azure Cosmos DB conmutará por error la cuenta sin entradas de usuario.
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.
En un entorno de base de datos distribuida de forma global, existe una relación directa entre el nivel de coherencia y la durabilidad de los datos si se produce una interrupción en toda la región. A medida que desarrolle su plan de continuidad empresarial, debe conocer el tiempo máximo aceptable antes de que la aplicación se recupere completamente tras un evento disruptivo (es decir, el RTO). También es necesario conocer el periodo máximo de actualizaciones de datos recientes que la aplicación puede tolerar perder cuando se está recuperando tras un evento disruptivo (es decir, el RPO). Para más información sobre RTO y RPO, consulte Niveles de coherencia en Azure Cosmos DB.
Qué cabe esperar durante una interrupción de región de Azure Cosmos DB
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. |
Pasos siguientes
A continuación, puede leer los siguientes artículos: