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

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

O serviço Instância Gerenciada de SQL do Azure garante automaticamente que todos os bancos de dados estejam online, íntegros e constantemente se esforçam para 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 Azure. Essa orientação se aplica a todas as camadas de serviço de 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 o Instância Gerenciada de SQL do Azure mantenha automaticamente a disponibilidade, há situações em que até mesmo alta disponibilidade (redundância de zona) pode não garantir resiliência, já que a queda afeta toda uma região. 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 do ouvinte de leitura-gravação e somente leitura na cadeia de conexão do aplicativo para que os aplicativos se conectem automaticamente à instância que for 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, escale verticalmente primeiro o secundário geográfico e, em seguida, o 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 mais alta de confirmação, considere chamar o procedimento armazenado sp_wait_for_database_copy_sync imediatamente após confirmar uma 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 atraso 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 atraso em segundos entre as transações confirmadas no primário e protegidas para o log de transações no secundário. Por exemplo, suponha que a latência seja de um segundo em um determinado momento. Se a instância primária for afetada por uma falha e um geo-failover 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 sistema secundário para uma interrupção operacional

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 restauração geográfica, identifique a instância em outra região a se tornar a nova instância primária. Se sua região primária tiver uma região emparelhada, é comum usar a região emparelhada como sua região secundária. Ao fazer isso, você normalmente reduz a latência para operações de replicação e 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ê configurou grupos de failover e usa o ouvinte de leitura/gravação e somente leitura em cadeias de conexão de aplicativo, nenhuma ação adicional será necessária – 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 SQL Server no primário atual e torne-a idêntica na instância secundária.

Conteúdo relacionado

Para saber mais, confira:

  • Last updated on