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 Visão geral Grupos de failover & práticas recomendadas - Instância Gerenciada SQL do Azure.

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 failover geográfico, consulte visão geral dode continuidade de negócios .

Redirecionamento de ponto final

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, 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 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.
  • 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, como resume a tabela a seguir:

Política de failover 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 de incorporada ou a alta disponibilidade de não são suficientes para atenuar uma falha, e os seus bancos de dados num grupo de transição automática podem estar indisponíveis por um período que não é aceitável para o contrato de nível de serviço (SLA) das aplicações que utilizam 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 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 têm a política de failover definida como gerenciada 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 gerido 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 forçar failovers de bases 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 tornar a aplicação indisponível.
  • É 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 transferência de falhas e quaisquer relações de replicação geográfica têm a mesma camada de serviço e camada de computação (provisionada ou sem servidor) com o mesmo 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 para 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 ter sido atenuada (retorno)

  • 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 restabelecimento, retornando 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 indisponibilidade do banco de dados secundário junto com objetos OLTP na memória no geosecundário. Isso, por sua vez, pode levar a 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 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 em um servidor, o registro CNAME DNS para a URL do ouvinte é 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 listener é 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 conseguires tolerar interrupções para as sessões em modo de leitura apenas e puderes utilizar o servidor primário tanto para tráfego de leitura como de leitura e escrita, em detrimento da possível degradação de desempenho do primário, poderás ativar o failover para o escuta 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 gravação quanto as sessões de leitura apenas.

  • 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 a sua aplicação de locatário por base de dados estiver implementada em várias regiões e utilizar conjuntos elásticos, pode usar esta capacidade para combinar bases de dados primárias e secundárias em cada conjunto. 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 ultrapassagem configurados para bancos de dados que não se alinham com o emparelhamento de regiões do Azure, utilize agendamentos de janelas de manutenção diferentes para os seus bancos de dados primários e secundários. 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 failover para alternar entre 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 desempenho que o 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-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. 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 listener só de leitura (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 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 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 bancos de dados podem encontrar problemas, incluindo failovers geográficos planeados mais demorados e desempenho degradado. Esses problemas são mais prováveis de ocorrer para workloads intensivas de escrita quando as réplicas geográficas estão amplamente separadas por distâncias geográficas ou quando múltiplas 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 ao estado primário

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