Visão geral dos grupos de failover & práticas recomendadas (Banco de Dados SQL do Azure)

Aplica-se a:Banco de Dados SQL do Azure

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

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

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

Descrição geral

O recurso de grupos de failover permite gerenciar a replicação e o failover de 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 ser replicado para outro servidor lógico. É uma abstração declarativa sobre o 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 RPO e RTO de failover geográfico, consulte Visão geral da continuidade de negócios.

Redirecionamento de ponto final

Os grupos de failover fornecem pontos finais de escuta somente leitura e leitura que permanecem inalterados durante failovers geográficos. Não é necessário alterar a cadeia de conexão do seu aplicativo após um failover geográfico, porque as conexões são automaticamente roteadas para a primária atual. Um failover geográfico alterna todos os bancos de dados secundários do grupo para a função principal. 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

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

Política de Ativação de Failover

Os grupos de ativação pós-falha suportam duas políticas de ativação pós-falha:

• Gerido pelo cliente (recomendado) - Os clientes podem executar um failover de um grupo quando perceberem uma interrupção inesperada afetando 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 o cliente gerenciado é manual.
• Gerido 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 gerida pela Microsoft. O failover gerido pela Microsoft não será iniciado para grupos de failover individuais ou um subconjunto de grupos de failover numa 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, como resume a tabela a seguir:

Gerenciado pelo cliente

Em raras ocasiões, a disponibilidade interna ou alta disponibilidade não é suficiente para atenuar uma interrupção e seus bancos de dados em um grupo de failover podem estar indisponíveis por um período que não é aceitável para o contrato de nível de serviço (SLA) dos aplicativos que usam 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 datacenter, na zona de disponibilidade ou no nível 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 como 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.

Gerido 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:

• Datacenter, zona de disponibilidade ou interrupção no 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 e a mitigação da interrupção dependem de 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.

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

• Você deseja delegar a responsabilidade de recuperação de desastres ao serviço SQL do Azure.
• O aplicativo é tolerante a que seu banco de dados fique indisponível por pelo menos uma hora ou mais.
• É aceitável acionar failovers forçados algum tempo após o período de carência expirar, 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 da configuração de redundância de zona ou do 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 gerenciada 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 têm a mesma camada de serviço, camada de computação (provisionada ou sem servidor) ou tamanho de computação (DTUs ou vCores). Se o objetivo de nível de serviço (SLO) de todos os bancos de dados em um grupo de failover não corresponder, a política de failover será eventualmente atualizada do serviço SQL do Microsoft Managed para o Customer Managed by Azure.

Quando um failover é acionado pela Microsoft, uma entrada para o nome da operação Failover do 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 capacidades

• Grupo de failover (FOG)

  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 todos ou alguns bancos de dados primários fiquem indisponíveis devido a uma interrupção na região primária.

  Importante

  O nome do grupo de ativação pós-falha tem de ser globalmente exclusivo no domínio .database.windows.net.

• Servidores

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

• Principal

  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 que o principal.

• Failover (sem perda de dados)

  O failover executa a sincronização completa de dados entre bancos de dados primários e secundários antes que o secundário alterne para a função principal. Isso garante que não haja perda de dados. O failover só é possível quando o primário está acessível. O failover é usado nos seguintes cenários:

  • Execute exercícios de recuperação de desastres (DR) na produção quando a perda de dados não for aceitável
  • Realocar a carga de trabalho para uma região diferente
  • Retornar a carga de trabalho para a região primária após a interrupção ter sido atenuada (failback)

• Failover forçado (perda potencial de dados)

  O failover forçado alterna imediatamente o secundário para a função principal sem esperar que as alterações recentes se propaguem a partir da principal. Esta operação pode resultar em perda potencial de dados. O failover forçado é usado como um método de recuperação durante interrupções quando o principal não está acessível. Quando a interrupção for atenuada, o primário antigo se reconectará automaticamente e se tornará um novo secundário. Um failover pode ser executado para 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 gerenciadas 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 GracePeriodWithDataLossHourso , você pode controlar quanto tempo o serviço SQL do Azure aguarda antes de iniciar um failover forçado, o que pode resultar em perda de dados.

• Adicionando bancos de dados únicos ao grupo de failover

  Você pode colocar vários bancos de dados únicos no mesmo servidor lógico no mesmo grupo de failover. Se você adicionar um único banco de dados ao grupo de failover, ele criará automaticamente um banco de dados secundário usando a mesma edição e tamanho de computação no servidor secundário especificado quando o grupo de failover foi criado. Se você adicionar um banco de dados que já tenha um banco de dados secundário no servidor secundário, esse link de replicação geográfica será 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

  • Verifique se o servidor lógico secundário não tem 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 na memória, o banco de dados primário e o banco de dados de réplica geográfica secundário deverão ter camadas de serviço correspondentes, pois os objetos OLTP na memória residem na memória. Uma camada de serviço mais baixa no banco de dados de réplica geográfica pode resultar em problemas de falta de memória. Se isso ocorrer, a réplica geográfica pode falhar ao recuperar o banco de dados, causando indisponibilidade do banco de dados secundário junto com objetos OLTP na memória no geosecundário. Isso, por sua vez, pode fazer com que os failovers também não sejam bem-sucedidos. Para evitar isso, verifique se a camada de serviço do banco de dados geosecundário corresponde à do banco de dados primário. As atualizações da camada de serviço podem ser operações de tamanho de dados e podem demorar um pouco para serem concluídas.

• Adicionando bancos de dados no pool elástico ao grupo de failover

  Você pode 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 secundário será criado automaticamente no pool elástico com o mesmo nome (pool secundário). Você deve garantir que o servidor secundário contenha um pool elástico com o mesmo nome exato 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á tenha um banco de dados secundário no pool secundário, esse link de replicação geográfica será 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.

• Serviço de escuta de leitura/escrita do grupo de ativação pós-falha

  Um registro DNS CNAME que aponta para o primário atual. Ele é criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho de leitura-gravação se reconecte de forma transparente ao primário quando o principal for 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. Após o failover, o registro DNS é atualizado automaticamente para redirecionar o ouvinte para o novo primário.

• Serviço de escuta apenas de leitura do grupo de ativação pós-falha

  Um registro DNS CNAME que aponta para o 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 forma transparente ao secundário quando o secundário for 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 se conectar até que o secundário seja recuperado. Se você não puder tolerar o tempo de inatividade para as sessões somente leitura e puder usar o primário para tráfego somente leitura e leitura-gravação às custas da potencial degradação do desempenho do primário, você poderá habilitar o failover para o ouvinte somente leitura configurando a AllowReadOnlyFailoverToPrimary propriedade. Nesse caso, o tráfego somente leitura é automaticamente redirecionado para o primário se o secundário não estiver disponível.

  Nota

  A AllowReadOnlyFailoverToPrimary propriedade só terá efeito se a política de failover gerenciada pela Microsoft estiver habilitada e um failover forçado tiver sido acionado. Nesse caso, se a propriedade estiver definida como True, o novo primário servirá 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 para controlar o escopo de failovers geográficos. Cada grupo falha de forma independente. Se seu aplicativo locatário por banco de dados for implantado em várias regiões e usar pools elásticos, você poderá usar esse recurso para misturar bancos de dados primários e secundários em cada pool. Dessa forma, você poderá reduzir o impacto de uma interrupção para apenas alguns bancos de dados de locatário.

Arquitetura de 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 deve ser configurado no servidor primário, que o conecta ao servidor secundário em uma região diferente do Azure. O grupo de failover pode incluir todos ou alguns 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 em um grupo de failover:

Ao projetar um serviço com a continuidade de negócios em mente, siga as diretrizes gerais e as práticas recomendadas descritas neste artigo. Ao configurar um grupo de failover, certifique-se de que a autenticação e o acesso à rede no secundário estejam configurados para funcionar corretamente após o failover geográfico, quando o geosecundário se tornar o novo primário. Para obter detalhes, consulte Segurança do Banco de dados SQL após a recuperação de desastres. Para obter mais informações, consulte Projetando soluções de nuvem para recuperação de desastres.

Utilizar 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, o servidor primário é atualizado primeiro e, às vezes, é atualizado em segundo.

Se você tiver grupos de replicação geográfica ou 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ários e secundários. Por exemplo, você pode selecionar a janela de manutenção de dia da semana para seu banco de dados secundário e a janela de manutenção de fim de semana para seu banco de dados primário.

Semeadura inicial

Ao adicionar bancos de dados ou pools elásticos a um grupo de failover, há uma fase inicial de propagação antes do início da replicação de dados. A fase inicial de semeadura é a operação mais longa e mais cara. Quando a propagação inicial é concluída, os dados são sincronizados e, em seguida, apenas as alterações de dados subsequentes são replicadas. O tempo necessário para a conclusão da propagação inicial depende do tamanho dos dados, do número de bancos de dados replicados, da carga nos bancos de dados primários e da velocidade do link de rede entre o banco de dados primário e secundário. Em circunstâncias normais, a velocidade de propagação possível é de até 500 GB por hora para o Banco de dados SQL. A semeadura é realizada para todos os bancos de dados em paralelo.

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

Um ou vários grupos de failover podem ser criados entre dois servidores em regiões diferentes (servidores primários e secundários). Cada grupo pode incluir um ou vários bancos de dados que são recuperados como uma unidade, caso todos ou alguns bancos de dados primários fiquem indisponíveis devido a uma interrupção na região primária. A criação de um grupo de failover cria bancos de dados geosecundários com o mesmo objetivo de serviço do principal. Se você adicionar uma relação de replicação geográfica existente a um grupo de failover, verifique se o geosecundário está configurado com a mesma camada de serviço e tamanho de computação que o principal.

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

Para cargas de trabalho de leitura-escrita, utilize <fog-name>.database.windows.net como o nome do servidor na cadeia de ligaçã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 as conexões do cliente sejam redirecionadas para o novo primário somente depois que o cache DNS do cliente for atualizado. O tempo de vida (TTL) do registro DNS do ouvinte 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, poderá executá-las no geosecundário. Para cargas de trabalho só de leitura, utilize <fog-name>.secondary.database.windows.net como o nome do servidor na cadeia de ligação. As conexões são direcionadas automaticamente para o geo-secundário. Também é recomendável que você indique a intenção de leitura na cadeia de conexão usando ApplicationIntent=ReadOnly.

Nas camadas de serviço Premium, Business Critical e Hyperscale, o Banco de dados SQL oferece suporte ao uso de réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura, usando o ApplicationIntent=ReadOnly parâmetro na cadeia de conexão. Depois de configurar um geosecundário, você pode usar esse recurso para se conectar a uma réplica somente leitura no local principal ou no local geosecundário:

Para se conectar a uma réplica somente leitura no local secundário, use ApplicationIntent=ReadOnly e <fog-name>.secondary.database.windows.net.

Potencial degradação do desempenho após ativação pós-falha

Uma aplicação típica do Azure usa vários serviços do Azure e consiste em vários componentes. A ativação pós-falha de um grupo é acionada com base apenas no estado da Base de Dados SQL do Azure. Outros serviços do Azure na região primária podem não ser afetados pela interrupção e os respetivos componentes ainda podem estar disponíveis nessa região. Quando as bases de dados primárias alternam para a região secundária (DR), a latência entre os componentes dependentes pode aumentar. Para evitar o impacto da latência mais alta no desempenho da aplicação, garanta a redundância de todos os componentes da aplicação na região de DR, siga estas diretrizes de segurança de rede e orquestre a ativação pós-falha geográfica de componentes relevantes da aplicação junto com a base de dados.

Perda potencial de dados após ativação pós-falha forçada

Se ocorrer uma interrupção na região primária, as transações recentes podem não ter sido replicadas para o secundário geográfico e pode haver perda de dados se uma ativação pós-falha forçada for executada.

Reativação pós-falha

Quando os grupos de failover são configurados com uma política de failover gerenciada pela Microsoft, o failover forçado para o servidor geosecundário é iniciado durante um cenário de desastre de acordo com o período de cortesia definido. O failback para o primário antigo deve ser iniciado manualmente.

Permissões e limitações

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

Faça a gestão de grupos de ativação pós-falha programaticamente

Os grupos de ativação pós-falha também podem ser geridos programaticamente utilizando o Azure PowerShell, a CLI do Azure e a API REST. Para obter mais informações, consulte Configurar grupo de ativação pós-falha.

Conteúdos relacionados

• Para obter scripts de exemplo, consulte:
  • Usar o PowerShell para configurar a replicação geográfica ativa para o Banco de Dados SQL do Azure
  • Usar o PowerShell para configurar a replicação geográfica ativa para um banco de dados em pool no Banco de Dados SQL do Azure
  • Usar o PowerShell para adicionar um Banco de Dados SQL do Azure a um grupo de failover
• Para obter uma visão geral e cenários de continuidade de negócios, consulte Visão geral de continuidade de negócios
• Para saber mais sobre backups automatizados do Banco de Dados SQL do Azure, consulte Backups automatizados do Banco de Dados SQL.
• Para saber mais sobre como usar backups automatizados para recuperação, consulte Restaurar um banco de dados a partir dos backups iniciados pelo serviço.
• Para saber mais sobre os requisitos de autenticação para um novo servidor primário e banco de dados, consulte Segurança do Banco de dados SQL após recuperação de desastres.