Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo descreve o suporte à alta disponibilidade (confiabilidade) no Azure Cosmos DB for NoSQL e abrange zonas de disponibilidade, bem como recuperação de desastre entre regiões e continuidade dos negócios.
Resiliência de nós de computação
O Azure Cosmos DB gerencia de forma transparente todos os detalhes de nós de computação individuais. Você não tem que se preocupar com nenhum tipo de correção ou manutenção planejada. O Azure Cosmos DB garante SLAs para disponibilidade e latência P99 por meio de todas as operações de manutenção automática que o sistema executa.
O Azure Cosmos DB reduz automaticamente os interrupções de réplica, garantindo pelo menos três réplicas de seus dados em cada região do Azure para a sua conta dentro de um quorum de quatro réplicas. Essa garantia resulta em um RTO de 0 e um RPO de 0 para interrupções de nó individuais, sem precisar de alterações ou configurações de aplicativos. Para obter informações sobre RTO e RPO, consulte O que são continuidade dos negócios, alta disponibilidade e recuperação de desastre?.
Suporte à zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de datacenters em cada região do Azure. Quando uma zona falha, os serviços podem passar para uma das zonas restantes.
O Azure Cosmos DB dá suporte à redundância de zona. Quando você habilita a redundância de zona, o Azure distribui as réplicas de seus dados em várias zonas de disponibilidade, fornecendo resiliência a problemas e interrupções do datacenter. Você pode habilitar a redundância de zona em regiões do Azure que dão suporte a zonas de disponibilidade. Para revisar se a sua região dá suporte a zonas de disponibilidade, consulte a lista de regiões com suporte.
É recomendável usar a redundância de zona em regiões em que há suporte, especialmente para contas de região única.
Redundância de zona e contas de região única
Quando você tem uma conta do Cosmos DB de região única, é importante ser resiliente a problemas em uma zona de disponibilidade. Habilitar a redundância de zona protege contra perda total de disponibilidade devido à falha de uma zona de disponibilidade.
Como as zonas de disponibilidade são fisicamente separadas e fornecem fonte de energia, rede e resfriamento distintos, os SLAs de disponibilidade do Azure Cosmos DB são mais altos para contas com redundância de zona do que contas que não usam zonas de disponibilidade.
Redundância de zona e contas de várias regiões
Se você tiver uma conta de várias regiões, opcionalmente poderá habilitar a redundância de zona em qualquer uma ou em todas as regiões de conta que dão suporte a zonas de disponibilidade. As contas de várias regiões podem alcançar SLAs (contratos de nível de serviço) de alta disponibilidade e habilitar a redundância de zona pode aprimorar ainda mais os SLAs de disponibilidade geral que você consegue nessas regiões.
Para contas de várias regiões, o impacto da redundância de zona na disponibilidade do banco de dados Cosmos DB para NoSQL depende do nível de consistência da conta e quais regiões têm a redundância de zona habilitada. Consulte a tabela abaixo para estimar o impacto do uso de zonas de disponibilidade na configuração da conta de várias regiões:
| Nível de consistência da conta | Regiões com zonas de disponibilidade habilitadas | Impacto do uso de zonas de disponibilidade |
|---|---|---|
| Síncrona (forte) | Uma região de leitura secundária | Alto benefício da redundância de zona. Fornece um valor maior porque a perda de uma região de leitura nesse cenário pode afetar a disponibilidade de gravação. |
| Síncrona (forte) | Duas ou mais regiões de leitura secundárias | Menor valor de redundância de zona. Fornece um valor marginal, porque o sistema pode aproveitar o quorum dinâmico caso uma região de leitura perca a disponibilidade, o que permite que as gravações continuem. |
| Assíncrona (desatualização limitada ou mais fraca) | Uma ou mais regiões de leitura secundárias | Menor valor de redundância de zona. Fornece valor mínimo porque o SDK já fornece redirecionamentos contínuos para leituras quando uma região de leitura falha. |
| Qualquer | Todas as regiões de gravação e qualquer número de regiões secundárias | Alto benefício da redundância de zona. Garante maior disponibilidade para operações de gravação em caso de falhas na zona de disponibilidade. |
Custo de habilitação da redundância de zona
Regiões em que a redundância de zona está habilitada são cobradas com um premium de 25%. No entanto, o preço do premium das zonas de disponibilidade é dispensado para contas configuradas com gravações de várias regiões e/ou para coleções configuradas com o modo de dimensionamento automático.
A adição de uma região adicional à conta do Cosmos DB normalmente aumenta sua fatura existente em 100% para cada região. No entanto, existem pequenas variações de custo entre regiões.
Para obter mais detalhes, consulte a página de preços.
Aprimoramentos do SLA
Para aumentar a resiliência e a disponibilidade de uma conta do Azure Cosmos DB, você pode implementar uma abordagem de camadas, que inclui:
- Habilitando a redundância de zona.
- Adicionando uma ou mais regiões adicionais.
- Habilitando gravações de várias regiões.
A abordagem de camadas protege a conta em cada etapa do caminho - desde a disponibilidade de 4 9's para uma configuração de região única sem redundância de zona, passando por 4 9's e meio para região única com redundância de zona, até 5 9's de disponibilidade para configuração de várias regiões com a opção de gravação de várias regiões habilitada.
A tabela a seguir contém um resumo de SLAs para cada configuração:
| KPI | Gravações de região única sem zonas de disponibilidade | Gravações de região única com zonas de disponibilidade | Gravações de várias regiões e de região única sem zonas de disponibilidade | Gravações de várias regiões e de região única com zonas de disponibilidade | Gravações em várias regiões e várias regiões com ou sem zonas de disponibilidade |
|---|---|---|---|---|---|
| SLA de disponibilidade de gravação | 99,99% | 99,995% | 99,99% | 99,995% | 99,999% |
| SLA de disponibilidade de leitura | 99,99% | 99,995% | 99,999% | 99,999% | 99,999% |
| Falhas de zona: perda de dados | Perda de dados | Sem perda de dados | Sem perda de dados | Sem perda de dados | Sem perda de dados |
| Falhas de zona: disponibilidade | Perda de disponibilidade | Sem perda de disponibilidade | Sem perda de disponibilidade | Sem perda de disponibilidade | Sem perda de disponibilidade |
| Interrupção regional: perda de dados | Perda de dados | Perda de dados | Dependente do nível de coerência. Para obter mais informações, consulte Compensações de coerência, disponibilidade e desempenho. | Dependente do nível de coerência. Para obter mais informações, consulte Compensações de coerência, disponibilidade e desempenho. | Dependente do nível de coerência. Para obter mais informações, consulte Compensações de coerência, disponibilidade e desempenho. |
| Interrupção regional: disponibilidade | Perda de disponibilidade | Perda de disponibilidade | Nenhuma perda de disponibilidade para a falha de região de leitura, perda temporária para falha de região de gravação | Nenhuma perda de disponibilidade para a falha de região de leitura, perda temporária para falha de região de gravação | Sem perda de disponibilidade de leitura, perda temporária de disponibilidade de gravação na região afetada |
| Preço (1) | Não aplicável | RU/s provisionada x taxa de 1,25 | RU/s provisionadas x N regiões | RU/s provisionadas x taxa de 1,25 x N regiões (2) | Taxa de gravação de várias regiões x N regiões |
1 Para contas sem servidor, as RUs são multiplicadas por um fator de 1,25.
2 A taxa de 1,25 se aplica apenas a regiões nas quais você habilita zonas de disponibilidade.
Configurar zonas de disponibilidade
Criar um recurso com zonas de disponibilidade habilitadas
Você só pode configurar zonas de disponibilidade quando adicionar uma nova região a uma conta do Azure Cosmos DB for NoSQL.
Para habilitar o suporte à zona de disponibilidade, você pode usar:
Habilitar o suporte à zona de disponibilidade
Para saber como habilitar a redundância de zona em sua conta do Azure Cosmos DB, consulte Migrar o Azure Cosmos DB para NoSQL para o suporte à zona de disponibilidade).
Recuperação de desastre entre regiões e continuidade dos negócios
Recuperação de desastre (DR) refere-se a práticas que as organizações usam para se recuperar de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a criar seu plano de recuperação de desastre, veja Recomendações para a elaboração de uma estratégia de recuperação de desastre.
Para a DR, a Microsoft usa o modelo de responsabilidade compartilhada. Nesse modelo, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. No entanto, muitos serviços do Azure não replicam automaticamente dados nem fazem fallback de uma região com falha para replicação entre outras regiões habilitadas. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de recuperação de desastre.
As interrupções de região são interrupções que afetam todos os nós do Azure Cosmos DB em uma região do Azure, em todas as zonas de disponibilidade. Para os raros casos de interrupções de região, você pode configurar o Azure Cosmos DB para dar suporte a vários resultados de durabilidade e disponibilidade.
Durabilidade
Quando uma conta do Azure Cosmos DB é implantada em uma única região, geralmente não ocorre nenhuma perda de dados. O acesso aos dados é restaurado após a recuperação dos serviços do Azure Cosmos DB na região afetada. A perda de dados pode ocorrer apenas com um desastre irrecuperável na região do Azure Cosmos DB.
Para ajudá-lo a se proteger contra a perda completa de dados, que pode resultar de desastres catastróficos em uma região, o Azure Cosmos DB fornece dois modos de backup:
- Os backups contínuos fazem backup de cada região a cada 100 segundos. Eles permitem que você restaure seus dados para qualquer ponto no tempo com granularidade de 1 segundo. Em cada região, o backup depende dos dados confirmados nessa região. Se a região tiver zonas de disponibilidade habilitadas, o backup será armazenado em contas de armazenamento com redundância de zona.
- Os backups periódicos fazem backups completos de todas as partições de todos os contêineres em sua conta, sem sincronização entre partições. O intervalo de backup mínimo é de 1 hora.
Quando uma conta do Azure Cosmos DB é implantada em várias regiões, a durabilidade dos dados depende do nível de coerência que você configura na conta. A tabela a seguir detalha o RPO de uma conta do Azure Cosmos DB implantada em pelo menos duas regiões, para todos os níveis de coerência.
| Nível de coerência | RPO para interrupção de região |
|---|---|
| Sessão, prefixo consistente, eventual | Menos de 15 minutos |
| Desatualização limitada | K e T |
| Forte | 0 |
K = O número de versões (ou seja, atualizações) de um item.
T = O intervalo de tempo desde a última atualização.
Para contas de várias regiões, o valor mínimo de K e T é de 100 mil operações de gravação ou 300 segundos. Esse valor define o RPO mínimo dos dados quando você está usando a desatualização limitada.
Para obter mais informações sobre as diferenças entre níveis de coerência, confira os Níveis de coerência no Azure Cosmos DB.
Failover gerenciado pelo serviço
Se sua solução exigir tempo de atividade contínuo durante interrupções de região, você pode configurar o Azure Cosmos DB para replicar seus dados em várias regiões e fazer failover transparente para regiões disponíveis quando necessário.
As contas de uma única região podem perder a acessibilidade após uma interrupção regional. Para garantir a continuidade dos negócios em todos os momentos, recomendamos que você configure sua conta do Azure Cosmos DB com uma única região de gravação e pelo menos uma segunda região (leitura) e habilitar o failover gerenciado pelo serviço.
O failover gerenciado pelo serviço permite que o Azure Cosmos DB faça failover na região de gravação de uma conta de várias regiões, a fim de preservar a continuidade dos negócios à custa da perda de dados, conforme descrito anteriormente na seção Durabilidade. Os failovers regionais são detectados e manipulados no cliente do Azure Cosmos DB. Eles não exigem alterações do aplicativo. Para ver instruções de como habilitar várias regiões de leitura e o failover gerenciado pelo serviço, confira como Gerenciar uma conta do Azure Cosmos DB usando o portal do Azure.
Importante
Se você escolheu a configuração de gravação de região única com várias regiões de leitura, é altamente recomendável configurar as contas do Azure Cosmos DB usadas para cargas de trabalho de produção para habilitar o failover gerenciado pelo serviço. Essa configuração permite que o Azure Cosmos DB faça o failover dos bancos de dados da conta para as regiões disponíveis. Na ausência dessa configuração, a conta passará por perda de disponibilidade de gravação durante toda a interrupção da região de gravação. O failover manual não terá sucesso devido à falta de conectividade da região.
Aviso
Mesmo com o failover gerenciado pelo serviço ativado, a interrupção parcial pode exigir intervenção manual da equipe de serviço do Azure Cosmos DB. Nesses cenários, pode levar até 1 hora (ou mais) para que o failover entre em vigor. Para melhorar a disponibilidade de gravação durante interrupções parciais, recomendamos ativar as zonas de disponibilidade, além do failover gerenciado pelo serviço.
Várias regiões de gravação
Você pode configurar o Azure Cosmos DB para aceitar gravações em várias regiões. Essa configuração é útil para reduzir a latência de gravação em aplicativos geograficamente distribuídos.
Quando você configura uma conta do Azure Cosmos DB para várias regiões de gravação, não há suporte para coerência forte e podem surgir conflitos de gravação. Para obter mais informações sobre como resolver conflitos, confira Tipos de conflito e políticas de resolução ao usar várias regiões de gravação.
Importante
Atualizar a mesma ID do documento com frequência (ou recriar a mesma ID do documento com frequência após TTL ou exclusão) terá um efeito sobre o desempenho da replicação devido ao aumento do número de conflitos gerados no sistema.
Região de resolução de conflitos
Quando uma conta do Azure Cosmos DB é configurada com gravações de várias regiões, uma das regiões atuará como um árbitro em conflitos de gravação.
Práticas recomendadas para gravações de várias regiões
Aqui estão algumas práticas recomendadas a serem consideradas ao gravar em várias regiões.
Manter o tráfego local
Quando você usa gravações de várias regiões, o aplicativo deve emitir tráfego de leitura e gravação originado na região local estritamente para a região local do Cosmos DB. Para um desempenho ideal, evitar chamadas entre regiões.
É importante que o aplicativo minimize conflitos evitando os seguintes anti-padrões:
Enviar a mesma operação de gravação para todas as regiões para aumentar as chances de obter um tempo de resposta rápido
Determinar aleatoriamente a região de destino para uma operação de leitura ou gravação por solicitação
Usar uma política round-robin para determinar a região de destino para uma operação de leitura ou gravação por solicitação.
Evitar a dependência de retardo de replicação
Você não pode configurar contas de gravação de várias regiões para coerência forte. A região que está sendo gravada responde imediatamente após o Azure Cosmos DB replicar os dados localmente enquanto replica os dados de forma assíncrona globalmente.
Embora seja pouco frequente, um retardo de replicação pode ocorrer em uma ou algumas partições ao replicar dados geografais. O retardo na replicação pode ocorrer devido a erros raros no tráfego de rede ou taxas de resolução de conflitos maiores do que o normal.
Por exemplo, uma arquitetura na qual o aplicativo grava na Região A, mas lê da Região B, introduz uma dependência de retardo de replicação entre as duas regiões. No entanto, se o aplicativo ler e gravar na mesma região, o desempenho permanecerá constante mesmo na presença de retardo de replicação.
Avaliar o uso de consistência de sessão para operações de gravação
Na coerência da sessão, você usa o token de sessão para operações de leitura e gravação.
Para operações de leitura, o Azure Cosmos DB envia o token de sessão armazenado em cache para o servidor com a garantia de recebimento de dados que correspondem ao token de sessão especificado (ou mais recente).
Para operações de gravação, o Azure Cosmos DB envia o token de sessão para o banco de dados com a garantia de persistir os dados somente se o servidor tiver se atualizado em relação ao token de sessão fornecido. Em contas de gravação de região única, a região de gravação sempre tem a garantia de estar atualizada em relação ao token de sessão. No entanto, em contas de gravação de várias regiões, a região em que você grava pode não ter se atualizado com as gravações emitidas em outra região. Se o cliente gravar na Região A com um token de sessão da Região B, a Região A não poderá manter os dados até que atualize as alterações feitas na Região B.
É melhor usar tokens de sessão somente para operações de leitura e não para operações de gravação ao passar tokens de sessão entre instâncias de cliente.
Mitigar atualizações rápidas para o mesmo documento
As atualizações do servidor para resolver ou confirmar a ausência de conflitos podem colidir com gravações disparadas pelo aplicativo quando o mesmo documento é atualizado repetidamente. Atualizações repetidas em rápida sucessão para o mesmo documento experimentam latências mais altas durante a resolução de conflitos.
Embora intermitências ocasionais em atualizações repetidas para o mesmo documento sejam inevitáveis, considere explorar uma arquitetura em que novos documentos são criados, em vez disso, se o tráfego de estado estável vir atualizações rápidas para o mesmo documento durante um longo período.
Interrupções de leitura e gravação
Os clientes de contas de uma única região sofrerão perda de disponibilidade de leitura e gravação até que o serviço seja restaurado.
As contas de várias regiões apresentarão comportamentos diferentes dependendo das seguintes configurações e tipos de interrupção.
| Configuração | Interrupção | Impacto na disponibilidade | Impacto na durabilidade | O que fazer |
|---|---|---|---|---|
| Região única de gravação | Interrupção da região de leitura | Todos os clientes redirecionam automaticamente as leituras para outras regiões. Não há perda de disponibilidade de leitura ou gravação para todas as configurações. A exceção é uma configuração de duas regiões com coerência forte, que perde a disponibilidade de gravação até a restauração do serviço. Ou, se você habilitar o failover gerenciado pelo serviço, o serviço marcará a região como com falha e ocorrerá um failover. | Sem perda de dados. | Durante a interrupção, verifique se há RUs (Unidades de Solicitação) suficientes provisionadas nas regiões restantes para dar suporte ao tráfego de leitura. Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme apropriado. |
| Região única de gravação | Interrupção da região de gravação | Os clientes redirecionam as leituras para outras regiões. Sem o failover gerenciado pelo serviço, os clientes sofrem perda de disponibilidade de gravação. A restauração da disponibilidade de gravação ocorre automaticamente quando a interrupção termina. Com o failover de gerenciamento de serviço, os clientes terão perda de disponibilidade de gravação até que os serviços gerenciem um failover para uma nova região de gravação selecionada por você. |
Se você não selecionar o nível de coerência forte, o serviço poderá não replicar alguns dados para as regiões ativas restantes. Essa replicação depende do nível de coerência selecionado por você. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos. | Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego de leitura. Não acione um failover manual durante a interrupção, pois isso não terá sucesso. Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme apropriado. As contas que usam a API para NoSQL também podem recuperar os dados não replicados na região com falha do seu feed de conflitos. |
| Várias regiões de gravação | Qualquer interrupção regional | Há uma possibilidade de perda de disponibilidade de gravação temporária, que é análoga a uma única região de gravação com failover gerenciado pelo serviço. O failover da região de resolução de conflitos também pode causar uma perda de disponibilidade de gravação se um alto número de gravações conflitantes ocorrer no momento da paralisação. | Os dados atualizados recentemente na região com falha podem ficar indisponíveis nas regiões ativas restantes, dependendo do nível de coerência selecionado. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos. | Durante a interrupção, verifique se há RUs provisionadas suficientes nas regiões restantes para dar suporte ao tráfego de leitura. Quando a interrupção terminar, você pode ajustar novamente as RUs provisionadas conforme apropriado. Se possível, o Azure Cosmos DB recupera automaticamente dados não replicados na região com falha. Essa recuperação automática usa o método de resolução de conflitos que você configura para contas que usam a API para NoSQL. Para contas que usam outras APIs, essa recuperação automática usa last write wins. |
Informações adicionais sobre interrupções de área de leitura
A região afetada está desconectada e marcada como offline. Os SDKs do Azure Cosmos DB redirecionam as chamadas de leitura para a próxima região disponível na lista de regiões preferenciais.
Se nenhuma das regiões na lista de regiões preferenciais estiver disponível, as chamadas retornarão automaticamente à região de gravação atual.
Não é necessária nenhuma alteração no código do aplicativo para lidar com as interrupções da região de leitura. Quando a região de leitura afetada estiver novamente online, ela será sincronizada com a região de gravação atual e estará disponível novamente para atender às solicitações de leitura depois que ela estiver totalmente atualizada.
Leituras subsequentes são redirecionadas para a região recuperada sem exigir nenhuma alteração ao código do aplicativo. Durante o failover e o reingresso de uma região anteriormente com falha, o Azure Cosmos DB continua a honrar as garantias de coerência de leitura.
Mesmo em um evento raro e infeliz em que uma região de gravação do Azure tornar-se permanentemente irrecuperável, não haverá perda de dados se a conta do Azure Cosmos DB de várias regiões estiver configurada com coerência forte. Uma conta do Azure Cosmos DB de várias regiões tem as características de durabilidade especificadas anteriormente na seção Durabilidade.
Informações adicionais sobre interrupções de área de gravação
Durante uma interrupção na região de gravação, a conta do Azure Cosmos DB promove uma região secundária para ser a nova região de gravação primária quando o failover gerenciado por serviço é configurado na conta do Azure Cosmos DB. O failover ocorrerá em outra região na ordem de prioridade de região especificada.
Observe que o failover manual não deve ser disparado e não terá sucesso na presença de uma interrupção da região de origem ou de destino. O motivo é que o procedimento de failover inclui uma verificação de consistência que requer conectividade entre as regiões.
Quando a região afetada anteriormente estiver novamente online, todos os dados de gravação que não foram replicados quando a região falhou serão disponibilizados por meio do feed de conflitos. Aplicativos podem ler o feed de conflitos, resolvê-los com base na lógica específica do aplicativo e gravar os dados atualizados de volta no contêiner do Azure Cosmos DB conforme apropriado.
Depois que a região de gravação afetada anteriormente for recuperada, ela será exibida como "online" no portal do Azure e ficará disponível como uma região de leitura. Nesse ponto, é seguro voltar para a região recuperada como a região de gravação usando [PowerShell, a CLI do Azure ou o portal do Azure](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account. Não há perda de dados ou disponibilidade antes, durante ou depois de alternar a região de gravação. O aplicativo continua sendo altamente disponível.
Aviso
No caso de uma interrupção da região de gravação, em que a conta do Azure Cosmos DB promove uma região secundária para ser a nova região de gravação primária por meio de failover gerenciado pelo serviço, a região de gravação original não será promovida de volta como a região de gravação automaticamente depois de recuperada. É sua responsabilidade alternar de volta para a região recuperada como a região de gravação usando o PowerShell, a CLI do Azure ou o portal do Microsoft Azure (uma vez que seja seguro fazê-lo, conforme descrito acima).
Detecção, notificação e gerenciamento de interrupção
Para contas de região única, os clientes experimentam uma perda de disponibilidade de leitura e gravação durante uma interrupção da região do Azure Cosmos DB. As contas de várias regiões apresentarão comportamentos diferentes, conforme descrito na tabela a seguir.
| Regiões de gravação | Failover gerenciado pelo serviço | O que esperar | O que fazer |
|---|---|---|---|
| Região única de gravação | Não habilitado | No caso de uma interrupção em uma região de leitura quando você não estiver usando coerência forte, todos os clientes serão redirecionados para outras regiões. Não há perda de disponibilidade de leitura ou gravação e não há perda de dados. Quando você usa coerência forte, uma interrupção em uma região de leitura pode afetar a disponibilidade de gravação se menos de duas regiões de leitura permanecerem. No caso de uma interrupção na região de gravação, os clientes terão perda de disponibilidade de gravação. Se você não selecionou a coerência forte, o serviço poderá não replicar alguns dados para as regiões ativas restantes. Essa replicação depende do nível de coerência selecionado. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos. O Azure Cosmos DB restaura a disponibilidade de gravação quando a interrupção termina. |
Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego de leitura. Não acione um failover manual durante a interrupção, pois isso não terá sucesso. Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme apropriado. |
| Região única de gravação | Habilitado | No caso de uma interrupção em uma região de leitura quando você não estiver usando coerência forte, todos os clientes serão redirecionados para outras regiões. Não há perda de disponibilidade de leitura ou gravação e não há perda de dados. Quando você usa coerência forte, a interrupções de uma região de leitura pode afetar a disponibilidade de gravação se menos de duas regiões de leitura permanecerem. Se houver uma interrupção na região de gravação, os clientes sofrerão a perda da disponibilidade de gravação até que o Azure Cosmos DB eleja uma nova região como a nova região de gravação de acordo com suas preferências. Se você não selecionou a coerência forte, o serviço poderá não replicar alguns dados para as regiões ativas restantes. Essa replicação depende do nível de coerência selecionado. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos. |
Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego de leitura. Não acione um failover manual durante a interrupção, pois isso não terá sucesso. Quando a interrupção terminar, você pode mover a região de gravação de volta para a região original e ajustar novamente as RUs provisionadas conforme apropriado. As contas que usam a API para NoSQL também podem recuperar os dados não replicados na região com falha do seu feed de conflitos. |
| Várias regiões de gravação | Não aplicável | Os dados atualizados recentemente na região com falha podem ficar indisponíveis nas regiões ativas restantes. Os níveis de coerência de sessão, eventual e de prefixo coerente garantem uma desatualização inferior a 15 minutos. A desatualização limitada garante menos de K atualizações ou T segundos, dependendo da configuração. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos. | Durante a interrupção, verifique se há RUs provisionadas suficientes nas regiões restantes para dar suporte ao tráfego de leitura. Quando a interrupção terminar, você pode ajustar novamente as RUs provisionadas conforme apropriado. Se possível, o Azure Cosmos DB recupera dados não replicados na região com falha. Essa recuperação usa o método de resolução de conflitos que você configura para as contas que utilizam a API para NoSQL. Para contas que utilizam outras APIs, essa recuperação usa last write wins. |
Testar para alta disponibilidade
Mesmo se a conta do Azure Cosmos DB estiver altamente disponível, o aplicativo poderá não ser corretamente projetado para permanecer altamente disponível. Para testar a alta disponibilidade de ponta a ponta do aplicativo como parte de seus testes de aplicativo ou simulações de DR (recuperação de desastre), desabilite temporariamente o failover gerenciado pelo serviço para a conta. Invoque o failover manual usando o PowerShell, a CLI do Azure ou o portal do Azure e monitore o failover do aplicativo. Depois de concluir o teste, você pode fazer o failback para a região primária e restaurar o failover gerenciado pelo serviço para a conta.
Importante
Não invoque o failover manual durante uma interrupção do Azure Cosmos DB na região de origem ou de destino. O failover manual requer conectividade de região para manter a coerência dos dados, portanto, não será bem-sucedido.