Compartilhar via

Lista de verificação de alta disponibilidade e recuperação de desastre - Banco de Dados SQL do Azure

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

O serviço do Banco de Dados 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. Essas diretrizes se aplicam a todos os modelos de compra e camadas de serviço do Banco de Dados 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 o banco de dados ou pool elástico para garantir a resiliência de falhas da zona.

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

Embora o Banco de Dados SQL do Azure mantenha automaticamente alta 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 impactante abrange uma região inteira. Uma interrupção regional do Banco de Dados 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 um grupo de bancos de dados.
    • 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 servidor e banco de dados primário.
    • Defina a política de failover como gerenciada pelo cliente.
  • Como alternativa aos grupos de failover, você pode habilitar a replicação geográfica ativa para ter um banco de dados secundário legível em uma região diferente do Azure.
  • Certifique-se de que o banco de dados secundário da área geográfica seja criado com a mesma camada de serviço, camada de computação (provisionada ou sem servidor) e tamanho da computação (DTUs ou vCores) que o banco de dados primário.
  • 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 ou a replicação geográfica ativa, 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 obter êxito com a recuperação para outra região de dados usando replicação geográfica ativa, grupos de failover ou restauração geográfica, você precisa preparar um servidor lógico secundário do Banco de Dados SQL do Azure em outra região. Esse servidor secundário pode se tornar o novo servidor primário, 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 o servidor em outra região para que ele se torne o novo servidor primário. Isso geralmente será um servidor na região emparelhada para a região na qual o banco de dados primário está localizado. O uso de um servidor em uma região emparelhada com o primário 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, como alternativa, defina as regras de firewall necessárias para que os usuários acessem o novo banco de dados 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. Para obter mais informações, confira Segurança do Banco de Dados SQL do Azure após a recuperação de desastre.
  • Identifique as regras de alerta que precisarão ser atualizadas para mapear para o novo primário.
  • Documente a configuração de auditoria no servidor primário atual e torne-a idêntica no servidor secundário.

Conteúdo relacionado