Partilhar via

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

  • Artigo

Aplica-se a: do 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 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 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:

  • Incorpore a lógica de repetição na aplicação para lidar com erros transitórios.
  • Use janelas de manutenção para tornar eventos de manutenção significativos previsíveis e menos perturbadores.
  • Teste a resiliência a falhas da aplicação desencadeando manualmente uma falha para observar a resiliência em ação.

Lista de verificação de alta disponibilidade

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

  • Habilite de redundância de zona onde ela estiver disponível para o banco de dados ou pool elástico para garantir resiliência para falhas zonais.

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 regional interrupção 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 bases de dados.
    • Use os endpoints de leitura-escrita e apenas leitura na cadeia de ligação da sua aplicação, de forma que as aplicações se conectem automaticamente ao servidor e base de dados que sejam os primários atuais.
    • Defina a política de tolerância a falhas para gerido pelo cliente.
  • Como alternativa aos grupos de failover, pode-se habilitar a replicação geográfica ativa para ter um banco de dados secundário legível numa 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 secundário geográfico e, em seguida, aumente a escala do 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 o processo de chamada até que a última transação confirmada tenha sido transmitida e finalizada 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 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. 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 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 ativar grupos de failover ou replicação geográfica ativa, considere definir a opção de redundância de armazenamento de backup para armazenamento de backup georredundante para utilizar a restauração geográfica no Banco de Dados SQL do Azure.
  • 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 falha

Para recuperar com êxito 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 um servidor em outra região para se tornar o novo servidor primário. 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 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 é 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 que os usuários precisam para acessar o novo banco de dados 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. 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 o de configuração de auditoria de no servidor primário atual e torne-o idêntico no servidor secundário.

Conteúdo relacionado