Partilhar via

Executando exercícios de recuperação de desastres - Instância Gerenciada SQL do Azure

Aplica-se a:Azure SQL Managed Instance

Você deve testar e validar periodicamente se os aplicativos estão prontos para um fluxo de trabalho de recuperação. Verificar o comportamento do aplicativo e as implicações da perda de dados e/ou da interrupção que o failover envolve é uma boa prática de engenharia. Também é um requisito para a maioria dos padrões do setor como parte da certificação de continuidade de negócios.

A execução de um exercício de recuperação de desastres consiste em:

  • Simulando a interrupção da camada de dados
  • Recuperação
  • Validar a integridade do aplicativo após a recuperação
  • Retorno à instância original (opcional)

Dependendo de como você projetou seu aplicativo parade continuidade de negócios, o fluxo de trabalho para executar o drill pode variar. Este artigo descreve as práticas recomendadas para conduzir um drill de recuperação de desastres no contexto da Instância Gerenciada SQL do Azure.

Restauração Geográfica

Para evitar a perda potencial de dados ao conduzir um drill de recuperação de desastres, execute o drill usando um ambiente de teste criando uma cópia do ambiente de produção e usando-o para verificar o fluxo de trabalho de failover do aplicativo.

Simulação de interrupção

Para simular a interrupção, você pode renomear o banco de dados de origem. Essa alteração de nome causa falhas de conectividade do aplicativo.

Recuperação

Validação

Conclua o drill verificando a integridade do aplicativo após a recuperação (incluindo cadeias de conexão, logins, testes de funcionalidade básica ou outras validações que fazem parte dos procedimentos padrão de aprovação do aplicativo).

Recuperação

Com a restauração geográfica, o processo de failback consiste em redirecionar a aplicação para a instância original.

Grupos de tolerância a falhas

Para uma instância protegida por grupos de failover, o exercício de simulação envolve uma comutação por falha planeada para a instância secundária. O failover planejado garante que as instâncias primária e secundária no grupo de failover permaneçam sincronizadas quando as funções forem alternadas. Ao contrário do failover não planejado, essa operação não resulta em perda de dados, portanto, a perfuração pode ser executada em um ambiente de produção.

Configure o seu grupo de falha com a política de falha que atenda às suas necessidades de negócio e teste a falha independentemente de como a sua política de falha está configurada. Para obter mais informações, revise teste de failover. Recomenda-se uma política de failover gerenciada pelo cliente para oferecer controle sobre o processo de failover.

Importante

Como os bancos de dados do sistema não são replicados entre instâncias em um grupo de failover, recrie manualmente os objetos do sistema na instância secundária e, em seguida, teste ambientes com dependências de objetos do sistema para garantir que eles continuem funcionando corretamente após um failover.

Simulação de interrupção

Para simular a interrupção, você pode desabilitar o aplicativo Web ou a máquina virtual conectada ao banco de dados. Essa simulação de interrupção resulta em falhas de conectividade para os clientes da Web.

Recuperação

Validação

Conclua a simulação verificando a integridade da aplicação após a recuperação (incluindo conectividade, testes de funcionalidades básicas ou outras validações necessárias para a conclusão da simulação).

Recuperação

Para realizar um failback, execute uma failover planeada do grupo de failover de volta para a instância primária original. Como o aplicativo já está configurado para apontar para o ponto de extremidade do grupo de failover, não são necessárias mais alterações. O ponto de extremidade do grupo de failover roteia automaticamente o tráfego para a nova instância primária após o failover.

O failback é opcional. Se você não precisar fazer failback, poderá manter a instância secundária como a nova instância primária.

É possível usar um link de Instância Gerenciada para recuperação de desastres.

O failover bidirecional só é suportado entre:

O SQL Server 2019 e versões anteriores oferecem suporte apenas a failover unidirecional e não há suporte para failback para o SQL Server.

Esta seção descreve como executar um drill de recuperação de desastres com o SQL Server 2022 ou o SQL Server 2025. Ao usar um link de Instância Gerenciada para recuperação de desastres, o exercício envolve uma comutação planejada para a instância secundária. O failover planejado garante que as instâncias primária e secundária no link de Instância Gerida permaneçam sincronizadas quando as funções forem trocadas. Ao contrário do failover não planejado, essa operação não resulta em perda de dados, portanto, a perfuração pode ser executada em um ambiente de produção.

Simulação de interrupção

Para simular a interrupção, desative as conexões do cliente com a réplica primária do banco de dados replicado via link. Essa simulação de interrupção resulta em falhas de conectividade para os clientes de banco de dados (aplicativos).

Recuperação

Para recuperação, faça o seguinte:

  1. Inicie um failover de link programado para a instância secundária.
  2. Reaponte os aplicativos afetados para a nova instância primária.

Validação

Para validação, faça o seguinte:

  1. Execute testes de conectividade de aplicativos e leitura/gravação na nova instância primária.
  2. Opcionalmente, valide se os dados de teste gravados durante o drill são replicados para a instância secundária.

Recuperação

Para recuperação, execute uma transferência planejada da ligação da Instância Gerida para a instância primária original. Após o failover, o aplicativo deve ser redirecionado para a instância primária original.

O failback é opcional. Se você não precisar fazer failback, poderá manter a instância secundária como a nova instância primária.

Conteúdo relacionado

Para saber mais, consulte:

  • Last updated on