Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo descreve o suporte de alta disponibilidade (confiabilidade) no Azure Cosmos DB para NoSQL e abrange as zonas de disponibilidade, bem como a recuperação de desastres entre regiões e a continuidade de 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 precisa se preocupar com nenhum tipo de correção ou manutenção planejada. O Azure Cosmos DB garante SLAs para disponibilidade e latência P99 durante todas as operações de manutenção automática que o sistema executa.
O Azure Cosmos DB mitiga automaticamente as falhas de réplica, garantindo pelo menos três réplicas dos seus dados em cada região do Azure para a sua conta, dentro de um quórum de quatro réplicas. Essa garantia resulta em um RTO de 0 e um RPO de 0 para interrupções de nó individuais, sem exigir alterações ou configurações de aplicativos. Para obter informações sobre RTO e RPO, consulte O que são continuidade de negócios, alta disponibilidade e recuperação de desastres?.
Suporte à zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de datacenters dentro de cada região do Azure. Quando uma zona falha, os serviços podem fazer failover 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 ver se a sua região suporta zonas de disponibilidade, consulte a lista de regiões suportadas.
Recomendamos o uso de redundância de zona em regiões onde ela é suportada, especialmente para contas de uma única região.
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. A habilitação da redundância de zona impede a perda total de disponibilidade devido à falha de uma zona de disponibilidade.
Como as zonas de disponibilidade são fisicamente separadas e fornecem fonte de alimentação, rede e resfriamento distintos, os SLAs de disponibilidade do Azure Cosmos DB são maiores para contas com redundância de zona do que contas que não usam zonas de disponibilidade.
Redundância de zona e contas multirregionais
Se tiver uma conta multirregião, pode opcionalmente ativar a redundância de zona em qualquer uma ou em todas as regiões da conta que suportam zonas de disponibilidade. As contas de várias regiões podem alcançar contratos de nível de serviço (SLAs) de alta disponibilidade, e habilitar a redundância de zona pode melhorar ainda mais os SLAs de disponibilidade geral alcançados nessas regiões.
Para contas de várias regiões, o impacto da redundância de zona na disponibilidade do banco de dados do Cosmos DB para NoSQL depende do nível de consistência da conta e de 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 sua conta de várias regiões:
| Nível de consistência da conta | Regiões com zonas de disponibilidade ativadas | Impacto do uso de zonas de disponibilidade |
|---|---|---|
| Síncrono (Forte) | Uma única região de leitura secundária | Grande vantagem da redundância de zona. Fornece maior valor porque a perda de uma região de leitura nesse cenário pode afetar a disponibilidade de gravação. |
| Síncrono (Forte) | Duas ou mais regiões de leitura secundária | Menor valor para a redundância de zona. Fornece valor marginal porque o sistema pode aproveitar o quórum dinâmico caso uma região de leitura perca disponibilidade, o que permite que as gravações continuem. |
| Assíncrono (Consistência Limitada ou mais fraca) | Uma ou mais regiões de leitura secundária | Menor valor para a 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 escrita e quaisquer regiões secundárias | Grande vantagem da redundância de zona. Garante maior disponibilidade para operações de gravação em caso de falhas numa zona de disponibilidade. |
Custo de habilitar a redundância de zona
As regiões onde a redundância de zona está ativada são cobradas com uma sobretaxa de 25%. No entanto, o preço premium para zonas de disponibilidade é dispensado para contas configuradas com gravações em várias regiões e/ou para coleções configuradas com o modo de dimensionamento automático.
Adicionar 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.
Melhorias no SLA
Para aumentar a resiliência e a disponibilidade de uma conta do Azure Cosmos DB, você pode implementar uma abordagem em camadas, que inclui:
- Habilitando redundância de zona.
- Adicionar uma ou mais regiões adicionais.
- Habilitando gravações em várias regiões.
A abordagem em camadas protege a conta em cada etapa do caminho: desde 4 '9s' de disponibilidade para uma configuração de região única sem redundância de zona, passando por 4,5 '9s' para uma única região com redundância de zona, até 5 '9s' de disponibilidade para configuração de várias regiões com a opção de escrita em várias regiões habilitada.
A tabela a seguir contém um resumo dos 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 | Escritas em várias regiões e numa única região sem zonas de disponibilidade | Escritas em várias regiões e em uma única região com zonas de disponibilidade | Gravações em múltiplas regiões, com ou sem zonas de disponibilidade |
|---|---|---|---|---|---|
| SLA de disponibilidade de gravação | 99,99% | 99.995% | 99,99% | 99.995% | 99,999% |
| Consultar a disponibilidade do SLA | 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 | Depende do nível de consistência. Para obter mais informações, consulte Compromissos entre consistência, disponibilidade e desempenho. | Depende do nível de consistência. Para obter mais informações, consulte Compromissos entre consistência, disponibilidade e desempenho. | Depende do nível de consistência. Para obter mais informações, consulte Compromissos entre consistência, disponibilidade e desempenho. |
| Interrupção regional: disponibilidade | Perda de disponibilidade | Perda de disponibilidade | Nenhuma perda de disponibilidade para falha de região de leitura, temporária para falha de região de gravação | Nenhuma perda de disponibilidade para falha de região de leitura, temporária para falha de região de gravação | Nenhuma perda de disponibilidade de leitura, perda temporária de disponibilidade de gravação na região afetada |
| Preço (1) | Não aplicável | Taxa de RU/s x 1,25 provisionada | Regiões RU/s x N provisionadas | RU/s provisionado x taxa de 1,25 x regiões N (2) | Taxa de escrita em 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 aplica-se apenas a regiões nas quais você habilita zonas de disponibilidade.
Configurar zonas de disponibilidade
Criar um recurso com zonas de disponibilidade ativadas
Você pode configurar zonas de disponibilidade somente quando adicionar uma nova região a uma conta NoSQL do Azure Cosmos DB.
Para habilitar o suporte à zona de disponibilidade, você pode usar:
Ativar 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 suporte à zona de disponibilidade).
Recuperação de desastres entre regiões e continuidade de negócios
A recuperação de desastres (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. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.
Para DR, a Microsoft usa o modelo de responsabilidade compartilhada . Neste modelo, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. No entanto, muitos serviços do Azure não replicam dados automaticamente nem possuem mecanismos de fallback para mudar de uma região com falha para outra região ativada. 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 da plataforma Azure como serviço (PaaS) fornece recursos e orientações para dar suporte à DR. Você pode usar recursos específicos do serviço para apoiar a recuperação rápida e ajudar a desenvolver o seu plano de DR.
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 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:
- Cópias de segurança contínuas efetuam cópias de segurança de cada região a cada 100 segundos. Eles permitem restaurar os dados para qualquer momento com uma granularidade de um segundo. Em cada região, o backup depende dos dados gravados 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.
- Backups periódicos fazem backup completo de todas as partições de todos os contêineres em sua conta, sem sincronização entre partições. O intervalo mínimo de backup é 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 consistência que você configura na conta. A tabela a seguir detalha, para todos os níveis de consistência, o RPO de uma conta do Azure Cosmos DB implantada em pelo menos duas regiões.
| Nível de consistência | RPO para falha numa região |
|---|---|
| Sessão, prefixo consistente, eventual | Menos de 15 minutos |
| Estagnaçã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 é 100.000 operações de gravação ou 300 segundos. Esse valor define o RPO mínimo para os dados quando se utiliza a obsolescência limitada.
Para obter mais informações sobre as diferenças entre os níveis de consistência, consulte Níveis de consistência no Azure Cosmos DB.
Failover gerenciado por serviço
Se a sua solução exigir tempo de disponibilidade contínua durante interrupções de regiões, poderá configurar o Azure Cosmos DB para replicar os seus dados em várias regiões e realizar failover transparente para as regiões operacionais quando necessário.
As contas de uma única região podem perder a acessibilidade após uma interrupção regional. Para garantir a continuidade de 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 (de leitura) e habilite o failover gerenciado por serviço.
O failover gerido pelo serviço permite que o Azure Cosmos DB realize o failover da região de gravação de uma conta de várias regiões para preservar a continuidade do negócio a custo da perda de dados, conforme descrito anteriormente na seção Durabilidade. Os failovers regionais são detetados e tratados no cliente do Azure Cosmos DB. Eles não exigem nenhuma alteração do aplicativo. Para obter instruções sobre como habilitar várias regiões de leitura e failover gerenciado por serviço, consulte Gerenciar uma conta do Azure Cosmos DB usando o portal do Azure.
Importante
Se você tiver escolhido 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 realize a transferência dos bancos de dados de conta para regiões disponíveis. Na ausência dessa configuração, a conta sofrerá perda de disponibilidade de gravação durante toda a duração da interrupção da região de gravação. O failover manual não terá êxito devido à falta de conectividade regional.
Aviso
Mesmo com o failover gerido pelo serviço ativado, a interrupção parcial pode exigir intervenção manual da equipa responsável pelo serviço Azure Cosmos DB. Nesses cenários, pode levar até 1 hora (ou mais) para que o failover entre em vigor. Para uma melhor disponibilidade de gravação durante interrupções parciais, recomendamos habilitar 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 escritas em várias regiões. Essa configuração é útil para reduzir a latência de gravação em aplicativos geograficamente distribuídos.
Quando se configura uma conta do Azure Cosmos DB para múltiplas regiões de escrita, não há suporte para consistência forte e podem surgir conflitos de escrita. Para obter mais informações sobre como resolver esses conflitos, consulte Tipos de conflito e políticas de resolução ao usar várias regiões de gravação.
Importante
Atualizar o mesmo ID de documento com freqüência (ou recriar o mesmo ID de documento com freqüência após TTL ou excluir) terá um efeito no 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 árbitro em conflitos de gravação.
Práticas recomendadas para gravações em várias regiões
Aqui estão algumas práticas recomendadas a serem consideradas ao escrever em várias regiões.
Mantenha o tráfego local local
Quando utiliza gravações em várias regiões, o aplicativo deve emitir tráfego de leitura e gravação originado na região local, exclusivamente para a região local do Cosmos DB. Para um desempenho ideal, evite chamadas entre regiões.
É importante que o aplicativo minimize os conflitos, evitando os seguintes antipadrõ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
Usando 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 do atraso de replicação
Não é possível configurar contas de gravação de várias regiões para obter uma consistência forte. A região à qual se está a escrever responde imediatamente logo depois de o Azure Cosmos DB replicar os dados localmente, enquanto replica os dados globalmente de forma assíncrona.
Embora seja pouco frequente, um atraso de replicação pode ocorrer em uma ou algumas partições quando você está replicando dados geograficamente. O atraso de replicação pode ocorrer devido a um erro raro no tráfego de rede ou a taxas de resolução de conflitos mais altas 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 do atraso 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 atraso de replicação.
Avaliar o uso da consistência da sessão para operações de gravação
Na consistê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 receber 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 alcançado o token de sessão fornecido. Em contas de gravação de uma única região, a região de gravação sempre tem a garantia de ter alcançado o token de sessão. No entanto, em contas com escrita em várias regiões, a região em que se escreve pode não ter alcançado as escritas emitidas para outra região. Se o cliente escrever na Região A com um token de sessão da Região B, a Região A não conseguirá persistir os dados até sincronizar com as alterações realizadas na Região B.
É melhor usar tokens de sessão apenas para operações de leitura e não para operações de gravação quando você estiver passando tokens de sessão entre instâncias de cliente.
Minimize as atualizações rápidas sobre o mesmo documento
As atualizações do servidor destinadas a resolver ou confirmar a ausência de conflitos podem colidir com escritas efetuadas 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 picos ocasionais em atualizações repetidas do mesmo documento sejam inevitáveis, você pode considerar explorar uma arquitetura em que novos documentos sejam criados, caso o tráfego em estado estável apresente atualizações rápidas do mesmo documento ao longo de um período prolongado.
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.
Contas de várias regiões experimentam comportamentos diferentes, dependendo das seguintes configurações e tipos de paralisação.
| Configuração | Indisponibilidade | Impacto na disponibilidade | Impacto na durabilidade | O que fazer |
|---|---|---|---|---|
| Região de gravação única | Consulte a interrupção da região | 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 excepção é uma configuração de duas regiões com forte consistência, que perde a disponibilidade de gravação até à restauração do serviço. Ou, se você habilitar o failover gerenciado pelo serviço, o serviço marcará a região como falha e ocorrerá um failover. | Sem perda de dados. | Durante a interrupção, verifique se há unidades de solicitação (RUs) provisionadas suficientes nas regiões restantes para dar suporte ao tráfego de leitura. Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme necessário. |
| Região de gravação única | Registar falha de região | Os clientes redirecionam leituras para outras regiões. Sem failover gerido pelo serviço, os clientes experienciam perda de disponibilidade para gravação. A restauração da disponibilidade de gravação ocorre automaticamente quando a interrupção termina. Com o failover gerenciado pelo serviço, os clientes experimentam perda de disponibilidade de gravação até que o serviço gerencie um failover para uma nova região de gravação selecionada. |
Se você não selecionar o nível de consistência forte, o serviço pode não replicar alguns dados para as regiões ativas restantes. Essa replicação depende do nível de consistência selecionado. Se a região afetada sofrer perda permanente de dados, você poderá perder dados não replicados. | Durante a interrupção, certifique-se de que haja RUs aprovisionadas suficientes nas regiões restantes para dar suporte ao tráfego de leitura. Não acione uma comutação manual durante a interrupção, porque ela não pode ser bem-sucedida. Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme necessário. As contas que usam a API para NoSQL também podem recuperar os dados não replicados na região afetada por falha do seu feed de conflitos. |
| Várias regiões de gravação | Qualquer interrupção regional | Há uma possibilidade de perda temporária de disponibilidade de gravação, que é análoga a uma única região de gravação com failover gerenciado por 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 grande número de gravações conflitantes ocorrer no momento da interrupção. | Os dados atualizados recentemente na região com falha podem não estar disponíveis nas regiões ativas restantes, dependendo do nível de consistência selecionado. Se a região afetada sofrer perda permanente de dados, você poderá perder dados não replicados. | Durante a interrupção, certifique-se de que há RUs provisionadas suficientes nas regiões restantes para suportar mais tráfego. Quando a interrupção terminar, você poderá reajustar as RUs provisionadas conforme apropriado. Se possível, o Azure Cosmos DB recupera automaticamente os 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, esta recuperação automática usa o método última gravação prevalece. |
Informações adicionais sobre interrupções na região de leitura
A região afetada é desconectada e marcada como offline. Os SDKs do Azure Cosmos DB redirecionam chamadas de leitura para a próxima região disponível na lista de regiões preferidas.
Se nenhuma das regiões na lista de regiões preferidas estiver disponível, as chamadas retornarão automaticamente para a região de gravação atual.
Nenhuma alteração é necessária no código do aplicativo para lidar com interrupções de região de leitura. Quando a região de leitura afetada está online novamente, ela é sincronizada com a região de gravação atual e fica disponível novamente para atender às solicitações de leitura depois de ter recuperado completamente.
As leituras subsequentes são redirecionadas para a região recuperada sem necessidade de alterar o código da aplicação. Durante o failover e a rejunção de uma região com falha anterior, o Azure Cosmos DB continua a honrar as garantias de consistência de leitura.
Mesmo em um evento raro e infeliz em que uma região de gravação do Azure é permanentemente irrecuperável, não há perda de dados se sua conta do Azure Cosmos DB de várias regiões estiver configurada com forte consistência. 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 na região de gravação
Durante uma falha na região de gravação, a conta do Azure Cosmos DB promove uma região secundária como nova região de gravação primária quando o failover gerido pelo serviço é configurado na conta do Azure Cosmos DB. O failover ocorre para outra região, seguindo a ordem de prioridade que especificou para as regiões.
O failover manual não deve ser acionado e não terá êxito 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 online novamente, 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. Os aplicativos podem ler o feed de conflitos, resolver os conflitos 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 se recuperar, ela será exibida como "online" no portal do Azure e ficará disponível como uma região de leitura. Neste 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, enquanto ou depois de alternar a região de gravação. Seu aplicativo continua a estar altamente disponível.
Aviso
No caso de uma interrupção de 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 do failover gerido pelo serviço, a região de gravação original não será promovida novamente à região de gravação automaticamente após a sua recuperação. É sua responsabilidade voltar para a região recuperada como a região de gravação usando o PowerShell, a CLI do Azure ou o portal do Azure (uma vez seguro fazê-lo, conforme descrito acima).
Deteção, notificação e gerenciamento de interrupções
Para contas de uma única região, os clientes enfrentam uma perda de disponibilidade de leitura e escrita durante uma falha na região do Azure Cosmos DB. Contas de várias regiões apresentam comportamentos diferentes, conforme descrito na tabela a seguir.
| Escrever regiões | Failover gerenciado por serviço | O que esperar | O que fazer |
|---|---|---|---|
| Região de gravação única | Não ativado | Se houver uma interrupção numa região de leitura quando não estiver a usar uma consistê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 se usa consistência forte, uma falha numa região de leitura pode afetar a disponibilidade para escrita se restarem menos de duas regiões de leitura. Se houver uma interrupção na região de gravação, os clientes terão perda de disponibilidade de gravação. Se você não selecionou consistência forte, o serviço pode não replicar alguns dados para as regiões ativas restantes. Essa replicação depende do nível de consistência selecionado. Se a região afetada sofrer perda permanente de dados, você poderá perder dados não replicados. O Azure Cosmos DB restaura a disponibilidade de gravação quando a interrupção termina. |
Durante a interrupção, certifique-se de que haja RUs aprovisionadas suficientes nas regiões restantes para dar suporte ao tráfego de leitura. Não acione uma comutação manual durante a interrupção, porque ela não pode ser bem-sucedida. Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme necessário. |
| Região de gravação única | Ativado(a) | Se houver uma interrupção numa região de leitura quando não estiver a usar uma consistê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ê está usando consistência forte, a interrupção 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 experimentarão perda de 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 consistência forte, o serviço pode não replicar alguns dados para as regiões ativas restantes. Essa replicação depende do nível de consistência selecionado. Se a região afetada sofrer perda permanente de dados, você poderá perder dados não replicados. |
Durante a interrupção, certifique-se de que haja RUs aprovisionadas suficientes nas regiões restantes para dar suporte ao tráfego de leitura. Não acione uma comutação manual durante a interrupção, porque ela não pode ser bem-sucedida. Quando a interrupção terminar, você poderá mover a região de gravação de volta para a região original e reajustar 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 fluxo de conflitos. |
| Várias regiões de gravação | Não aplicável | Os dados atualizados recentemente na região com falha podem não estar disponíveis nas regiões ativas restantes. Os níveis de consistência eventual, de prefixo consistente e de sessão garantem um atraso de menos de 15 minutos. A obsolescência limitada garante menos de K atualizações ou T segundos, dependendo da configuração. Se a região afetada sofrer perda permanente de dados, você poderá perder dados não replicados. | Durante a interrupção, certifique-se de que há RUs provisionadas suficientes nas regiões restantes para suportar mais tráfego. Quando a interrupção terminar, você poderá reajustar 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 contas que usam a API para NoSQL. Para contas que usam outras APIs, essa recuperação utiliza o método de prioridade para a última gravação. |
Testes de alta disponibilidade
Mesmo que sua conta do Azure Cosmos DB esteja altamente disponível, seu aplicativo pode não ser projetado corretamente para permanecer altamente disponível. Para testar a alta disponibilidade completa do seu aplicativo como parte dos testes de aplicativos ou exercícios de recuperação de desastres (DR), desative 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 seu aplicativo. Depois de concluir o teste, você pode fazer failover para a região primária e restaurar o failover gerenciado pelo serviço para a conta.
Importante
Não invoque um failover manual durante uma falha no Azure Cosmos DB, quer na região de origem, quer na de destino. O failover manual requer conectividade de região para manter a consistência dos dados, portanto, não terá êxito.