Partilhar via

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

  • Artigo

Aplica-se a: do Banco de Dados SQL do Azure

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 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 a funcionalidade, reveja Configurar um grupo de failover para a Base de Dados SQL do Azure.

Observação

Este artigo aborda grupos de failover para o Banco de Dados SQL do Azure. Para a Instância Gerenciada SQL do Azure, consulte a Visão Geral dos Grupos de Failover & Práticas Recomendadas - Azure SQL Managed Instance.

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

Visã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, 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 finais de leitura/escrita e somente leitura que permanecem inalterados durante transferências de serviço geográficas. 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 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 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 gerido pelo cliente é 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 a sua política de failover configurada para serem geridos 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 gerida 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:

Política de tolerância a falhas Escopo de contingência Caso de uso Perda potencial de dados
Gerenciado pelo cliente
(Recomendado)		 Grupo(s) de tolerância a falhas Um ou mais bancos de dados em um grupo de failover são afetados por uma interrupção e ficam indisponíveis. 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 acionar 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 incorporada ou a alta disponibilidade não são suficientes para atenuar uma falha, e as suas bases de dados num grupo de failover podem estar indisponíveis por um período inaceitável para o contrato de nível de serviço (SLA) das aplicações que utilizam as bases 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 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 Azure SQL inicia interrupções forçadas para todos os grupos de failover na região que têm a política de tolerância a falhas configurada como gerida 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 que tenham a política de failover definida como gerida pela Microsoft. Não pode ser iniciado para um grupo de failover individual. Se você precisar da capacidade de fazer failover seletivamente em seu grupo de failover, use a política de failover gerenciada pelo cliente.

Defina a política de failover como gerida pela Microsoft apenas 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, visto que o tempo necessário 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 uma base de dados no grupo de failover sem considerar a dependência da aplicação de outros serviços ou componentes do Azure que ela utiliza, o que pode causar degradação de desempenho ou resultar em 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.
  • Todos os banco(s) de dados primário(s) e secundário(s) no grupo de failover e quaisquer relações de replicação geográfica têm a mesma camada de serviço, camada de computação (provisionada ou sem servidor) e tamanho de computação (DTUs ou vCores). Se o SLO (objetivo de nível de serviço) de todos os bancos de dados não corresponderem, a política de failover será atualizada, eventualmente, do serviço Microsoft Managed para gestão pelo cliente usando o Azure SQL.

Quando um failover é acionado pela Microsoft, uma entrada com o nome da operação Failover do grupo de failover do Azure SQL é adicionada ao log de atividades do 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. 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 Recuperação (FOG)

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

    Importante

    O nome do grupo de failover deve ser globalmente exclusivo dentro do 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.

  • 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 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 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, 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 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 somente leitura do grupo de failover

    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 do ouvinte é 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. Se não conseguir tolerar interrupções para as sessões em modo de leitura apenas e puder utilizar o servidor primário tanto para tráfego de leitura apenas como para leitura e escrita, em detrimento da possível degradação de desempenho do primário, poderá ativar o failover para o listener de leitura apenas configurando a propriedade AllowReadOnlyFailoverToPrimary. Nesse caso, o tráfego de leitura apenas é redirecionado automaticamente para o servidor primário se o servidor secundário não estiver disponível.

    Observação

    A propriedade AllowReadOnlyFailoverToPrimary 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á tanto as sessões de leitura e escrita quanto as sessões apenas de leitura.

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

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 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 Configurar e gerir a segurança do Banco de Dados SQL do Azure para restauração geográfica ou recuperação automática. Para obter mais informações, consulte Conceção de serviços globalmente disponíveis usando a Base de Dados SQL do Azure e Restauração geográfica para a Base 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 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, outras vezes, é atualizado depois.

Se tiver replicação geográfica ou grupos de failover configurados para bases de dados que não se alinham com o pareamento de regiões da Azure, utilize agendamentos de janelas de manutenção diferentes para as suas bases de dados primária e secundária. 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-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 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 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 segunda localização geográfica. 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 parâmetro ApplicationIntent=ReadOnly 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 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 principal podem não ser afetados pela interrupção e seus componentes ainda podem estar 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.

Importante

Pools elásticos com 800 ou menos DTUs ou 8 ou menos vCores e mais de 250 bases de dados podem encontrar problemas, tais como transições geográficas planeadas mais demoradas e desempenho reduzido. Esses problemas são mais prováveis de ocorrer para tarefas intensivas de escrita quando as geo-réplicas estão geograficamente muito distantes ou quando várias réplicas geográficas secundárias são usadas para cada base de dados. Um sintoma desses problemas é um aumento no atraso na replicação geográfica ao longo do tempo, potencialmente levando a uma perda de dados mais extensa em uma interrupção. Esse atraso pode ser monitorado usando sys.dm_geo_replication_link_status. Se esses problemas ocorrerem, a mitigação inclui o dimensionamento do pool para ter mais DTUs ou vCores, ou a redução do número de bancos de dados replicados geograficamente no pool.

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.

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 gerenciados programaticamente usando o Azure PowerShell, a CLI do Azure e a API REST. Para obter mais informações, consulte Configurar um grupo de failover para a Base de Dados SQL do Azure.

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