Partilhar via

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

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

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

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

Lista de verificação de disponibilidade

A seguir estão as configurações recomendadas para maximizar a disponibilidade:

  • Incorpore a lógica de nova tentativa na aplicação para lidar com erros transitórios.
  • Use janelas de manutenção para tornar eventos de manutenção significativos mais previsíveis e menos perturbadores.
  • Teste a resiliência de falha do aplicativo , acionando manualmente um failover para ver a resiliência em ação.

Lista de verificação de alta disponibilidade

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

  • Habilite a redundância de zonas onde disponível para a instância gerida de SQL, a fim de garantir a resiliência a falhas zonais.

Lista de verificação de recuperação de desastres

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

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 escuta de leitura-gravação e somente leitura na sua cadeia de conexão da aplicação para que as aplicações se conectem automaticamente à instância principal.
    • Defina a política de failover como gerenciado pelo cliente.
  • Certifique-se de que a instância geosecundária seja criada com a mesma camada de serviço, geração de hardware e tamanho de computação que a instância primária.
  • Ao aumentar a escala, aumente primeiro a escala do geosecundário e, em seguida, aumente o primário.
  • Ao reduzir a escala, inverta a ordem: reduza o primário primeiro e, em seguida, diminua o secundário.
  • A recuperação de desastres, por natureza, foi projetada para usar a replicaçã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 confirmação mais alta, 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 a linha de execução até que a última transação confirmada tenha sido transmitida e firmada no log de transações do banco de dados secundário.
  • Monitore o atraso em relação ao RPO (Recovery Point Objective, objetivo de ponto de recuperação) usando a coluna replication_lag_sec da exibição de gerenciamento dinâmico (DMV) de sys.dm_geo_replication_link_status no banco de dados primário. A DMV mostra o atraso em segundos entre as transações cometidas no primário e gravadas no log de transações no secundário. Por exemplo, suponha que o atraso seja de um segundo em um determinado momento, se o primário for afetado por uma interrupção e um failover geográfico 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 para de armazenamento de backup com redundância geográfica para usar o recurso de restauração geográfica .
  • Planeje e execute frequentemente exercícios de recuperação de desastres para que você esteja mais bem preparado no caso de uma interrupção real.

Preparar o sistema secundário para uma interrupção

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

  • Para restauração geográfica, identifique a instância em outra região que se tornará a nova instância primária. Se a 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 tiver configurado grupos de comutação por falha e usar o listener de leitura-gravação e somente leitura nas cadeias de conexão da aplicação, não é necessário tomar mais nenhuma ação - as conexões são automaticamente direcionadas para o novo principal após a comutação.
  • Identifique e, se desejar, defina o NSG e a configuração da tabela de rotas que os utilizadores precisam para aceder ao novo banco de dados primário no novo servidor primário.
  • Identifique e, opcionalmente, crie os logons que devem estar presentes no banco de dados master no novo servidor primário e verifique se esses logons têm permissões apropriadas no banco de dados master, se houver.
  • Documente a configuração de auditoria no primário atual e torne idêntica à instância secundária.

Conteúdo relacionado

Para saber mais, consulte:

  • Last updated on