Visão geral dos grupos de failover e melhores práticas (Azure SQL Database)

Aplica-se a: Azure SQL Database

O recurso de grupos de failover permite gerir a replicação e o failover de algumas ou todas as bases de dados num servidor lógico para um servidor lógico noutra região. Este artigo apresenta uma visão geral da funcionalidade do grupo de failover com boas práticas e recomendações para a sua utilização com o Azure SQL Database.

Para começar a usar a funcionalidade, consulte Configure um grupo de failover para Azure SQL Database.

Para saber mais sobre recuperação de desastres do Azure SQL Database, veja este vídeo:

Visão geral

A funcionalidade de grupos de failover permite gerir a replicação e failover de bases 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, projetada para simplificar a implantação e o gerenciamento de bancos de dados replicados geograficamente em escala.

Para RPO e RTO com geo-failover, consulte a visão geral de continuidade de negócios.

Redirecionamento de terminal

Os grupos de failover fornecem pontos de extremidade de escuta somente leitura e leitura que permanecem inalterados durante failovers geográficos. Não necessita mudar a cadeia de conexão da sua aplicação após um geo-failover, porque as ligações são automaticamente encaminhadas para o primário atual. Um failover geográfico altera todos os bancos de dados secundários do grupo para o papel principal. Após a conclusão do failover geográfico, o registo DNS é atualizado automaticamente para redirecionar as endpoints para a nova região.

Descarregar cargas de trabalho somente leitura

Para reduzir o tráfego para os seus bancos de dados primários, também pode usar os bancos de dados secundários em um grupo de recuperação para aliviar as cargas de trabalho de leitura. Utilize o ouvinte de leitura exclusiva para direcionar o tráfego de leitura exclusiva para um banco de dados secundário.

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, deves tomar as medidas adequadas para garantir que o teu serviço funcione durante o failover dos serviços dos quais depende.

Política de tolerância a falhas

Os grupos de failover suportam duas políticas de failover:

• Gerido pelo cliente (recomendado) - Os clientes podem realizar um failover de um grupo quando perceberem uma interrupção inesperada que afete um ou mais bancos de dados no grupo de failover. Ao utilizar ferramentas de linha de comandos como PowerShell, o Azure CLI ou a API Rest, o valor da política de failover para a gestão do 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 utilizar ferramentas de linha de comandos como PowerShell, o Azure CLI ou a API Rest, o valor da política de failover para o Microsoft-managed é 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 recomendável, 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 gerida pela Microsoft, a responsabilidade pela recuperação de desastres é delegada ao serviço Azure SQL. Para que o serviço Azure SQL inicie um failover forçado, as seguintes condições devem ser cumpridas:

• A 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 estas condições são cumpridas, o serviço Azure SQL inicia failovers forçados para todos os grupos de failover na região que tenham a política de failover definida para Microsoft Managed.

Defina a política de failover como gerida pela Microsoft apenas quando:

• Quer delegar a responsabilidade de recuperação de desastres ao serviço Azure SQL.
• 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 realizar failovers forçados de bases de dados no grupo de failover sem considerar a dependência da aplicação em relação a outros serviços ou componentes do Azure usados pela aplicação, o que pode causar degradação do desempenho ou indisponibilidade da aplicação.
• É 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.
• As réplicas primária e secundária no grupo de failover têm a mesma camada de serviço, camada de computação e tamanho de computação.

Quando a Microsoft desencadeia um failover, uma entrada para o nome da operação Failover Azure SQL failover group é adicionada ao registo de atividade Azure Monitor. A entrada inclui o nome do grupo de failover sob Recurso, e Evento iniciado por exibe um único hífen (-) para indicar que o failover foi iniciado pela Microsoft. Esta informação também pode ser encontrada na página Activity log do novo servidor ou instância principal no portal Azure.

Terminologia e capacidades

• Grupo de tolerância a falhas (FOG)

  Um grupo de failover é um grupo nomeado de bases de dados gerido por um único servidor lógico em Azure que pode realizar um failover em unidade para outra região do Azure caso todas ou algumas bases de dados primárias fiquem indisponíveis devido a uma falha na região primária.

  Importante

  O nome do grupo de failover deve ser globalmente único dentro do domínio .database.windows.net.

• Servers

  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.

• Primária

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

• Secundária

  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 de Azure que o primário.

• 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 servidor principal está disponí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
  • Restituir a carga de trabalho à região primária após a interrupção ser resolvida (retiro)

• 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 sistema primário 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. Uma comutação por falha pode ser executada para retorno ao estado original, devolvendo as réplicas às suas funções originais de primárias e secundárias.

• 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 GracePeriodWithDataLossHours, pode controlar quanto tempo o serviço de Azure SQL espera 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 a indisponibilidade do banco de dados secundário, bem como dos objetos OLTP na memória no geo-secundário. Isso, por sua vez, pode fazer com que as mudanças para outro sistema também não sejam bem-sucedidas. 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 que dependem do tamanho dos dados e podem demorar um pouco a concluir.

• Adicionar 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.

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

  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 automática ao servidor primário quando este for alterado após o failover. Quando o grupo de failover é criado num servidor, o registo CNAME DNS para a URL de escuta é formado como <fog-name>.database.windows.net. Após o failover, o registo DNS é atualizado automaticamente para redirecionar o listener para o novo primário.

• Ouvinte de leitura só do grupo de reserva

  Um registro DNS CNAME que aponta para o secundário atual. É criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho SQL de leitura única se conecte de maneira transparente ao secundário quando este é alterado após o failover. Quando o grupo de failover é criado num servidor, o registo CNAME DNS para a URL de escuta é formado como <fog-name>.secondary.database.windows.net. Por padrão, a comutação do ouvinte de modo apenas leitura é desabilitada, pois garante que o desempenho do primário não seja afetado quando o secundário estiver desconectado. No entanto, isso também significa que as sessões somente leitura não poderão ligar até que o servidor secundário seja recuperado.

• Vários grupos de failover

  Você pode configurar vários grupos de failover para o mesmo par de servidores para controlar o escopo dos geo-failovers. Cada grupo falha de forma independente. Se a sua aplicação com um locatário por base de dados estiver implementada em várias regiões e utilizar pools elásticos, pode usar esta capacidade para combinar bases de dados primárias e secundárias 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 contingência

Um grupo de failover no Azure SQL Database pode incluir uma ou várias bases de dados, normalmente usadas pela mesma aplicação. Um grupo de failover deve ser configurado no servidor principal, que o liga ao servidor secundário numa região Azure diferente. 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 mais detalhes, veja Configurar e gerir a segurança do Azure SQL Database para restauração geográfica ou de failover. Para mais informações, consulte Desenhando serviços globalmente disponíveis usando o Banco de Dados SQL do Azure e Geo-restauração para o Banco de Dados SQL do Azure.

Usar regiões emparelhadas

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

Seguindo práticas de implementação segura, o Azure SQL Database 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, outras vezes, é atualizado depois.

Se tiver geo-replication ou failover groups configurados para bases de dados que não estejam alinhadas com o emparelhamento de regiões Azure, use diferentes agendas de janelas de manutenção para as suas bases de dados primárias e secundárias. Por exemplo, você pode selecionar janela de manutenção de de dias úteis para seu banco de dados secundário e janela de manutenção de 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.

Número de bancos de dados no grupo de failover

O número de bases de dados num grupo de comutação automática afeta diretamente a duração das operações de comutação automática e comutação forçada.

• Durante um failover (também conhecido como failover planejado), garantimos que todos os bancos de dados primários estejam totalmente sincronizados com seus secundários e atinjam um estado pronto. Para evitar sobrecarregar o plano 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 o número de bases de dados no grupo de *failover* num número mais reduzido.

Usar vários grupos de contingência para efetuar o failover de múltiplas bases 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 bases de dados geo-secundárias com o mesmo objetivo de serviço que o principal. Se adicionar uma relação de replicação geográfica existente a um grupo de tolerância a falhas, verifique se o geosecundário está configurado com a mesma camada de serviço e capacidade de processamento que o primário.

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

Para cargas de trabalho de leitura-escrita, use <fog-name>.database.windows.net como nome do servidor na connection string. As conexões são direcionadas automaticamente para o servidor principal. Este nome permanece o mesmo após o failover. Tome nota de que o failover envolve a atualização do registo DNS para que as conexões do cliente sejam redirecionadas para o novo servidor principal 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.

Utilizar o ouvinte de leitura apenas (secundário)

Se tiver cargas de trabalho somente de leitura, logicamente isoladas e tolerantes à latência de dados, pode executá-las na geo-secundária. Para sessões apenas de leitura, use <fog-name>.secondary.database.windows.net como nome do servidor na connection string. As conexões são direcionadas automaticamente para a segunda localização geográfica. Também é recomendado indicar a intenção de leitura no connection string usando ApplicationIntent=ReadOnly.

Nos níveis de serviço Premium, Business Critical e Hyperscale, o SQL Database suporta o uso de réplicas apenas leitura para descarregar cargas de trabalho de consulta apenas de leitura, usando o parâmetro ApplicationIntent=ReadOnly na connection string. 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 de leitura única na localização secundária, use ApplicationIntent=ReadOnly e <fog-name>.secondary.database.windows.net.

Potencial degradação do desempenho após failover

Uma aplicação típica do Azure utiliza múltiplos serviços Azure e consiste em múltiplos componentes. O failover de um grupo é desencadeado apenas com base no estado do Azure SQL Database. Outros serviços do Azure na região primária podem não ser afetados pela interrupção e os seus componentes podem continuar disponíveis nessa região. Quando os bancos de dados primários 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 do aplicativo, garanta a redundância de todos os componentes do aplicativo na região de DR, siga estas diretrizes de segurança de redee orquestre o failover geográfico dos componentes relevantes do aplicativo junto com o banco de dados.

Perda potencial de dados após failover forçado

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

Retorno apó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 retorno ao primário antigo deve ser iniciado manualmente.

Múltiplas secundárias

Cada grupo de failover pode suportar múltiplos servidores secundários na mesma região ou em diferentes regiões. Esta configuração oferece opções adicionais para recuperação de desastres e permite que cargas de trabalho apenas de leitura sejam distribuídas por múltiplas regiões. Ao configurar múltiplos secundários, considere o seguinte:

• Podem ser especificados até quatro servidores secundários para cada grupo de failover.
• Cada servidor secundário pode estar na mesma região ou numa região diferente do servidor principal e entre si.
• Cada servidor secundário mantém a sua própria ligação de geo-replicação com o servidor principal.
• O failover pode ser iniciado para qualquer um dos servidores secundários.
• O ouvinte só de leitura pode ser configurado apenas para um dos servidores secundários e deve ser para um secundário numa região diferente para servir corretamente cargas de trabalho apenas de leitura.
• O encadeamento (criação de geo-réplicas em cadeia) não é suportado nesta configuração.

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.

Gerencie grupos de failover programaticamente

Os grupos de failover também podem ser geridos programaticamente usando Azure PowerShell, Azure CLI e REST API. Para mais informações, consulte Configure um grupo de failover para Azure SQL Database.

Habilitar alta disponibilidade (redundância de zona)

A disponibilidade por meio de redundância melhora ainda mais a resiliência, protegendo contra interrupções de uma zona de disponibilidade dentro de uma região.

Ao criar um grupo de failover que inclua um ou mais bancos de dados, não há opção para habilitar a alta disponibilidade para os bancos de dados secundários, independentemente das configurações de alta disponibilidade dos bancos de dados primários.

Redundância de zona com bancos de dados que não sejam de hiperescala

Os bancos de dados secundários criados por meio do grupo de failover não terão alta disponibilidade habilitada por padrão. Depois de o grupo de failover ser criado, ative a alta disponibilidade nos bancos de dados contidos no grupo. Esse comportamento também se aplica se você criar o Active Geo-Replication primeiro e, em seguida, opcionalmente, adicionar os bancos de dados a um grupo de failover.

Redundância de zona com Hyperscale

Os bancos de dados secundários criados por meio do grupo de failover herdarão as configurações de alta disponibilidade de seus respetivos bancos de dados primários. Portanto, se o banco de dados primário tiver alta disponibilidade habilitada, o banco de dados secundário também o terá habilitado. Por outro lado, se o banco de dados primário não tiver alta disponibilidade habilitada, o banco de dados secundário também não o terá habilitado.

Suporte regional para zonas de disponibilidade

Em um cenário em que a alta disponibilidade está habilitada no banco de dados primário e o banco de dados secundário que está sendo adicionado está em uma região que ainda não oferece suporte a zonas de disponibilidade, o fluxo de trabalho falhará com uma mensagem de erro com o código 45122: "Criar ou atualizar a operação do Grupo de Failover concluída com êxito; no entanto, alguns dos bancos de dados não puderam ser adicionados ou removidos do Grupo de Failover. O provisionamento de banco de dados/pool redundante de zona não é suportado para a sua solicitação atual. Para contornar este problema, use a replicação geográfica ativa , em que você activa ou desactiva a alta disponibilidade ao criar o banco de dados secundário. Opcionalmente, você pode adicionar esses bancos de dados a um grupo de failover.

Conteúdo relacionado

• Para obter scripts de exemplo, consulte:
  • Utilize o PowerShell para configurar a geo-replicação ativa para Azure SQL Database
  • Utilize o PowerShell para configurar a geo-replicação ativa para uma base de dados agrupada em Azure SQL Database
  • Usa o PowerShell para adicionar um Azure SQL Database 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 os backups automatizados do Azure SQL Database, veja backups automatizados do SQL Database.
• 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 a recuperação de desastres.
• Para resolver problemas de geo-replicação, veja Troubleshoot geo-replication redo lag.