Compartilhar via

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

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 a disponibilidade, há instâncias em que até mesmo ter alta disponibilidade (redundância de zona) pode não garantir resiliência, pois a interrupção que afeta 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, suponha que o atraso seja de um segundo em determinado momento; se o servidor primário for afetado por uma interrupção e um failover geográfico for iniciado nesse instante, as transações confirmadas no segundo anterior serão perdidas.
  • Se não for possível habilitar os grupos de failover ou a replicação geográfica ativa, considere a possibilidade de definir a opção de redundância de armazenamento de backup como Armazenamento de backup com redundância geográfica para usar a restauração geográfica para o Banco de Dados SQL do Azure.
  • 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. 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ê 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, consulte Configurar e gerenciar a segurança do Banco de Dados SQL do Azure para restauração geográfica ou failover .
  • 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

  • Last updated on