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

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

O serviço Banco de Dados SQL do Azure garante automaticamente que todos os bancos de dados estejam online, íntegros e se esforce constantemente para atingir 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 todos os modelos de compra e camadas de serviço da Base de Dados SQL do Azure.

Lista de verificação de disponibilidade

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

Lista de verificação de elevada disponibilidade

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

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

Embora o Banco de Dados SQL do Azure mantenha automaticamente a disponibilidade, há instâncias em que mesmo ter 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 do Banco de Dados 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 um grupo de bancos de dados.
    • Use os pontos de extremidade de escuta de leitura-gravação e somente leitura em sua cadeia de conexão de aplicativo para que os aplicativos se conectem automaticamente ao 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 geosecundário seja criado com a mesma camada de serviço, camada de computação (provisionada ou sem servidor) e tamanho de computação (DTUs ou vCores) que o banco de dados primário.
  • Ao aumentar a escala, aumente primeiro a escala do geosecundário e, em seguida, aumente o primário.
  • Ao reduzir verticalmente, inverta a ordem: comece por reduzir verticalmente a principal e, em seguida, a secundária.
  • 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 a transação. A chamada bloqueia o thread de chamada sp_wait_for_database_copy_sync até que a última transação confirmada tenha sido transmitida e reforçada no log de transações do banco de dados secundário.
  • Monitore o atraso em relação ao RPO (Recovery Point Objetive, objetivo de ponto de recuperação) usando a replication_lag_sec coluna do sys.dm_geo_replication_link_status DMV (modo de exibição de gerenciamento dinâmico) no banco de dados primário. O Detran mostra defasagem em segundos entre as transações confirmadas no primário e reforçadas para o log de transações no secundário. Por exemplo, suponha que o atraso é de um segundo em um ponto no tempo, 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 ou 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 o recurso de restauração geográfica.
  • Planeje e execute exercícios de recuperação de desastres com frequência para que você esteja mais bem preparado no caso de uma interrupção real.

Preparar o secundário para uma interrupção

Para uma recuperação bem-sucedida 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, 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 o servidor em outra região para se tornar o novo servidor primário. Geralmente, trata-se de um servidor na região emparelhada da região em que o banco de dados primário está localizado. Usar um servidor na mesma região 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ê configurou grupos de failover e usa o ouvinte leitura-gravação e somente leitura nas cadeias de conexão do aplicativo, nenhuma ação adicional é necessária - as conexões são automaticamente direcionadas para o novo primário após o failover.
  • Identifique e, opcionalmente, defina as regras de firewall necessárias para que os usuários acessem o novo banco de dados primário.
  • Identifique e, opcionalmente, crie os logons que devem estar presentes no banco de dados no novo servidor primário e verifique se esses logons têm permissões apropriadas no master master banco de dados, se houver. Para obter mais informações, consulte Segurança do Banco de Dados SQL do Azure após a recuperação de desastres.
  • Identifique as regras de alerta que precisam ser atualizadas para serem mapeadas para a nova primária.
  • Documente a configuração de auditoria no primário atual.

Conteúdos relacionados