Confiabilidade no Azure Cosmos DB

Azure Cosmos DB para NoSQL é um serviço de banco de dados multimodelo distribuído globalmente que dá suporte a modelos de dados de documentos com esquemas flexíveis. Azure Cosmos DB oferece recursos de confiabilidade abrangentes, incluindo vários níveis de consistência que permitem balancear o desempenho e a disponibilidade, implantações com redundância de zona que protegem contra falhas de zona de disponibilidade, replicação de várias regiões com failover gerenciado pelo serviço ou gerenciado pelo cliente e opções de backup contínuas e periódicas para proteção de dados.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar Azure Cosmos DB resilientes a várias possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade, interrupções na região e manutenção do serviço. Ele também descreve como usar backups para se recuperar de outros tipos de problemas e realça as principais informações sobre o SLA (contrato de nível de serviço) Azure Cosmos DB.

Recomendações de implantação de produção

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, segurança, custo, operações e desempenho. Para entender como essas áreas influenciam umas às outras e contribuem para uma solução de Azure Cosmos DB confiável, consulte as práticas recomendadas Architecture para Azure Cosmos DB.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

O recurso primário que você implanta é uma Azure Cosmos DB conta. Cada conta pode ter vários bancos de dados com vários contêineres. Os contêineres servem como unidades lógicas de distribuição e escalabilidade. Você pode criar contêineres, como coleções, tabelas e grafos, dependendo da API usada para interagir com Azure Cosmos DB. Para obter mais informações sobre o modelo de recurso, consulte Databases, contêineres e itens em Azure Cosmos DB. Cada contêiner usa particionamento, que dá suporte a alta escala e alto desempenho.

Você configura a taxa de transferência, que representa a quantidade de recursos do sistema que você pode usar para consultar e trabalhar com seus dados. Você pode provisionar manualmente a taxa de transferência, usar o dimensionamento automático para ajustar dinamicamente a capacidade com base nos requisitos da carga de trabalho ou usar o tipo de conta sem servidor a ser cobrado pelo uso real.

Uma única conta pode abranger várias regiões do Azure, o que aumenta sua resiliência a interrupções de região. Você pode configurar várias regiões para leitura e, se usar a camada Business Critical, poderá utilizar várias regiões para gravação. Azure Cosmos DB replica geograficamente seus dados automaticamente. O comportamento de replicação geográfica é afetado pela configuração que você usa, como o nível de consistência, que indica como você deseja fazer compensações entre consistência de dados, disponibilidade, latência e taxa de transferência. Diferentes níveis de consistência otimizam para diferentes preocupações, dão suporte a garantias diferentes e fornecem diferentes tipos de replicação entre regiões.

Arquitetura física

Azure Cosmos DB armazena vários replicas de seus dados para redundância. O serviço automaticamente mitiga interrupções de réplicas ao manter o quorum entre as réplicas em cada região. Essa abordagem garante alta disponibilidade e protege contra perda de dados durante falhas de nó individuais, sem a necessidade de alterações ou configuração do aplicativo.

Internamente, o Azure Cosmos DB gerencia seus dados por meio de várias estruturas, incluindo partições físicas, conjuntos de partição e conjuntos de réplica. Para obter informações mais detalhadas sobre como Azure Cosmos DB funciona, consulte A distribuição de dados global com Azure Cosmos DB - nos bastidores.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Recomendamos que você use os SDKs de Azure Cosmos DB. Os SDKs implementam automaticamente o suporte para uma série de considerações de resiliência, incluindo tratamento transitório de falhas por meio de novas tentativas automáticas e respeitando as respostas de limite de taxa enviadas pelo serviço. Para obter mais informações, consulte Design aplicativos resilientes com Azure Cosmos DB SDKs.

Ao trabalhar com uma conta de várias regiões, o SDK também dá suporte a uma estratégia de disponibilidade baseada em limiar, também chamada hedging, em que envia solicitações de leitura paralelas para diversas regiões e aceita a resposta mais rápida. Essa abordagem pode melhorar o desempenho do aplicativo quando uma região experimenta temporariamente uma latência maior do que o normal.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de 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. Microsoft seleciona as zonas de disponibilidade a serem usadas.

Uma conta Azure Cosmos DB pode usar várias regiões (locais) para distribuição global, escala e failover. Você configura a redundância de zona separadamente para cada região em sua conta.

O uso da redundância de zona em Azure Cosmos DB não tem nenhum impacto perceptível no desempenho ou na latência. Ele não requer nenhum ajuste no modo de consistência selecionado e não requer nenhuma modificação no código do aplicativo.

É recomendável usar a redundância de zona em regiões em que há suporte, especialmente para contas de região única. 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.

Se você não habilitar a redundância de zona, a conta será não zonal nessa região. As contas nonzonal podem localizar réplicas em uma única zona de disponibilidade, o que pode levar a uma possível indisponibilidade se essa zona específica apresentar um problema.

Requirements

• Region support: Você pode habilitar a redundância de zona em regiões Azure que dão suporte a zonas de disponibilidade. Para ver se sua região dá suporte a zonas de disponibilidade, consulte a lista de regiões com suporte.

  A redundância de zona não é uma configuração para toda a conta. Azure Cosmos DB contas podem abranger várias regiões e cada região pode ser configurada independentemente para usar zonas de disponibilidade. Regiões que não dão suporte a zonas de disponibilidade não impedem que você habilite a redundância de zona em outras regiões na mesma conta.

• Contas sem servidor: Você só pode configurar contas sem servidor com redundância de zona ao criá-las. Não é possível converter contas sem servidor existentes sem zonas de disponibilidade em uma configuração de zona de disponibilidade. Para cargas de trabalho críticas para a missão, recomendamos que você use o throughput provisionado.

Considerações

• Várias interrupções simultâneas de zona: Uma conta de região única com redundância de zona pode manter a disponibilidade de leitura/gravação quando uma interrupção afeta uma única zona de disponibilidade. No entanto, se a interrupção afetar várias zonas de disponibilidade ou toda a região, as contas de região única perderão o acesso de leitura e gravação até que o serviço seja restaurado. Considere implantar uma conta multirregional se você precisar ser resiliente a múltiplas zonas falhando simultaneamente.

• 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. É altamente recomendável habilitar a redundância de zona quando sua conta estiver configurada para usar uma única região ou se ela estiver configurada para usar uma única região de gravação com várias regiões de leitura.

Custo

Regiões em que a redundância de zona está habilitada são cobradas com um valor adicional. No entanto, o preço premium das zonas de disponibilidade não é cobrado para contas configuradas com gravações multirregionais e para coleções configuradas para usar o modo de escalonamento automático de taxa de transferência. Para obter mais informações, veja Preços do Azure Cosmos DB.

Configurar o suporte à zona de disponibilidade

Para a maioria das contas, você habilita a redundância de zona somente quando adiciona uma nova região a uma conta Azure Cosmos DB. Para habilitar o suporte à zona de disponibilidade em uma conta existente, adicione uma região e habilite a redundância de zona nela. Você pode seguir um processo para adicionar uma região temporária para que possa configurar a redundância de zona em sua região original. Para obter etapas detalhadas, consulte Habilitar redundância de zona em conta do Azure Cosmos DB.

Para contas sem servidor, você deve habilitar a redundância de zona ao criar a conta.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando você configura uma conta Azure Cosmos DB para redundância de zona e todas as zonas estão operacionais.

• Cross-zone operation: Azure Cosmos DB roteia automaticamente solicitações para réplicas entre zonas de disponibilidade, para que qualquer réplica possa atender a uma solicitação.

• Replicação de dados entre zonas: Quando um cliente faz uma alteração em qualquer dado, essa alteração é aplicada a várias réplicas em zonas diferentes para obter quorum. Essa abordagem é conhecida como replicação síncrona. A replicação síncrona garante um alto nível de consistência de dados, o que reduz a probabilidade de perda de dados durante uma falha de zona. As zonas de disponibilidade estão localizadas relativamente próximas, o que significa que há um efeito mínimo na latência ou na taxa de transferência.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando você configura uma conta Azure Cosmos DB para redundância de zona e há uma interrupção em uma das zonas.

• Detection and response: A plataforma Azure Cosmos DB é responsável por detectar uma falha em uma zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.

• Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.

• Solicitações ativas: quando uma zona de disponibilidade fica indisponível, o Azure Cosmos DB encerrará quaisquer solicitações em andamento conectadas a réplicas na zona afetada, e o aplicativo deverá repetir as solicitações. Verifique se o aplicativo está preparado seguindo as diretrizes transitórias de tratamento de falhas.

• Perda de dados esperada: Não há nenhuma perda de dados esperada de uma falha de zona.

• Tempo de inatividade esperado: Durante interrupções de zona, as conexões podem sofrer breves interrupções que normalmente duram alguns segundos à medida que o tráfego é redistribuído. Verifique se os aplicativos estão preparados seguindo as diretrizes de tratamento de falhas transitórias.

• Redistribution: Azure Cosmos DB automaticamente redireciona solicitações de entrada para réplicas saudáveis em outras zonas de disponibilidade. Quando uma zona de disponibilidade sofre uma interrupção, a plataforma realoca automaticamente a capacidade de transferência provisionada para outras réplicas.

Recuperação de zona

Quando a zona de disponibilidade é recuperada, Azure Cosmos DB restaura automaticamente as réplicas na zona de disponibilidade e redireciona o tráfego entre réplicas normalmente.

Testar falhas em zonas

O failover e a recuperação da Zona de Disponibilidade do Azure Cosmos DB são totalmente gerenciados pela Microsoft. Você não precisa iniciar nem validar processos relacionados à falha de zona de disponibilidade.

Resiliência a falhas em toda a região

Quando você implanta uma conta de Azure Cosmos DB em uma única região, uma interrupção em toda a região que afeta todos os nós Azure Cosmos DB normalmente não causa perda de dados, mas impede que seu aplicativo acesse dados. Azure Cosmos DB restaura o acesso a dados após a recuperação do serviço na região afetada. A perda de dados ocorrerá somente se a região apresentar um desastre irrecuperável.

Para se preparar para os raros casos de interrupções de região, você pode configurar Azure Cosmos DB para dar suporte a vários níveis de durabilidade e disponibilidade usando uma destas abordagens:

• Várias regiões de leitura com uma única região de gravação. Opcionalmente, você pode habilitar o Failover Gerenciado pelo Serviço ou o PPAF (Failover Automático por Partição).
• Várias regiões de gravação.

A tabela a seguir resume as opções de recuperação disponíveis com base na configuração da conta e no tipo de interrupção. Seções posteriores deste artigo fornecem detalhes abrangentes dessas opções e do comportamento associado.

SDKs e resiliência

Os SDKs de Azure Cosmos DB são uma parte importante da estratégia de resiliência do aplicativo. Quando você tem uma conta de várias regiões, a configuração do SDK afeta como as solicitações são roteadas entre regiões, incluindo as regiões preferenciais às quais se conectar e regiões que devem ser excluídas. Os SDKs monitoram a disponibilidade de regiões e partições e podem reconfigurar-se dinamicamente para usar regiões e partições saudáveis, como por meio do disjuntor no nível da partição.

Para obter mais informações sobre como o SDK dá suporte à alta disponibilidade, consulte a documentação de alta disponibilidade do SDK que você usa:

• Azure Cosmos DB .NET SDK v3
• Azure Cosmos DB Java SDK v4
• SDK do Python do Azure Cosmos DB

Potencial perda de dados durante interrupções de região

Quando você implanta uma conta Azure Cosmos DB em várias regiões, a durabilidade dos dados depende do nível de consistência configurado na conta. A tabela a seguir detalha, para todos os níveis de consistência, o RPO (objetivo de ponto de recuperação) de uma conta de Azure Cosmos DB implantada em pelo menos duas regiões. O RPO representa a possível perda de dados durante uma falha de região.

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.

Várias regiões de leitura com uma única região de gravação

Se sua solução exigir tempo de atividade contínuo durante interrupções de região, você poderá configurar Azure Cosmos DB para replicar seus dados em várias regiões, com gravações manipuladas pela região primária. Opcionalmente, você pode configurar seus aplicativos para se conectar a regiões de leitura específicas, o que pode ajudar a melhorar seu desempenho. Se uma região tiver uma interrupção, a conta poderá continuar operando a partir de regiões saudáveis.

Processo de failover entre regiões

Você pode configurar o SDK do Azure Cosmos DB com uma lista priorizada de regiões de leitura. O SDK conecta seu aplicativo à primeira região disponível da lista. Durante uma interrupção de região de leitura, o SDK detecta a interrupção da região por meio de códigos de resposta de back-end, marca-a como indisponível e roteia operações futuras para a próxima região disponível na lista de preferências. Verifique se a lista de regiões preferenciais está definida corretamente e se alinha aos requisitos de negócios e latência. Para obter diretrizes detalhadas, consulte Solucionar problemas de disponibilidade do SDK do Azure Cosmos DB.

O failover é o processo de tornar uma das regiões da sua conta indisponível, completamente ou em parte. O efeito de um failover depende se a região é uma região de gravação ou uma região de leitura:

• Se uma região de gravação ficar indisponível, outra região se tornará a região de gravação.
• Se uma região de leitura ficar indisponível, essa região não poderá atender a solicitações de leitura e outras regiões serão usadas para operações de leitura.

Azure Cosmos DB fornece vários tipos de failover:

• Per-partition automatic failover (PPAF): Internamente, o Azure Cosmos DB distribui seus dados entre várias partições físicas. Se ocorrer um problema com a infraestrutura que dá suporte a uma partição, outras partições poderão não ser afetadas. O PPAF permite que contas de região de gravação única façam failover automático de partições individuais para uma região secundária, mantendo partições íntegras na região primária. O PPAF pode ajudar a minimizar o tempo de inatividade e habilitar uma recuperação mais rápida durante uma falha parcial na região. Para obter mais informações, consulte Como integrar e adotar o Failover Automático por Partição (PPAF) para Azure Cosmos DB.

  Note

  O Failover Automático por Partição está em versão prévia pública. O recurso é fornecido sem um Contrato de Nível de Serviço. Para obter mais informações, consulte Termos de Uso Complementares para Versões Prévias do Microsoft Azure.

• Failover forçado: Você pode ficar offline em uma das regiões da sua conta. Isso também é conhecido como um failover gerenciado pelo cliente ou uma operação de região offline. Essa é a abordagem recomendada para restaurar rapidamente a disponibilidade durante uma interrupção. Você é responsável por detectar a interrupção e disparar o failover. Você também pode usar failovers forçados para simular cenários de indisponibilidade de região para testes, como durante um teste de recuperação de desastre.

  Se você deixar a região de gravação offline, a região de leitura com a prioridade seguinte mais alta se tornará a nova região de gravação. Se você colocar uma região de leitura offline, seus aplicativos poderão se conectar a qualquer outra região de leitura na conta.

  Um failover forçado da sua região de gravação apresenta a possibilidade de perda de dados para quaisquer gravações não replicadas.

  Após um failover forçado, Microsoft deve colocar a região novamente online. Para regiões íntegras, esse processo é automatizado, mas pode levar até vários dias. Se a região não voltar a ficar online dentro de um ou dois dias, abra um caso de suporte para solicitar assistência.

• Alterar a região de gravação: Quando as regiões estiverem íntegras, você poderá alterar a região de gravação da sua conta. Essa alteração é efetivamente um failover planejado da região de gravação para sua conta.

  A alteração da região de gravação não resulta em perda de dados, pois a replicação de dados é sincronizada antes de a nova região de gravação ser promovida. Pode haver uma breve interrupção, mas os clientes que usam lógica de repetição e outras técnicas transitórias de tratamento de falhas normalmente não experimentam impacto significativo.

  Essa operação exige que as regiões sejam íntegras, portanto, não pode ser usada durante uma interrupção em uma região.

• Service-managed failover: Quando sua conta usa failover gerenciado pelo serviço, a Microsoft é responsável por decidir quando realizar o failover entre regiões. Para habilitar o failover gerenciado pelo serviço, especifique prioridades para cada região. No entanto, o processo de declarar uma interrupção e disparar o failover gerenciado pelo serviço pode levar um tempo significativo - potencialmente uma hora ou mais. Para uma recuperação mais rápida, execute um failover forçado em vez de aguardar o failover gerenciado pelo serviço ser disparado.

  Se a Microsoft acionar o failover gerenciado pelo serviço para a região de gravação da conta, qualquer gravação não replicada poderá ser perdida.

  Após um failover gerenciado pelo serviço, Microsoft deve colocar uma região novamente online. Microsoft coloca a região online automaticamente, mas esse processo pode levar vários dias.

Requirements

Region support: Você pode configurar qualquer região Azure como uma região de leitura para sua conta Azure Cosmos DB.

Custo

Adicionar uma região de leitura adicional a uma conta Azure Cosmos DB aumenta os custos existentes para cada região. Para obter mais informações, veja Preços do Azure Cosmos DB.

Configurar várias regiões de leitura

• Adicionar regiões de leitura a uma conta: Você pode configurar várias regiões em sua conta ao criar a conta ou a qualquer momento após a criação da conta. Para obter mais informações, consulte Adicionar/remover regiões de sua conta de banco de dados.

• Habilitar failover: Alguns tipos de failover devem ser configurados com antecedência:

  • Failover Automático por Partição: para obter mais informações, consulte Como integrar e adotar o Failover Automático por Partição (PPAF) para o Azure Cosmos DB.

  • Failover gerenciado pelo serviço: Primeiro, habilite o failover gerenciado pelo serviço. Em seguida, defina as prioridades de failover para cada região em sua conta.

Planejamento e gerenciamento de capacidade

Se o aplicativo espalhar solicitações entre regiões e uma região ficar offline, as regiões restantes experimentarão maior volume de solicitação. Use a escalabilidade automática de largura de banda para ajustar dinamicamente a capacidade com base na demanda. Se você usar a taxa de transferência provisionada, planeje a capacidade adequada para lidar com a perda de uma região sem degradação do serviço e considere o superprovisionamento. Para obter mais informações, consulte Gerenciar capacidade com provisionamento excessivo.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando você configura uma conta Azure Cosmos DB com várias regiões de leitura e todas as regiões estão operacionais.

• Operação entre regiões: Seu aplicativo configura a região que deve receber operações de leitura. Você pode configurar seu aplicativo com uma lista priorizada de regiões ou excluir algumas regiões. Para obter mais informações sobre como a seleção de região funciona, consulte Diagnose e solucione problemas da disponibilidade de SDKs de Azure Cosmos DB em ambientes multi-regionais.

  Todas as operações de escrita são direcionadas para a região de escrita da sua conta.

• Replicação de dados entre regiões: Todas as operações de gravação ocorrem na região primária da sua conta. As escritas são replicadas para outras regiões de leitura com base no nível de consistência configurado da conta. Para obter informações sobre o atraso máximo de replicação, consulte Potencial perda de dados durante interrupções de região.

Comportamento durante uma falha na região de leitura

Esta seção descreve o que esperar quando você configura uma conta Azure Cosmos DB com várias regiões de leitura e há uma interrupção em uma das regiões de leitura da conta.

• Detecção e resposta: A responsabilidade de detectar a interrupção e responder depende do tipo de failover que sua conta usa.

  • PPAF: O PPAF normalmente não se aplica a interrupções de região de leitura. No entanto, para contas com consistência forte e apenas duas regiões, a perda da região de leitura reduz a conta para uma única região, o que não pode manter o quorum dinâmico. Nesse cenário, o PPAF pode ser ativado para preservar a disponibilidade, deslocando as partições afetadas para a região íntegra.

  • Failover forçado: Você é responsável por executar um failover forçado. Para obter etapas detalhadas, consulte Execute o failover forçado para sua conta do Azure Cosmos DB.

    Se você não executar um failover, o comportamento da sua conta dependerá do nível de consistência:

    • Consistência forte: a consistência forte requer duas ou mais regiões para manter o quorum dinâmico. Se houver menos de duas regiões disponíveis e você não executar um failover, a conta perderá a disponibilidade de gravação até a restauração do serviço.

    • Consistência de desatualização limitada: A consistência de desatualização limitada depende da manutenção de um limite de desatualização específico entre regiões. Se o comprimento da interrupção da região exceder o limite, o sistema não poderá manter a consistência entre gravações. Caso não execute um failover, a conta ficará sem capacidade de escrita até que o serviço seja restaurado.

  • Service-managed failover: Se o failover gerenciado pelo serviço estiver habilitado, Microsoft eventualmente detectará a interrupção e iniciará um failover de sua conta. No entanto, esse processo pode levar um tempo significativo, potencialmente uma hora ou mais. Para uma recuperação mais rápida, execute um failover forçado em vez de aguardar o failover gerenciado pelo serviço ser disparado.

• Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto:

  • Você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e configurar alertas Resource Health para notificá-lo de problemas.

  • Você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo eventuais falhas de região, e pode configurar alertas Service Health para notificá-lo de problemas.

• Solicitações ativas: Todas as solicitações ativas podem ser encerradas e precisam ser repetidas pelo cliente após a conclusão do failover. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: Uma interrupção em uma região de leitura não causa perda de dados. Azure Cosmos DB continua honrando as garantias de consistência de leitura.

• Tempo de inatividade esperado: O tempo de inatividade que sua conta enfrenta depende do tipo de failover que sua conta usa.

  • PPAF: Quando o PPAF está habilitado, o sistema detecta e se recupera automaticamente da falha, normalmente dentro de 3 minutos, sem nenhuma intervenção manual.

  • Failover forçado: O tempo de inatividade depende de:

    • Quanto tempo você leva para identificar a interrupção e iniciar um failover.

    • Quanto tempo leva o failover, que geralmente é de alguns segundos.

      Aviso

      Não execute nenhuma operação de configuração (plano de controle) na região afetada durante cenários de interrupção, pois elas resultam em inconsistência da conta e atraso na recuperação. Alguns dos exemplos de operações do plano de controle para evitar incluem:

      • Alterar a região de gravação ou modificar a prioridade de failover
      • Atualizar a conta para a configuração com múltiplas gravações
      • Atualizando níveis de consistência ou outras configurações de conta
      • Atualizando configurações de endpoints privados ou configurações de rede
      • Atualizando a capacidade de transferência da conta ou operações de escalonamento
      • Qualquer outra operação que modifique a configuração da conta ou as configurações de região

  • Failover gerenciado pelo serviço: A Microsoft é responsável por iniciar o failover gerenciado pelo serviço, e o tempo de inatividade que sua conta enfrenta é baseado no tempo que a Microsoft leva para declarar a interrupção e iniciar o failover. Em algumas situações, pode levar uma hora ou mais. Se sua conta sofrer interrupção nas operações de gravação e você precisar restaurar rapidamente a disponibilidade de gravações, realize um failover forçado.

• Redistribuição: Para failover forçado ou failover gerenciado pelo serviço, a região afetada é desconectada e marcada como offline.

  Não é necessária nenhuma alteração no código do aplicativo para lidar com as interrupções da região de leitura. Os SDKs Azure Cosmos DB redirecionam operações 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 operações de leitura retornarão automaticamente à região de gravação atual da conta, conforme configurado no serviço.

  Note

  Se você usar endpoints privados com uma conta do Azure Cosmos DB, verifique se o DNS privado está roteando corretamente após a operação da região offline. Para obter diretrizes detalhadas, consulte as considerações de failover para pontos de extremidade privados.

Comportamento durante uma falha na região de gravação

Esta seção descreve o que esperar quando você configura uma conta Azure Cosmos DB com várias regiões de leitura e há uma interrupção na região de gravação da conta.

• Detecção e resposta: A responsabilidade de detectar a interrupção e responder depende do tipo de failover que sua conta usa.

  • PPAF: Microsoft detecta automaticamente a interrupção e inicia um failover de algumas partições, se apropriado. Seu aplicativo não precisa executar nenhuma ação.

  • Failover forçado: Você é responsável por executar um failover forçado. Para obter etapas detalhadas, consulte Execute o failover forçado para sua conta do Azure Cosmos DB.

    Se você não executar um failover, a conta perderá a capacidade de gravação até a restauração do serviço.

    Se houver uma interrupção na região de gravação da sua conta, evite executar uma operação de alterar região de gravação. As alterações na região de gravação não serão bem-sucedidas se houver uma interrupção da região de origem ou de destino. O motivo é que o procedimento de alteração de região inclui uma verificação de consistência que requer conectividade entre as regiões.

  • Service-managed failover: Microsoft detecta automaticamente a interrupção e inicia um failover de sua conta. Seu aplicativo não precisa executar nenhuma ação.

• Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto:

  • Você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e configurar alertas Resource Health para notificá-lo de problemas.

  • Você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo eventuais falhas de região, e pode configurar alertas Service Health para notificá-lo de problemas.

• Solicitações ativas: Todas as solicitações ativas podem ser encerradas e precisam ser repetidas pelo cliente após a conclusão do failover. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: Se você configurar sua conta com consistência forte, nenhuma perda de dados ocorrerá. Caso contrário, quaisquer gravações não duplicadas poderão ser perdidas após a conclusão do failover. Para obter informações sobre a perda máxima de dados esperada durante uma interrupção de região, consulte Potencial perda de dados durante interrupções de região.

• Tempo de inatividade esperado: A quantidade de tempo de inatividade que sua conta experimenta depende do tipo de failover que sua conta utiliza.

  • PPAF: Quando o PPAF estiver habilitado, espere uma breve interrupção, que geralmente é de cerca de 3 minutos.

  • Failover forçado: O tempo de inatividade depende de:

    • Quanto tempo você leva para identificar a pane e iniciar um failover.
    • Quanto tempo leva o failover, que geralmente é de alguns segundos.

  Aviso

  Não execute nenhuma operação de plano de gerenciamento na região afetada em caso de interrupção, pois elas resultam em inconsistência da conta e atraso na recuperação. Alguns dos exemplos de operações do plano de controle para evitar incluem:

  • Alterar a região de gravação ou ajustar a prioridade de failover
  • Atualizar a conta para a configuração com múltiplas gravações
  • Atualizando níveis de consistência ou outras configurações de conta
  • Atualizando configurações de endpoints privados ou configurações de rede
  • Atualizando a capacidade de transferência da conta ou operações de escalonamento
  • Qualquer outra operação que modifique a configuração da conta ou as configurações de região
  • Service-managed failover: A Microsoft é responsável por iniciar o failover gerenciado pelo serviço, e o tempo de inatividade que sua conta experimenta é baseado no tempo que a Microsoft leva para declarar a interrupção e iniciar o failover. Em algumas situações, pode levar uma hora ou mais. Para restaurar rapidamente a disponibilidade de gravação, execute um failover forçado.

• Redistribuição: A redistribuição de tráfego de gravação depende do tipo de failover que sua conta usa.

  • PPAF: Azure Cosmos DB realiza failover automaticamente da partição com problema para uma região saudável.

  • Failover forçado: Quando você realiza um failover forçado, a região de gravação da sua conta é alterada para a região especificada.

  Note

  Se você usar pontos de extremidade privados com uma conta Azure Cosmos DB, verifique se o DNS privado está roteando corretamente após a operação de região offline. Para obter diretrizes detalhadas, consulte as considerações de failover para pontos de extremidade privados.

  • Failover gerenciado por serviço: O Azure Cosmos DB promove automaticamente uma das regiões secundárias da conta para ser a nova região de gravação primária. O failover ocorrerá em outra região na ordem de prioridade de região especificada.

Recuperação de região

Microsoft deve colocar uma região novamente online. Quando uma região se recupera após uma interrupção, Microsoft coloca a região online automaticamente. No entanto, esse processo pode levar vários dias.

Depois que a região estiver online, as ações executadas serão diferentes dependendo se a interrupção foi em uma região de leitura ou em uma região de gravação.

• Após interrupções na região de leitura: Quando a região afetada está online novamente, ela é sincronizada com a região de gravação atual e está disponível novamente para atender às solicitações de leitura depois de ter sido 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.

• Após interrupções na região de gravação: Quando a região afetada estiver online novamente, a região será exibida como "online" no portal do Azure e estará disponível para leitura. Neste ponto, é seguro alterar a região de gravação de volta para a região recuperada.

  Importante

  A região recuperada não será promovida automaticamente de volta como a região de escrita uma vez que for recuperada. É sua responsabilidade mudar de volta para a região recuperada como a região de gravação, uma vez que é seguro fazê-lo.

  Não há perda de dados ou disponibilidade antes ou depois de alterar a região de gravação. O aplicativo continua sendo altamente disponível.

  Se alguma escrita não foi replicada antes da região ficar offline, você poderá ler as escritas não replicadas do feed de conflitos. Seu aplicativo pode ler o feed de conflitos, resolver conflitos com base na lógica específica do aplicativo e gravar os dados atualizados de volta no contêiner conforme apropriado.

Teste de falhas na região

Seu aplicativo pode não lidar com failovers de região corretamente, mesmo que sua conta Azure Cosmos DB esteja 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 forçado usando o PowerShell, o CLI do Azure ou o portal Azure e, em seguida, monitore seu aplicativo. Depois de concluir o teste, você poderá reverter para a região primária assim que a região voltar a ficar online automaticamente e, em seguida, restaurar o failover gerenciado pelo serviço para a conta. Se a região não voltar a ficar online dentro de um ou dois dias, abra um caso de suporte para solicitar assistência.

Se sua conta usar PPAF, você poderá simular um failover de partição. Para obter mais informações, consulte Testar a configuração do PPAF (simular falha).

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 pode fornecer resiliência muito alta para interrupções de região. Também é ú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. A região do hub atua como mediador em 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 considerar o design do aplicativo e como ele funciona com várias regiões de gravação. Revise as práticas recomendadas para gravações de várias regiões.

Requirements

Region support: Você pode configurar qualquer região Azure como uma região de leitura ou gravação para sua conta Azure Cosmos DB.

Custo

Adicionar uma região de gravação adicional a uma conta Azure Cosmos DB aumenta os custos existentes para cada região. Para obter mais informações, veja Preços do Azure Cosmos DB.

Configurar várias regiões de gravação

Você pode configurar várias regiões de gravação em sua conta ao criar a conta ou a qualquer momento após a criação da conta. Para obter mais informações, consulte Configurar várias regiões de gravação.

Para usar efetivamente várias regiões de gravação, seu aplicativo também precisa ser configurado adequadamente. Consulte Configuração de escritas em várias regiões em aplicativos que usam Azure Cosmos DB.

Planejamento e gerenciamento de capacidade

Se o aplicativo espalhar solicitações entre regiões e uma região ficar offline, as regiões restantes experimentarão maior volume de solicitação. Use a escalabilidade automática de largura de banda para ajustar dinamicamente a capacidade com base na demanda. Se você usar a taxa de transferência provisionada, planeje a capacidade adequada para lidar com a perda de uma região sem degradação do serviço e considere o superprovisionamento. Para obter mais informações, consulte Gerenciar capacidade com provisionamento excessivo.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando você configura uma conta Azure Cosmos DB com várias regiões de gravação e todas as regiões estão operacionais.

• Operação entre regiões: Quando uma conta é configurada com várias regiões de gravação, seu aplicativo configura a região que deve ser usada para operações de leitura e gravação. Você pode configurar seu aplicativo com uma lista priorizada de regiões ou excluir algumas regiões. Para obter mais informações sobre como a seleção de região funciona, consulte Diagnose e solucione problemas da disponibilidade de SDKs de Azure Cosmos DB em ambientes multi-regionais. Para saber como configurar seu aplicativo, consulte Configurações de várias regiões em aplicativos que usam Azure Cosmos DB.

• Replicação de dados entre regiões: Os dados são replicados entre regiões de forma assíncrona. O atraso de replicação depende do nível de consistência da conta. Você não pode usar consistência forte para escritas em várias regiões. Para obter mais informações, consulte Potencial perda de dados durante interrupções de região.

  Quando uma conta é configurada para várias regiões de gravação, aplicativos em regiões diferentes podem fazer alterações que entram em conflito entre si. Azure Cosmos DB fornece recursos de resolução de conflitos. Para obter mais informações, consulte tipos de conflito e políticas de resolução ao usar várias regiões de gravação. Para saber mais sobre como configurar sua própria política de resolução de conflitos, consulte Manage políticas de resolução de conflitos no Azure Cosmos DB.

  Note

  Atualizar a mesma ID do documento com frequência ou recriar a mesma ID do documento com frequência depois que sua TTL expirar ou for excluída, afetará negativamente o desempenho da replicação devido a um número maior de conflitos gerados no sistema.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando você configura uma conta Azure Cosmos DB com várias regiões de gravação e há uma interrupção em uma das regiões de leitura ou gravação da conta.

• Detecção e resposta: Seu aplicativo detecta a perda da região. Azure Cosmos DB SDKs fornecem recursos automáticos de seleção de região que roteiam operações de leitura e gravação para regiões íntegras.

• Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto:

  • Você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e configurar alertas Resource Health para notificá-lo de problemas.

  • Você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo eventuais falhas de região, e pode configurar alertas Service Health para notificá-lo de problemas.

• Solicitações ativas: Todas as solicitações ativas podem ser encerradas e precisam ser repetidas pelo cliente após a conclusão do failover. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: Os dados atualizados recentemente podem ficar indisponíveis em outras regiões. Para obter informações sobre a perda máxima de dados esperada durante uma interrupção de região, consulte Potencial perda de dados durante interrupções de região. No improvável caso de que a região afetada sofra perda permanente de dados, você poderá perder dados não replicados.

• Tempo de inatividade esperado: Não há tempo de inatividade esperado em configurações de várias gravações, desde que os SDKs estejam configurados corretamente com ApplicationRegions ou PreferredRegions.

  Dica

  Para obter melhores resultados, os aplicativos distribuídos globalmente devem ser encadeados por um serviço global de balanceamento de carga, como Azure Front Door ou Gerenciador de Tráfego do Azure. Esses serviços podem detectar degradação regional e rotear automaticamente o tráfego para instâncias de aplicativo em uma região íntegra.

• Redistribuição: Os SDKs do Azure Cosmos DB detectam automaticamente que a região está instável e redirecionam as operações de leitura e escrita para a próxima região disponível na lista preferencial de regiões. Nenhuma alteração é necessária no código do aplicativo.

  Dica

  Se o aplicativo for apresentado por Azure Front Door ou Gerenciador de Tráfego, esses serviços também detectarão degradação regional e rotearão o tráfego para uma região íntegra.

Recuperação de região

Quando a região afetada estiver online novamente, a região será exibida como "online" no portal Azure e ficará disponível novamente.

Todos os dados de escrita que não foram replicados quando a região falhou sã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.

Teste de falhas na região

Para testar cenários de failover de gravação em várias regiões, você pode fazer com que uma região de gravação fique offline usando um failover forçado. Esse processo simula uma interrupção de região e você pode observar como seu aplicativo responde.

Backup e restauração

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte O que são redundância, replicação e backup?.

A perda de dados pode ocorrer devido a exclusões acidentais ou outros problemas em seu aplicativo que causam corrupção de dados. Quando você usa uma conta de região única, a perda de dados também pode ocorrer devido a um desastre irrecuperável na região Azure Cosmos DB. Para ajudá-lo a proteger contra perda de dados, Azure Cosmos DB fornece um conjunto de recursos de backup e restauração. Você pode configurar backups e retenção com base em seus requisitos de recuperabilidade e requisitos de custo. Para obter mais informações, confira Backup online e restauração de dados sob demanda no Azure Cosmos DB.

Resiliência à manutenção do serviço

Azure Cosmos DB gerencia de forma transparente todos os detalhes de nós de computação individuais e executa automaticamente a aplicação de patch e outros tipos de manutenção planejada. Os SLAs de Azure Cosmos DB para disponibilidade e latência se aplicam por meio de todas as operações de manutenção automática que o sistema executa.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Azure Cosmos DB fornece SLAs para uma variedade de configurações e características de serviço, incluindo disponibilidade, latência, taxa de transferência e consistência.

Os SLAs de disponibilidade são diferentes dependendo se você usa qualquer um dos seguintes recursos de produto:

• Capacidade provisionada
• Conta de região única com suporte à zona de disponibilidade (redundância de zona)
• Contas que usam várias regiões de leitura
• Contas que usam várias regiões de gravação (camada Crítica para Negócios)

Conteúdo relacionado

• Confiabilidade do Azure
• visão geral Azure Cosmos DB
• Níveis de consistência no Azure Cosmos DB
• Distribuição global de dados com Azure Cosmos DB
• Diagnose e solucionar problemas de disponibilidade de SDKs Azure Cosmos DB em ambientes multi-regionais