Compartilhar via

Lista de verificação de alta disponibilidade e recuperação de desastre - Instância Gerenciada de SQL do Azure

  • Artigo

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

O serviço da Instância Gerenciada de SQL do Azure garante automaticamente que todos os bancos de dados estejam online, íntegros e que constantemente busquem alcançar o SLA publicado.

Este guia fornece uma revisão detalhada das etapas proativas que você pode executar para maximizar a disponibilidade, garantir a recuperação e se preparar para interrupções do Azure. Esta orientação se aplica a todas as camadas de serviço da Instância Gerenciada de SQL do Azure.

Lista de verificação de disponibilidade

Veja a seguir as configurações recomendadas para maximizar a disponibilidade:

Lista de verificação de alta disponibilidade

Esta é a configuração recomendada para obter alta disponibilidade:

  • Habilite a redundância de zona quando disponível para a instância gerenciada de SQL para garantir a resiliência de falhas da zona.

Lista de verificação de recuperação de desastre

Embora a Instância Gerenciada de SQL do Azure mantenha automaticamente a disponibilidade, há instâncias em que mesmo ter uma alta disponibilidade (redundância de zona) pode não garantir a resiliência, pois a interrupção de impacto abrange uma região inteira. Uma interrupção regional da Instância Gerenciada de SQL do Azure pode exigir que você inicie a recuperação de desastre.

Para se preparar melhor para a recuperação de desastres, siga estas recomendações:

  • Habilite grupos de failover para uma instância.
    • Use os pontos de extremidade de ouvinte de leitura-gravação e somente leitura na cadeia de conexão do aplicativo para que os aplicativos se conectem automaticamente a qualquer instância primária.
    • Defina a política de failover como gerenciada pelo cliente.
  • Verifique se a instância geográfica secundária foi criada com a mesma camada de serviço, geração de hardware e tamanho da computação que a instância primária.
  • Ao escalar verticalmente, faça primeiro no secundário geográfico e, em seguida, no primário.
  • Ao reduzir verticalmente, faça o oposto: primeiro reduza o primário e, em seguida, o secundário.
  • A recuperação de desastre, por natureza, foi criada para usar a duplicação assíncrona de dados entre a região primária e secundária. Para priorizar a disponibilidade de dados em relação à latência de commit mais alta, considere chamar o procedimento armazenado sp_wait_for_database_copy_sync imediatamente após fazer commit da transação. Chamar sp_wait_for_database_copy_sync bloqueia o thread de chamada até que a última transação confirmada seja transmitida e persistida no log de transações do banco de dados secundário.
  • Monitore o retardo em relação ao RPO (Objetivo de Ponto de Recuperação), usando a coluna replication_lag_sec da DMV (exibição de gerenciamento dinâmico) sys.dm_geo_replication_link_status no banco de dados primário. A DMV mostra o retardo em segundos entre as transações confirmadas no primário e persistidas no log de transações do secundário. Por exemplo, assuma que o retardo é de um segundo em um momento específico. Se o primário for afetado por uma interrupção e um failover da área geográfica for iniciado nesse momento, as transações confirmadas no último segundo serão perdidas.
  • Se não for possível habilitar grupos de failover, considere definir a opção de redundância de armazenamento de backup como armazenamento de backup com redundância geográfica para usar a capacidade de restauração geográfica.
  • Planeje e execute análises de recuperação de desastre com frequência para que você esteja melhor preparado em caso de uma interrupção real.

Preparar o secundário para uma interrupção

Para uma recuperação com êxito para outra região de dados usando grupos de failover ou restauração geográfica, você precisa preparar uma Instância Gerenciada de SQL do Azure secundária em outra região. Essa instância secundária pode se tornar a nova instância primária, caso necessário. Você também deve ter etapas bem definidas documentadas e testadas para garantir uma recuperação tranquila. Essas etapas de preparação incluem:

  • Para uma restauração geográfica, identifique a instância em outra região para que ela se torne a nova instância primária. Isso geralmente é uma instância na região emparelhada para a região na qual a instância primária está localizada. O uso de uma instância em uma região emparelhada com a região primária elimina o custo extra de tráfego durante as operações de restauração geográfica.
  • Determine como você vai redirecionar os usuários para o novo servidor primário. O redirecionamento de usuários pode ser feito alterando manualmente as cadeias de conexão do aplicativo ou as entradas DNS. Se você tiver configurado grupos de failover e usar o ouvinte de leitura/gravação e somente leitura em cadeias de conexão do aplicativo, nenhuma ação adicional será necessária, pois as conexões serão direcionadas automaticamente para o novo primário após o failover.
  • Identifique e, opcionalmente, defina a configuração do NSG e da tabela de roteamento de que os usuários precisam para acessar o novo banco de dados primário no novo primário.
  • Identificar e, como alternativa, criar os logons que devem estar presentes no banco de dados master do novo servidor primário e verificar se esses logons têm permissões apropriadas no banco de dados master, se aplicável.
  • Documente a configuração de auditoria na primária atual e torne-a idêntica na instância secundária.

Conteúdo relacionado

Para saber mais, confira: