Compartilhar via

Melhores práticas de visão geral dos grupos de failover (Instância Gerenciada de SQL do Azure)

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo fornece uma visão geral do recurso de grupo de failover com as melhores práticas e recomendações a serem usadas com a Instância Gerenciada de SQL do Azure. O recurso de grupos de failover permite que você gerencie a replicação e o failover de todos os bancos de dados de usuário em uma instância gerenciada de SQL para outra região do Azure.

Para começar, examine Configurar um grupo de failover para a Instância Gerenciada de SQL do Azure.

Visão geral

O recurso de grupos de failover permite que você gerencie a replicação e o failover de bancos de dados de usuário de uma instância gerenciada de SQL para outra instância gerenciada de SQL em uma região diferente do Azure. Os grupos de failover foram projetados para simplificar a implantação e o gerenciamento de bancos de dados replicados geograficamente em escala.

Para obter mais informações, confira Alta disponibilidade da Instância Gerenciada de SQL do Azure. Para os RPO e RTO do failover geográfico, confira Visão geral da continuidade dos negócios.

Redirecionamento de ponto de extremidade

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

Descarregar cargas de trabalho somente leitura

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

Recuperando um aplicativo

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

Política de failover

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

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

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

Política de failover Escopo de failover Caso de uso Possível perda de dados
Gerenciado pelo cliente
(Recomendado)		 Grupos de failover 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 uma região causa indisponibilidade de bancos de dados e a equipe de serviço sql do Microsoft Azure decide disparar um failover forçado.
Use essa opção somente quando quiser delegar a responsabilidade de recuperação de desastres à Microsoft e o aplicativo for tolerante ao RTO (tempo de inatividade) de pelo menos uma hora ou mais.
O failover gerenciado pela Microsoft só pode ser executado em circunstâncias extremas. Uma política de failover gerenciada pelo cliente é altamente recomendada.		 Sim

Gerenciado pelo cliente

Em raras ocasiões, a disponibilidade interna ou a alta disponibilidade não são suficientes para atenuar uma interrupção, e seus bancos de dados em um grupo de failover podem ficar indisponíveis por uma duração que não seja aceitável para o SLA (contrato de nível de serviço) 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 nível do datacenter, da zona de disponibilidade ou da região. Em qualquer um desses casos, para restaurar a continuidade dos negócios, você pode iniciar um failover forçado.

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

Gerenciado pela Microsoft

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

  • 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 componente de hardware e muitos bancos de dados na região são afetados.
  • O período de carência expirou. Como a verificação da escala da interrupção e sua mitigação envolvem ações humanas, o período de carência não pode ser definido abaixo de uma hora.

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

Importante

Use a política de failover gerenciada pelo cliente para testar e implementar seu plano de recuperação de desastre. Não confie no failover gerenciado pela Microsoft, que só pode ser executado pela Microsoft em circunstâncias extremas. Um failover gerenciado pela Microsoft é iniciado para todos os grupos de failover na região que têm sua política de failover definida como gerenciada pela Microsoft. Ele não pode ser iniciado para grupos de failover individuais. Se você precisar fazer failover seletivo do grupo de failover, use a política de failover gerenciada pelo cliente.

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

  • Você deseja delegar a responsabilidade de recuperação de desastres ao serviço SQL do Azure.
  • O aplicativo é tolerante ao seu banco de dados ficar indisponível por pelo menos uma hora ou mais.
  • É aceitável disparar 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 de sua configuração de redundância de zona ou status de disponibilidade. Embora os bancos de dados configurados para redundância de zona sejam resilientes a falhas zonais e possam não ser afetados por uma interrupção, eles ainda serão submetidos a failover se fizerem parte de um grupo de failover com uma política de failover gerenciado pela Microsoft.
  • É aceitável ter failovers forçados de bancos de dados no grupo de failover sem levar em consideração a dependência do aplicativo de outros serviços ou componentes do Azure usados pelo aplicativo, o que pode causar degradação do desempenho ou indisponibilidade do aplicativo.
  • É aceitável incorrer em uma quantidade desconhecida de perda de dados, pois o tempo exato do failover forçado não pode ser controlado e ignora o status de sincronização dos bancos de dados secundários.
  • As réplicas primárias e secundárias no grupo de failover têm a mesma camada de serviço, camada de computação e tamanho de computação.

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

Terminologia e recursos

  • FOG (grupo de failover)

    Caso a instância gerenciada de SQL principal se torne indisponível devido a uma interrupção na região primária, um grupo de failover permite que todos os bancos de dados de usuário façam o failover como uma unidade para outra região do Azure. Como os grupos de failover a Instância Gerenciada de SQL, contém todos os bancos de dados de usuário na instância, é possível configurar apenas um grupo de failover em uma instância.

    Importante

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

  • Primário

    A instância gerenciada de SQL que hospeda os bancos de dados primários no grupo de failover.

  • Secundário

    A instância gerenciada de SQL que hospeda os bancos de dados secundários no grupo de failover. O secundário não pode estar na mesma região do Azure do primário.

    Importante

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

  • Failover (sem perda de dados)

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

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

  • Failover forçado (potencial perda de dados)

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

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

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

  • Zona DNS

    Uma ID exclusiva que é gerada automaticamente quando um nova Instância Gerenciada de SQL é criada. Um certificado SAN (vários domínios) para essa instância é provisionado para autenticar as conexões de cliente com qualquer instância na mesma zona DNS. As duas instâncias de SQL gerenciadas no mesmo grupo de failover devem compartilhar a zona DNS.

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

    Um registro CNAME DNS que aponta para a primária atual. Ele é criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho de leitura/gravação se reconecte de modo transparente ao primário quando o primário é alterado após o failover. Quando o grupo de failover é criado em uma instância gerenciada de SQL, o registro CNAME DNS para a URL do listener é formado como <fog-name>.<zone_id>.database.windows.net.

  • Ouvinte de somente leitura do grupo de failover

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

    Observação

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

Arquitetura do grupo de failover

O grupo de failover deve ser configurado na instância primária e conectá-lo à instância secundária em uma região diferente do Azure. Todos os bancos de dados de usuário na instância primária são replicados para a instância secundária. Bancos de dados do sistema, como master e msdb, não são replicados.

O diagrama a seguir ilustra uma configuração típica de um aplicativo de nuvem com redundância geográfica usando uma instância gerenciada de SQL e um grupo de failover:

diagrama de um grupo de failover para uma Instância Gerenciada de SQL do Azure.

Se o aplicativo usar a Instância Gerenciada de SQL como a camada de dados, siga estas diretrizes gerais e as melhores práticas descritas neste artigo ao projetar para continuidade de negócios.

Criar a instância geográfica secundária

Para garantir a conectividade ininterrupta com a Instância Gerenciada de SQL primária após o failover, as instâncias primária e secundária devem estar na mesma zona DNS. Isso garante que o mesmo certificado de vários domínios (SAN) possa ser usado para autenticar as conexões do cliente com uma das duas instâncias no grupo de failover. Quando seu aplicativo estiver pronto para implantação em produção, crie uma Instância Gerenciada de SQL secundária em uma região diferente e verifique se ela compartilha a zona DNS com a Instância Gerenciada de SQL primária. Você pode fazer isso especificando um parâmetro opcional ao criar a instância. Se você estiver usando o PowerShell ou a API REST, o nome do parâmetro opcional será DNSZonePartner. O nome do campo opcional correspondente no portal do Azure é Primary Instância Gerenciada.

Importante

A primeira instância gerenciada de SQL criada na sub-rede determina a zona DNS para todas as instâncias subsequentes na mesma sub-rede. Isso significa que duas instâncias da mesma sub-rede não podem pertencer a zonas DNS diferentes.

Para obter mais informações sobre como criar a Instância Gerenciada de SQL secundária na mesma zona DNS que a instância primária, confira Configurar um grupo de failover para a Instância Gerenciada de SQL do Azure.

Usar regiões emparelhadas

Implante ambas as instâncias gerenciadas de SQL em regiões emparelhadas por motivos de desempenho. Grupos de failover de Instância Gerenciada de SQL em regiões emparelhadas têm melhor desempenho em comparação com regiões não emparelhadas.

A Instância Gerenciada de SQL do Azure segue uma prática de implantação segura em que as regiões emparelhadas do Azure geralmente não são implantadas ao mesmo tempo. No entanto, não é possível prever qual região é atualizada primeiro, portanto, a ordem da implantação não é garantida. Às vezes, sua instância primária é atualizada primeiro e, às vezes, a instância secundária é atualizada primeiro.

Em situações em que a Instância Gerenciada de SQL do Azure faz parte de um grupo de failover e as instâncias do grupo não estão em regiões emparelhadas do Azure, selecione diferentes agendamentos de janela de manutenção para seus bancos de dados primário e secundário. Por exemplo, selecione a janela de manutenção Dia da semana para o banco de dados geográfico secundário e a janela de manutenção Fim de semana para o banco de dados geográfico primário.

Habilitar e otimizar o fluxo de tráfego de replicação geográfica entre as instâncias

A conectividade entre as sub-redes de rede virtual que hospedam a instância primária e secundária deve ser estabelecida e mantida para o fluxo de tráfego de replicação geográfica ininterrupta. Há várias maneiras de fornecer conectividade entre as instâncias que você pode escolher com base em sua topologia e políticas de rede:

O emparelhamento de rede virtual (emparelhamento VNET) global é a maneira recomendada para estabelecer conectividade entre duas instâncias em um grupo de failover. Ele fornece uma conexão privada de baixa latência e alta largura de banda entre as redes virtuais emparelhadas usando a infraestrutura de backbone da Microsoft. A Internet pública, os gateways ou a criptografia adicional não é necessária na comunicação entre as redes virtuais emparelhadas.

Propagação inicial

Ao estabelecer um grupo de failover entre instâncias gerenciadas de SQL, há uma fase inicial de semeadura antes que a replicação de dados comece. A fase de propagação inicial é a parte da operação mais longa e custosa. Após a conclusão da propagação inicial, os dados são sincronizados e somente as alterações de dados subsequentes são replicadas. O tempo necessário para que a propagação inicial seja concluída depende do tamanho dos dados, do número de bancos de dados replicados, da intensidade da carga de trabalho nos bancos de dados primários e da velocidade do vínculo entre as redes virtuais que hospedam a instância primária e secundária, que depende principalmente da maneira como a conectividade é estabelecida. Em circunstâncias normais e quando a conectividade é estabelecida usando o emparelhamento de rede virtual global recomendado, a velocidade de propagação é de até 360 GB por hora para a Instância Gerenciada de SQL. A inicialização é executada para um lote de bancos de dados de usuário em paralelo, mas não necessariamente para todos os bancos de dados ao mesmo tempo. Vários lotes poderão ser necessários se houver muitos bancos de dados hospedados na instância.

Caso a velocidade do link entre as duas instâncias seja mais lenta do que o necessário, provavelmente o tempo de propagação será significativamente afetado. Você pode usar a velocidade de propagação declarada, o número de bancos de dados, o tamanho total dos dados e a velocidade do link para estimar quanto tempo a fase de propagação inicial leva antes do início da replicação de dados. Por exemplo, para um único banco de dados de 100 GB, a fase de propagação inicial levará cerca de 1,2 hora se o link for capaz de enviar por push 84 GB por hora e se não houver nenhum outro banco de dados em propagação. Se o link só puder transferir 10 GB por hora, a propagação de um banco de dados de 100 GB pode levar cerca de 10 horas. Se houver vários bancos de dados a serem replicados, a propagação será executada em paralelo. Quando combinada com uma velocidade de vínculo lenta, a fase de propagação inicial pode levar consideravelmente mais tempo, especialmente se a propagação paralela de dados de todos os bancos de dados exceder a largura de banda do link disponível.

Importante

A fase inicial de propagação pode levar dias com links de velocidade extremamente baixa ou congestionados. Nesse caso, a criação do grupo de failover pode acabar. A criação do grupo de failover é cancelada automaticamente após seis dias.

Gerenciar o failover geográfico para uma instância secundária geográfica

O grupo de failover gerencia o failover geográfico de todos os bancos de dados na instância gerenciada de SQL primária. Quando um grupo é criado, cada banco de dados na instância é automaticamente replicado geograficamente para a instância geo-secundária. Não é possível usar grupos de failover para iniciar um failover parcial de um subconjunto de bancos de dados.

Importante

Se um banco de dados for descartado na instância gerenciada de SQL primário, ele também será descartado automaticamente na instância gerenciada de SQL geo-secundária.

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

Para cargas de trabalho de leitura/gravação, use <fog-name>.zone_id.database.windows.net como o nome do servidor. As conexões são direcionadas automaticamente para o primário. Esse nome não é alterado após o failover. O failover geográfico envolve a atualização do registro DNS, para que novas conexões de clientes sejam roteadas para o novo servidor primário somente depois que o cache DNS do cliente for atualizado. Como a instância secundária compartilha a zona DNS com a primária, o aplicativo cliente poderá reconectar-se a ela usando o mesmo certificado de SAN do lado do cliente. As conexões de cliente existentes precisam ser encerradas e, em seguida, recriadas para serem roteadas para o novo primário. O monitor de leitura-gravação e o monitor somente leitura não podem ser acessados via o endpoint público da instância gerenciada SQL.

Usar o ouvinte somente leitura (MI secundário)

Se você tiver cargas de trabalho somente leitura logicamente isoladas que são tolerantes à latência de dados, é possível executa-las na área geográfica secundária. Para se conectar diretamente à área secundária geográfico, use <fog-name>.secondary.<zone_id>.database.windows.net como o nome do servidor.

Na camada Comercialmente Crítico, a Instância Gerenciada de SQL dá suporte ao uso de réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura usando o parâmetro ApplicationIntent=ReadOnly na cadeia de conexão. Ao configurar um secundário replicado geograficamente, você pode usar essa funcionalidade para se conectar a uma réplica somente leitura na localização do primário ou na localização com replicação geográfica:

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

O ouvinte de leitura-gravação e o ouvinte somente leitura não podem ser acessados por meio do ponto de extremidade público para a instância gerenciada de SQL.

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

Um aplicativo típico do Azure usa vários serviços do Azure e consiste em vários componentes. O failover geográfico do grupo de failover é acionado com base no estado dos componentes do SQL do Azure sozinhos. Uma interrupção pode não afetar outros serviços do Azure na região primária e seus componentes ainda podem estar disponíveis nessa região. Depois que os bancos de dados primários mudarem para a região secundária, a latência entre os componentes dependentes poderá aumentar. Verifique a redundância de todos os componentes do aplicativo na região secundária e faça failover dos componentes do aplicativo junto com o banco de dados para que a latência entre regiões mais alta não afete o desempenho de um aplicativo.

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

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

Atualização de DNS

A atualização do DNS do ouvinte de leitura-gravação ocorrerá imediatamente após o início do failover. Essa operação não resultará em perda de dados. No entanto, o processo de alternância de funções de banco de dados pode levar até cinco minutos em condições normais. Até que ele seja concluído, alguns bancos de dados na nova instância primária ainda serão somente leitura. Se um failover for iniciado usando o PowerShell, a operação para alternar a função de réplica primária será síncrona. Se ele for iniciado usando o portal do Azure, a interface do usuário indicará o status de conclusão. Se ele for iniciado usando a API REST, use o mecanismo de sondagem padrão do Azure Resource Manager para monitorar quanto à conclusão.

Importante

Quando a interrupção que causou o failover geográfico for atenuada use o failover manual planejado para mover o primário de volta para o local original.

Economize nos custos com uma réplica de DR sem licença

Você pode economizar nos custos de licença do SQL Server configurando sua instância gerenciada de SQL secundária para ser usada somente para recuperação de desastre (DR). Para configurar isso, consulte Configurar uma réplica em espera sem licença para a Instância Gerenciada de SQL do Azure.

Desde que a instância secundária não seja usada para cargas de trabalho de leitura, a Microsoft fornece um número gratuito de vCores para corresponder à instância primária. Você ainda é cobrado pela computação e pelo armazenamento usados pela instância secundária. Os grupos de failover dão suporte a apenas uma réplica, e a réplica deve ser uma réplica de leitura ou designada como uma réplica apenas para DR.

Habilitar cenários dependentes de objetos dos bancos de dados do sistema

Os bancos de dados de sistema não são replicados para a instância secundária em um grupo de failover. Para habilitar cenários que dependem de objetos dos bancos de dados do sistema, crie os mesmos objetos na instância secundária. Mantenha-os sincronizados com a instância primária.

Por exemplo, se você planeja usar os mesmos logins na instância secundária, crie-os com os mesmos SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Para saber mais, confira Replicação de logons e trabalhos de agente.

Sincronizar as propriedades da instância e as instâncias de políticas de retenção

As instâncias em um grupo de failover permanecem separadas dos recursos do Azure e nenhuma alteração feita na configuração da instância primária é replicada automaticamente para a instância secundária. Certifique-se de executar todas as alterações relevantes na instância primária e secundária. Por exemplo, se você alterar a redundância de armazenamento de backup ou a política de retenção de backup de longo prazo na instância primária, altere-a também na instância secundária.

Escalar instâncias

A configuração da instância primária e secundária deve ser a mesma. Isso inclui o tamanho da computação, o tamanho do armazenamento e a camada de serviço. Se você precisar alterar a configuração do grupo de failover, poderá fazer isso dimensionando cada instância para a mesma configuração adequadamente. Para saber mais, examine as instâncias de dimensionamento em um grupo de failover.

Evitar a perda de dados críticos

Devido à alta latência das redes de longa distância, a replicação geográfica usa um mecanismo de replicação assíncrona. Com a replicação assíncrona, é impossível evitar a perda de dados em caso de falha no primário. Para saber como você pode proteger seus dados, examine Evitar perda de dados.

Status do grupo de failover

O grupo de failover relata seu status descrevendo o estado atual da replicação de dados:

  • Propagação: a propagação inicial ocorre após a criação do grupo de failover, até que todos os bancos de dados de usuário sejam inicializados na instância secundária. O failover não pode ser iniciado enquanto o grupo de failover está no estado de Seed, já que os bancos de dados de usuário ainda não foram copiados para a instância secundária.
  • Sincronização: o status usual do grupo de failover. Isso significa que as alterações de dados na instância primária estão sendo replicadas de forma assíncrona para a instância secundária. Esse status não garante que os dados estejam totalmente sincronizados a cada momento. Pode haver alterações de dados do primário ainda a serem replicados para o secundário devido à natureza assíncrona do processo de replicação entre instâncias em um grupo de failover. Os failovers automáticos e manuais podem ser iniciados enquanto o grupo de failover está no estado de sincronização .
  • Failover em andamento: esse status indica que o failover iniciado automaticamente ou manualmente está em andamento. Nenhuma alteração no grupo de failover ou falhas adicionais podem ser iniciadas enquanto o grupo de failover estiver nesse estado.

Failback

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

Interoperabilidade de recursos

Cópias de segurança

Um backup completo é feito nos seguintes cenários:

  • Antes que a propagação inicial comece quando você cria um grupo de failover.
  • Depois de um failover.

Um backup completo é um tamanho de operação de dados que não pode ser ignorado ou adiado e pode levar algum tempo para ser concluído. O tempo necessário para concluir depende do tamanho dos dados, do número de bancos de dados e da intensidade da carga de trabalho nos bancos de dados primários. Um backup completo pode atrasar visivelmente a propagação inicial e pode atrasar ou impedir uma operação de failover em uma nova instância logo após um failover.

Considere o seguinte:

  • Os bancos de dados hospedados na instância secundária de um grupo de failover não são armazenados em backup até que essa instância se torne primária após um failover ou até que o grupo de failover seja descartado.
  • Depois que um banco de dados é alterado para a função primária após um failover ou se torna autônomo depois que um grupo de failover é descartado, um backup de banco de dados completo é iniciado automaticamente para facilitar restaurações pontuais.
  • Um banco de dados não pode ser restaurado de uma instância para um ponto no tempo em que essa instância era uma réplica secundária em um grupo de failover. Para restaurar para um ponto no tempo, você deve restaurar o banco de dados da instância que foi primária durante esse ponto no tempo.
  • Para recriar um grupo de failover descartado no mesmo par de instâncias gerenciadas de SQL, todos os bancos de dados de usuário precisam ser removidos do secundário pretendido após a remoção do grupo de failover. Um banco de dados só será totalmente removido após a conclusão de todas as operações de backup pendentes, incluindo um backup completo caso um não tenha sido realizado (sendo esta uma operação proporcional ao tamanho dos dados). Permita tempo para limpar a instância secundária depois de remover um grupo de failover com bancos de dados muito grandes, pois cada banco de dados pode ter uma operação de backup completa pendente em andamento.

Um backup completo é uma operação de dados significativa que não pode ser ignorada ou adiada e pode exigir algum tempo para ser concluída. O tempo necessário para concluir depende do tamanho dos dados, do número de bancos de dados e da intensidade da carga de trabalho nos bancos de dados primários. Um backup completo pode atrasar significativamente o seed inicial e pode atrasar ou impedir que uma operação de failover ocorra em seguida em uma nova instância logo após um failover.

Serviço de reprodução de log

Bancos de dados migrados para a Instância Gerenciada de SQL do Azure usando o LRS (Serviço de Reprodução de Log) não podem ser adicionados a um grupo de failover até que a etapa de substituição seja executada. Um banco de dados migrado com LRS está em um estado de restauração até a substituição, e os bancos de dados em um estado de restauração não podem ser adicionados a um grupo de failover. A tentativa de criar um grupo de failover com um banco de dados em um estado de restauração atrasa a criação do grupo de failover até que a restauração do banco de dados seja concluída.

Replicação transacional

Há suporte para o uso da replicação transacional com instâncias que estão em um grupo de failover. No entanto, se você configurar a replicação antes de adicionar sua instância gerenciada de SQL em um grupo de failover, a replicação será pausada quando você começar a criar seu grupo de failover. O monitor de replicação mostra um status de Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. A replicação é retomada depois que o grupo de failover é criado com êxito.

Se uma Instância Gerenciada de SQL de publicador ou distribuidor estiver em um grupo de failover, o administrador da Instância Gerenciada de SQL deverá limpar todas as publicações no antigo primário e reconfigurá-las no novo primário após a ocorrência de um failover. Revise o guia de replicação transacional para obter a etapa de atividades necessárias nesse cenário.

Limitações e permissões

Consulte uma lista de permissões e limitações antes de configurar um grupo de failover.

Gerenciar programaticamente grupos de failover

Os grupos de failover também podem ser gerenciados programaticamente usando o Azure PowerShell, a CLI do Azure e a API REST. Examine Configurar grupo de failover para saber mais.

Análises de recuperação de desastre

A maneira recomendada de executar uma análise de DR é usando a recuperação panejada manual, de acordo com o seguinte tutorial: Failover de teste.

Não é recomendável executar uma simulação usando failover forçado, pois essa operação não fornece proteções contra perda de dados. No entanto, é possível obter failover forçado sem perda de dados garantindo que as seguintes condições sejam atendidas antes de iniciar o failover forçado:

  • A carga de trabalho é interrompida na instância gerenciada de SQL primária.
  • Todas as transações de execução prolongada foram concluídas.
  • Todas as conexões de cliente com a instância gerenciada de SQL primária foram desconectadas.
  • O status do grupo de failover é “Sincronizando”.

Verifique se as duas instâncias gerenciadas de SQL mudaram de função. Além disso, o status do grupo de failover alternou de 'Failover em andamento' para 'Synchronizing' antes de, opcionalmente, estabelecer conexões com a nova instância gerenciada de SQL primária e iniciar a carga de trabalho de leitura/gravação.

Para executar um failback sem perda de dados para as funções originais da instância gerenciada de SQL, é altamente recomendável usar o failover planejado manualmente em vez do failover forçado. Caso o failback forçado seja empregado:

  • Siga as mesmas etapas do failover sem perdas de dados.
  • Mais tempo de execução de failback é esperado se o failback forçado for executado logo após a conclusão do failover forçado inicial, pois é necessário aguardar a conclusão de operações de backup automático pendentes na instância gerenciada anterior de SQL primário.
  • Qualquer operação de backup automático pendente em uma instância que faz a transição da função primária para a secundária pode afetar a disponibilidade do banco de dados nessa instância.
  • Use o status do grupo de failover para determinar se ambas as instâncias alteraram suas funções com êxito e estão prontas para aceitar conexões de cliente.

Conteúdo relacionado

  • Last updated on