Compartilhar via

Melhores práticas e visão geral dos grupos de failover (Banco de Dados SQL do Azure)

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

O recurso de grupos de failover permite gerenciar a duplicação e o failover de alguns ou todos os bancos de dados em um servidor lógico para um servidor lógico de outra região. Este artigo fornece uma visão geral do recurso de grupo de failover com melhores práticas e recomendações para usá-lo com o Banco de Dados SQL do Azure.

Para começar a usar o recurso, revise Configurar o grupo de failover.

Observação

Este artigo aborda os grupos de failover para o Banco de Dados SQL do Azure. Para a Instância Gerenciada de SQL do Azure, consulte Grupos de failover na Instância Gerenciada de SQL do Azure.

Para saber mais sobre a recuperação de desastre do Banco de Dados SQL do Azure, assista a este vídeo:

Visão geral

O recurso de grupos de failover permite gerenciar a duplicação e o failover dos bancos de dados para outra região do Azure. Você pode escolher todos, ou um subconjunto de, bancos de dados de usuário em um servidor lógico para serem replicados em outro servidor lógico. É é uma abstração declarativa junto ao recurso de replicação geográfica ativa, projetado para simplificar a implantação e o gerenciamento de bancos de dados replicados geograficamente em escala.

Para os RPO e RTO do failover geográfico, confira Visão geral da continuidade dos negócios.

Redirecionamento de ponto de extremidade

Além disso, os grupos de failover fornecem pontos de extremidade de ouvinte de leitura/gravação e somente leitura que permanecem inalterados durante failovers geográficos. Você não precisa alterar a cadeia de conexão para seu aplicativo após um failover geográfico, pois as conexões são automaticamente roteadas para o primário atual. Um failover geográfico alterna todos os bancos de dados secundários no grupo para a função primária. Após a conclusão do failover geográfico, o registro DNS é atualizado automaticamente para redirecionar os pontos de extremidade para a nova região.

Descarregar cargas de trabalho somente leitura

Para reduzir o tráfego para seus bancos de dados primários, você também pode usar os bancos de dados secundários em um grupo de failover para descarregar cargas de trabalho somente leitura. Use o ouvinte somente leitura para direcionar o tráfego somente leitura para um banco de dados secundário legível.

Recuperando um aplicativo

Adicionar a redundância do banco de dados regional é apenas parte da solução para obter uma continuidade de negócios completa. A recuperação de um aplicativo (serviço) de ponta a ponta após uma falha catastrófica exige a recuperação de todos os componentes que constituem o serviço e quaisquer serviços dependentes. O software cliente (por exemplo, um navegador com um JavaScript personalizado), front-ends da Web, armazenamento e DNS são exemplos desses componentes. É fundamental que todos os componentes sejam resilientes às mesmas falhas e fiquem disponíveis dentro do RTO (objetivo de tempo de recuperação) de seu aplicativo. Portanto, você precisa identificar todos os serviços dependentes e entender as garantias e os recursos que eles fornecem. Em seguida, você deve tomar as medidas necessárias para garantir que seu serviço funcione durante o failover dos serviços dos quais ele depende.

Política de failover

Os grupos de failover oferecem suporte a duas políticas de failover:

  • Gerenciado pelo cliente (recomendado): os clientes podem executar um failover de um grupo quando percebem uma interrupção inesperada que afeta um ou mais bancos de dados no grupo de failover. Ao usar ferramentas de linha de comando, como o PowerShell, a CLI do Azure ou a API Rest, o valor da política de failover para gerenciado pelo cliente é manual.
  • Gerenciado pela Microsoft: no caso de uma interrupção generalizada que afete uma região primária, a Microsoft inicia o failover de todos os grupos de failover afetados que têm sua política de failover configurada para ser gerenciada pela Microsoft. O failover gerenciado pela Microsoft não será iniciado para grupos de failover individuais ou um subconjunto de grupos de failover em uma região. Ao usar ferramentas de linha de comando, como o PowerShell, a CLI do Azure ou a API Rest, o valor da política de failover para gerenciado pela Microsoft é automatic.

Cada política de failover tem um conjunto exclusivo de casos de uso e expectativas correspondentes sobre o escopo de failover e a perda de dados, conforme resume a tabela a seguir:

Política de failover Escopo de failover Caso de uso Possível perda de dados
Gerenciado pelo cliente
(Recomendado)		 Grupo(s) de failover Um ou mais bancos de dados em um grupo de failover é afetado por uma interrupção e fica indisponível. Você pode optar por fazer failover. Sim
Gerenciado pela Microsoft Todos os grupos de failover na região Uma interrupção generalizada em um datacenter, zona de disponibilidade ou região causa indisponibilidade de bancos de dados e a equipe de serviço SQL do Microsoft Azure decide disparar um failover forçado.
Use essa opção somente quando quiser delegar a responsabilidade de recuperação de desastres à Microsoft e o aplicativo for tolerante ao RTO (tempo de inatividade) de pelo menos uma hora ou mais.		 Sim

Gerenciado pelo cliente

Em raras ocasiões, a disponibilidade interna ou a alta disponibilidade não são suficientes para mitigar uma interrupção, e seus bancos de dados em um grupo de failover podem ficar indisponíveis por um período que não é aceitável para o Contrato de Nível de Serviço (SLA) do aplicativo que usa os bancos de dados. Os bancos de dados podem estar indisponíveis devido a um problema localizado que afeta apenas alguns bancos de dados ou podem estar no nível do datacenter, da zona de disponibilidade ou da região. Em qualquer um desses casos, para restaurar a continuidade dos negócios, você pode iniciar um failover forçado.

Definir sua política de failover para gerenciada pelo cliente é altamente recomendado, pois mantém você no controle de quando iniciar um failover e restaurar a continuidade dos negócios. Você pode iniciar um failover quando notar uma interrupção inesperada afetando um ou mais bancos de dados no grupo de failover.

Gerenciado pela Microsoft

Com uma política de failover gerenciada pela Microsoft, a responsabilidade pela recuperação de desastres é delegada ao serviço SQL do Azure. Para que o serviço SQL do Azure inicie um failover forçado, as seguintes condições devem ser atendidas:

  • Interrupção do datacenter, da zona de disponibilidade ou do nível da região causada por um evento de desastre natural, alterações de configuração, bugs de software ou falhas de componentes de hardware e muitos bancos de dados na região são afetados.
  • O período de carência expirou. Como a verificação da escala da interrupção e sua mitigação envolvem ações humanas, o período de carência não pode ser definido abaixo de uma hora.

Quando essas condições são atendidas, o serviço SQL do Azure inicia failovers forçados para todos os grupos de failover na região que têm a política de failover definida como gerenciada pela Microsoft.

Importante

Use a política de failover gerenciada pelo cliente para testar e implementar seu plano de recuperação de desastres. Não confie no failover gerenciado pela Microsoft, que só pode ser executado pela Microsoft em circunstâncias extremas. Um failover gerenciado pela Microsoft seria iniciado para todos os grupos de failover na região com a política de failover definida como gerenciada pela Microsoft. Ele não pode ser iniciado para um grupo de failover individual. Se precisar da capacidade de failover seletivo do grupo de failover, use a política de failover gerenciada pelo cliente.

Defina a política de failover como Gerenciada pela Microsoft somente quando:

  • Você deseja delegar a responsabilidade de recuperação de desastres ao serviço SQL do Azure.
  • O aplicativo é tolerante ao seu banco de dados ficar indisponível por pelo menos uma hora ou mais.
  • É aceitável acionar failovers forçados algum tempo após o término do período de carência, pois o tempo real para o failover forçado pode variar significativamente.
  • É aceitável que todos os bancos de dados dentro do grupo de failover façam failover, independentemente de sua configuração de redundância de zona ou status de disponibilidade. Embora os bancos de dados configurados para redundância de zona sejam resilientes a falhas zonais e possam não ser afetados por uma interrupção, eles ainda serão submetidos a failover se fizerem parte de um grupo de failover com uma política de failover gerenciado pela Microsoft.
  • É aceitável ter failovers forçados de bancos de dados no grupo de failover sem levar em consideração a dependência do aplicativo de outros serviços ou componentes do Azure usados pelo aplicativo, o que pode causar degradação do desempenho ou indisponibilidade do aplicativo.
  • É aceitável incorrer em uma quantidade desconhecida de perda de dados, pois o tempo exato do failover forçado não pode ser controlado e ignora o status de sincronização dos bancos de dados secundários.
  • Todos os bancos de dados primários e secundários no grupo de failover e todas as relações de replicação geográfica têm a mesma camada de serviço, o mesmo nível de computação (provisionado ou sem servidor) e o mesmo tamanho da computação (DTUs ou vCores). Se o objetivo de nível de serviço (SLO) de todos os bancos de dados não corresponder, a política de failover será consequentemente atualizada do serviço Gerenciado pela Microsoft para Gerenciado pelo Cliente pelo serviço SQL do Azure.

Quando um failover é acionado pela Microsoft, uma entrada para o nome da operação Grupo de failover do SQL do Azure é adicionada ao log de atividades do Azure Monitor. A entrada inclui o nome do grupo de failover em Recurso e Evento iniciado por exibe um único hífen (-) para indicar que o failover foi iniciado pela Microsoft. Essas informações também podem ser encontradas na página Log de atividades do novo servidor primário ou instância no portal do Azure.

Terminologia e recursos

  • FOG (grupo de failover)

    Um grupo de failover é um grupo nomeado de bancos de dados gerenciados por um único servidor lógico no Azure que pode fazer failover como uma unidade para outra região do Azure caso alguns ou todos os bancos de dados primários não estejam disponíveis devido a uma interrupção na região primária.

    Importante

    O nome do grupo de failover deve ser globalmente exclusivo no domínio .database.windows.net.

  • Servidores

    Alguns ou todos os bancos de dados de usuário em um servidor lógico podem ser colocados em um grupo de failover. Além disso, um servidor dá suporte a vários grupos de failover em um único servidor.

  • Primário

    O servidor lógico que hospeda os bancos de dados primários no grupo de failover.

  • Secundário

    O servidor lógico que hospeda os bancos de dados secundários no grupo de failover. O secundário não pode estar na mesma região do Azure do primário.

  • Failover (sem perda de dados)

    O failover executa uma sincronização de dados completa entre o banco de dados primário e o secundário antes de o secundário mudar para a função de primário. Isso assegura que não ocorra nenhuma perda de dados. O failover só é possível quando o primário está acessível. O failover é usado nos seguintes cenários:

    • Executar simulações de recuperação de desastre (DR) em produção quando a perda de dados não é aceitável
    • Relocar a carga de trabalho para uma região diferente
    • Retornar a carga de trabalho para a região primária após a mitigação da interrupção (failback)

  • Failover forçado (potencial perda de dados)

    O failover forçado alterna imediatamente o secundário para a função primária sem esperar que as alterações recentes se propaguem do primário. Essa operação pode resultar em potencial perda de dados. Um failover forçaco é usado como um método de recuperação durante as interrupções quando o primário não está acessível. Quando a interrupção for atenuada, o primário antigo será reconectado automaticamente e se tornará um novo secundário. Um failover pode ser executado para realizar o failback, retornando as réplicas para suas funções primárias e secundárias originais.

  • Período de carência com perda de dados

    Como os dados são replicados para o secundário usando replicação assíncrona, o failover forçado de grupos com políticas de failover gerenciado pela Microsoft pode resultar em perda de dados. Você pode personalizar a política de failover para refletir a tolerância do seu aplicativo à perda de dados. Ao configurar GracePeriodWithDataLossHours, você pode controlar quanto tempo o serviço de SQL do Azure espera antes de iniciar um failover forçado, o que pode resultar em perda de dados.

  • Adicionar bancos de dados individuais ao grupo de failover

    É possível colocar vários bancos de dados individuais no mesmo servidor lógico no mesmo grupo de failover. Se você adicionar um banco de dados individual ao grupo de failover, ele criará automaticamente um banco de dados secundário usando a mesma edição e tamanho da computação no servidor secundário especificado quando o grupo de failover foi criado. Se você adicionar um banco de dados que já possui um banco de dados secundário no servidor secundário, esse vínculo de replicação geográfica é herdado pelo grupo. Quando você adiciona um banco de dados que já tem um banco de dados secundário em um servidor que não faz parte do grupo de failover, um novo banco de dados secundário é criado no servidor secundário.

    Importante

    • Certifique-se de que o servidor lógico secundário não pode ter um banco de dados com o mesmo nome, a menos que seja um banco de dados secundário existente.
    • Se um banco de dados contiver objetos OLTP in-memory, o banco de dados primário e o banco de dados secundário de réplica de área geográfica deverão ter camadas de serviço correspondentes, pois os objetos OLTP in-memory residem na memória. Uma camada de serviço inferior no banco de dados de réplica de área geográfica pode resultar em problemas de memória insuficiente. Se isso ocorrer, a réplica de área geográfica pode falhar ao recuperar o banco de dados, deixando o banco de dados secundário não disponível junto com objetos OLTP in-memory na área geográfica secundária. Isso, por sua vez, também pode fazer com que os failovers não sejam bem-sucedidos. Para evitar isso, verifique se a camada de serviço do banco de dados secundário de área geográfica corresponde à do banco de dados primário. As atualizações da camada de serviço podem ser operações de tamanho de dados e demorar um pouco para serem concluídas.

  • Adicionar bancos de dados no pool elástico para o grupo de failover

    É possível colocar todos ou vários bancos de dados dentro de um pool elástico no mesmo grupo de failover. Se o banco de dados primário estiver em um pool elástico, o banco de dados secundário é criado automaticamente no pool elástico com o mesmo nome (pool secundário). Você deve garantir que o servidor secundário contém um pool elástico com exatamente o mesmo nome e capacidade livre suficiente para hospedar os bancos de dados secundários que serão criados pelo grupo de failover. Se você adicionar um banco de dados no pool que já possui um banco de dados secundário no pool secundário, esse vínculo de replicação geográfica é herdado pelo grupo. Quando você adiciona um banco de dados que já tem um banco de dados secundário em um servidor que não faz parte do grupo de failover, um novo banco de dados secundário é criado no pool secundário.

  • Ouvinte de leitura/gravação do grupo de failover

    Um registro CNAME DNS que aponta para a primária atual. Ele é criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho de leitura/gravação se reconecte de modo transparente ao primário quando o primário é alterado após o failover. Quando o grupo de failover é criado em um servidor, o registro DNS CNAME para a URL do ouvinte é formado como <fog-name>.database.windows.net. Depois do failover, o registro DNS é atualizado automaticamente para redirecionar o ouvinte para a nova região.

  • Ouvinte de somente leitura do grupo de failover

    Um registro CNAME DNS que aponta para a secundário atual. Ele é criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho SQL somente leitura se conecte de modo transparente ao secundário quando o secundário é alterado após o failover. Quando o grupo de failover é criado em um servidor, o registro DNS CNAME para a URL do ouvinte é formado como <fog-name>.secondary.database.windows.net. Por padrão, o failover do ouvinte somente leitura é desabilitado, pois garante que o desempenho do primário não seja afetado quando o secundário estiver offline. No entanto, isso também significa que as sessões somente leitura não poderão conectar-se até que o secundário seja recuperado. Se não for possível tolerar o tempo de inatividade em sessões somente leitura e se der para usar o primário para tráfego somente leitura e de leitura/gravação às custas da possível degradação do desempenho do primário, você poderá habilitar o failover para o ouvinte somente leitura configurando a propriedade AllowReadOnlyFailoverToPrimary. Nesse caso, o tráfego somente leitura é redirecionado automaticamente para o primário se o secundário não estiver disponível.

    Observação

    A propriedade AllowReadOnlyFailoverToPrimary só terá efeito se a política de failover gerenciado pela Microsoft estiver habilitada e um failover forçado for disparado. Nesse caso, se a propriedade for definida como True, o novo primário servirá para as sessões de leitura/gravação e somente leitura.

  • Vários grupos de failover

    Você pode configurar vários grupos de failover para o mesmo par de servidores a fim de controlar o escopo de failovers geográficos. Cada grupo sofre failover de forma independente. Se seu aplicativo de locatário por banco de dados for implantado em várias regiões e usar pools elásticos, é possível usar essa funcionalidade para misturar bancos de dados primários e secundários em cada pool. Dessa forma, você poderá reduzir o impacto de uma interrupção apenas para alguns bancos de dados de locatário.

Arquitetura do grupo de failover

Um grupo de failover no Banco de Dados SQL do Azure pode incluir um ou vários bancos de dados, normalmente usados pelo mesmo aplicativo. Um grupo de failover precisa ser configurado no servidor primário, que o conectará ao servidor secundário em outra região do Azure. O grupo de failover pode incluir alguns ou todos os bancos de dados no servidor primário. O diagrama a seguir ilustra uma configuração típica de um aplicativo de nuvem com redundância geográfica usando vários bancos de dados e um grupo de failover.

O diagrama mostra uma configuração típica de um aplicativo de nuvem com redundância geográfica usando vários bancos de dados e um grupo de failover.

Ao projetar um serviço com a continuidade dos negócios em mente, siga as diretrizes gerais e as melhores práticas descritas neste artigo. Ao configurar um grupo de failover, verifique se a autenticação e o acesso à rede no secundário estão configurados para funcionar corretamente após o failover geográfico, quando a área geográfica secundária se tornar a nova primária. Para obter detalhes, consulte Segurança do Banco de Dados SQL do Azure após a recuperação de desastre. Para mais informações, consulte Como projetar soluções de nuvem para recuperação de desastre.

Usar regiões emparelhadas

Ao criar seu grupo de failover entre o servidor primário e secundário, use regiões emparelhadas, pois os grupos de failover em regiões emparelhadas têm melhor desempenho em comparação com regiões não emparelhadas.

Seguindo práticas de implantação seguras, o Banco de Dados SQL do Azure geralmente não atualiza regiões emparelhadas ao mesmo tempo. No entanto, não é possível prever qual região será atualizada primeiro, portanto, a ordem de implantação não é garantida. Às vezes, seu servidor primário é atualizado primeiro e, às vezes, é atualizado segundo.

Se você tiver replicação geográfica ou grupos de failover configurados para bancos de dados que não se alinham com o emparelhamento de região do Azure, use agendamentos de janela de manutenção diferentes para seus bancos de dados primário e secundário. Por exemplo, você pode selecionar a janela de manutenção Dia da semana para seu banco de dados secundário e a janela de manutenção Fim de semana para o banco de dados primário.

Propagação inicial

Ao adicionar bancos de dados ou pools elásticos ou a um grupo de failover, há uma fase de propagação inicial antes que a duplicação de dados comece. A fase de propagação inicial é a operação mais longa e cara. Após a conclusão da propagação inicial, os dados são sincronizados, e somente as alterações de dados subsequentes são replicadas. O tempo que leva para a propagação inicial ser concluída depende do tamanho de seus dados, do número de bancos de dados replicados, da carga nos bancos de dados primários e da velocidade do vínculo de rede entre o banco de dados primário e o secundário. Em circunstâncias normais, a possível velocidade de propagação é de até 500 GB por hora para o Banco de Dados SQL. A propagação é executada em todos os bancos de dados em paralelo.

Número de bancos de dados no grupo de failover

O número de bancos de dados em um grupo de failover afeta diretamente a duração das operações de Failover e Failover forçado.

  • Durante um Failover (também conhecido como Recuperação planejada), garantimos que todos os bancos de dados primários estejam totalmente sincronizados com seus secundários e estejam em estado pronto. Para evitar sobrecarregar o painel de controle, os bancos de dados são preparados em lotes. Portanto, é altamente recomendável limitar o número de bancos de dados em um grupo de failover.
  • No caso de um Failover forçado, a fase de preparação é acelerada, pois a sincronização de dados não é iniciada. Para obter durações de failover mais rápidas e previsíveis, pode ser benéfico manter um número menor de bancos de dados no grupo de failover.

Usar vários grupos de failover para fazer failover de vários bancos de dados

Um ou mais grupos de failover podem ser criados entre dois servidores em diferentes regiões (servidores primário e secundário). Cada grupo pode conter um ou vários bancos de dados que são recuperados como uma unidade no caso de alguns ou todos os bancos de dados primários ficarem indisponíveis devido a uma interrupção na região primária. Criar um grupo de failover cria um banco de dados geograficamente secundário com o mesmo objetivo de serviço do primário. Se você adicionar uma relação de replicação geográfica existente a um grupo de failover, verifique se a área geograficamente secundária esta configurado com o mesmo nível de serviço e tamanho da computação da primária.

Usar o ouvinte de leitura/gravação (primário)

Para cargas de trabalho de leitura/gravação, use <fog-name>.database.windows.net como o nome do servidor na cadeia de conexão. As conexões são direcionadas automaticamente para o primário. Esse nome não é alterado após o failover. Observe que o failover envolve a atualização do registro DNS, para que conexões de cliente sejam redirecionadas ao novo primário somente após a atualização do cliente do cache DNS. A TTL (vida útil) do registro DNS dos ouvintes primário e secundário é de 30 segundos.

Usar o ouvinte somente leitura (secundário)

Se você tiver cargas de trabalho somente leitura logicamente isoladas que são tolerantes à latência de dados, é possível executa-las na área geográfica secundária. Para sessões somente leitura, use <fog-name>.secondary.database.windows.net como o nome do servidor na cadeia de conexão. As conexões são direcionadas automaticamente para a área geográfica secundária. Também recomendamos que você indique a intenção de leitura na cadeia de conexão usando ApplicationIntent=ReadOnly.

Nas camadas de serviço Premium, Comercialmente Crítico e Hiperescala, o Banco de Dados SQL dá suporte ao uso de réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura usando o parâmetro ApplicationIntent=ReadOnly na cadeia de conexão. Ao configurar uma área geográfica secundária poderá usar essa funcionalidade para se conectar a uma réplica somente leitura na localização geográfica primária ou na localização geográfica secundária:

Para se conectar a uma réplica somente leitura na localização do secundário, use ApplicationIntent=ReadOnly e <fog-name>.secondary.database.windows.net.

Possível degradação do desempenho após o failover

Um aplicativo típico do Azure usa vários serviços do Azure e consiste em vários componentes. O failover de um grupo é acionado com base apenas no estado do Banco de Dados SQL do Azure. Outros serviços do Azure na região primária podem não ser afetados pela interrupção, e seus componentes ainda podem estar disponíveis nessa região. Assim que os bancos de dados primários alternarem para a DR (região secundária), a latência entre os componentes dependentes pode aumentar. Para evitar o impacto de maior latência no desempenho do aplicativo, verifique se há redundância de todos os componentes do aplicativo na região da DR, siga estas diretrizes de segurança de rede e organize o failover geográfico dos componentes com o banco de dados.

Potencial perda de dados após o failover forçado

Se ocorrer uma interrupção na região primária, as transações recentes podem não ter sido replicadas para a secundária geográfica e pode haver perda de dados se um failover forçado for executado.

Importante

Os pools elásticos com 800 DTUs ou menos, 8 vCores ou menos e mais de 250 bancos de dados podem encontrar problemas, incluindo failovers geográficos planejados mais longos e diminuição do desempenho. A ocorrência desses problemas é mais provável para cargas de trabalho com uso intensivo de gravação, quando replicas geográficas são separadas por uma grande extensão geográfica ou quando várias réplicas geográficas secundárias são usadas para cada banco de dados. Um sintoma desses problemas é um aumento no retardo da replicação geográfica ao longo do tempo, potencialmente levando a uma perda de dados mais ampla em uma paralisação. Esse retardo pode ser monitorado usando sys.dm_geo_replication_link_status. Se esses problemas ocorrerem, a mitigação incluirá o dimensionamento do pool para ter mais DTUs ou vCores ou reduzir o número de bancos de dados replicados geograficamente no pool.

Failback

Quando os grupos de failover estiverem configurados com a política de failover gerenciada pela Microsoft, o failover para o servidor secundário geográfico será iniciado durante um cenário de desastre de acordo com o período de carência definido. O failback para o primário antigo precisará ser iniciado manualmente.

Limitações e permissões

Consulte o guia configurar grupo de failover para obter uma lista de permissões e limitações.

Gerenciar programaticamente grupos de failover

Os grupos de failover também podem ser gerenciados programaticamente usando o Azure PowerShell, a CLI do Azure e a API REST. Para obter mais informações, analise Configurar grupo de failover.

Conteúdo relacionado