Diretrizes de recuperação de desastres - Banco de Dados SQL do Azure

Aplica-se a: Banco de Dados SQL do Azure

• Banco de Dados SQL do Azure
• Instância Gerenciada do SQL do Azure

O Banco de Dados SQL do Azure fornece garantia de alta disponibilidade líder do setor de pelo menos 99,99% para dar suporte a uma ampla variedade de aplicativos, inclusive os críticos, que precisam estar sempre disponíveis. O Banco de Dados SQL do Azure também tem capacidades essenciais de continuidade dos negócios que permitem executar uma rápida recuperação de desastre no caso de uma interrupção regional. Este artigo contém informações valiosas para revisar antes da implantação do aplicativo.

Embora nos esforcemos continuamente para fornecer alta disponibilidade, há momentos em que o serviço de Banco de Dados SQL do Azure incorre em interrupção, causando indisponibilidade do seu banco de dados e, portanto, afetando seu aplicativo. Quando nosso monitoramento de serviço detecta problemas que causam erros generalizados de conectividade, falhas ou problemas de desempenho, o serviço declara automaticamente uma interrupção para mantê-lo informado.

Interrupção do serviço

No caso de uma interrupção do serviço Banco de Dados SQL do Azure, você poderá conferir detalhes adicionais relacionados à interrupção nos locais a seguir.

• Faixa do portal do Azure

  Se sua assinatura for identificada como afetada, haverá um alerta de interrupção de um problema de serviço em suas Notificações do portal do Azure:

  

• Ajuda + suporte ou Suporte + solução de problemas

  Quando você criar um tíquete de suporte da Ajuda + suporte ou Suporte + solução de problemas, haverá informações sobre quaisquer problemas que afetem seus recursos. Selecione Exibir os detalhes da interrupção para obter mais informações e um resumo do impacto. Também haverá um alerta na página Nova solicitação de suporte.

  

• Integridade do serviço

  A página Integridade do Serviço no portal do Azure contém informações sobre o status do data center do Azure globalmente. Pesquise "integridade do serviço" na barra de pesquisa no portal do Azure e exiba Problemas de serviço na categoria Eventos ativos. Você também pode exibir a integridade de recursos individuais na página Integridade do recurso de qualquer recurso no menu Ajuda. A seguir você verá uma amostra de captura de tela da página Integridade do Serviço, com informações sobre um problema de serviço ativo no Sudeste Asiático.

  

• Notificação por email

  Se você tiver configurado alertas, uma notificação por email será enviada de azure-noreply@microsoft.com quando uma interrupção de serviço afetar sua assinatura e o recurso. O corpo do email tipicamente começaria com "O alerta do log de atividades... foi disparado por um problema de serviço para a assinatura do Azure...". Para obter mais informações sobre alertas de integridade do serviço, confira Receber alertas do log de atividades em notificações de serviço do Azure usando o portal do Azure.

• Métrica de disponibilidade

  Você pode monitorar e configurar alertas da métrica de Disponibilidade do Banco de Dados SQL do Azure no portal do Azure.

Quando iniciar a recuperação de desastre durante uma interrupção

No caso de uma interrupção de serviço que afete os recursos do aplicativo, considere os seguintes cursos de ação:

• As equipes do Azure trabalham cuidadosamente para restaurar a disponibilidade do serviço o mais rapidamente possível, mas dependendo da causa raiz, isso às vezes pode levar horas. Se seu aplicativo pode tolerar tempo de inatividade significativo, você pode simplesmente esperar a conclusão da recuperação. Nesse caso, nenhuma ação sua é necessária. Exiba a integridade de recursos individuais na página Integridade do recurso de qualquer recurso no menu Ajuda. Confira a página Integridade do recurso para obter atualizações e as informações mais recentes sobre uma interrupção. Após a recuperação da região, a disponibilidade do aplicativo será restaurada.

• A recuperação para outra região do Azure pode exigir a alteração das cadeias de conexão do aplicativo ou o uso do redirecionamento de DNS e pode resultar na perda permanente de dados. Portanto, a recuperação de desastre deve ser executada somente quando a duração da interrupção se aproximar do RTO (objetivo de tempo de recuperação) do aplicativo. Quando o aplicativo é implantado na produção, você deve realizar o monitoramento regular da integridade dele e afirmar que a recuperação será garantida somente quando houver falha de conectividade prolongada da camada de aplicativo para o banco de dados. Dependendo da tolerância de seu aplicativo ao tempo de inatividade e possível responsabilidade comercial, você pode decidir se deseja aguardar a recuperação do serviço ou iniciar a recuperação de desastres por conta própria.

Diretrizes da recuperação de interrupção

Se a interrupção do Banco de Dados SQL do Azure em uma região não tiver sido atenuada por um longo período de tempo e estiver afetando o Contrato de Nível de Serviço (SLA) do aplicativo, considere as seguintes etapas:

Failover (sem perda de dados) para o servidor secundário com replicação geográfica

Se a replicação geográfica ativa ou os grupos de failover estiverem habilitados, verifique se o status do recurso de banco de dados primário e secundário está Online no portal do Azure. Nesse caso, o plano de dados do banco de dados primário e secundário está íntegro. Inicie um failover de replicação geográfica ativa ou grupos de failover para a região secundária usando o portal do Azure, T-SQL, PowerShell ou CLI do Azure.

Observação

Um failover requer sincronização completa de dados antes de alternar funções e não resulta em perda de dados. Dependendo do tipo de interrupção de serviço, não há garantia de que o failover sem perda de dados terá êxito, mas vale a pena tentar como a primeira opção de recuperação.

Para iniciar um failover, use os seguintes links:

Tecnologia	Método	Etapas
Replicação geográfica ativa	PowerShell	Failover para replicação geográfica secundária via PowerShell
	T-SQL	Failover para replicação geográfica secundária via T-SQL
Grupos de failover	CLI do Azure	Failover para servidor secundário via CLI do Azure
	Portal do Azure	Failover para servidor secundário via portal do Azure
	PowerShell	Failover para servidor secundário via PowerShell

Failover forçado (potencial perda de dados) para o servidor secundário com replicação geográfica

Se o failover não for concluído normalmente e apresentar erros, ou se o status do banco de dados primário não for Online, considere um failover forçado com possível perda de dados para a região secundária.

Para iniciar um failover forçado, use os seguintes links:

Tecnologia	Método	Etapas
Replicação geográfica ativa	CLI do Azure	Failover forçado para replicação geográfica secundária por meio da CLI do Azure
	Portal do Azure	Failover forçado para replicação geográfica secundária por meio do portal do Azure
	PowerShell	Failover forçado para replicação geográfica secundária via PowerShell
	T-SQL	Failover forçado para replicação geográfica secundária via T-SQL
Grupos de failover	Portal do Azure	Failover forçado para o servidor secundário por meio do portal do Azure, mas escolha Failover forçado.
	CLI do Azure	Failover forçado para servidor secundário via CLI do Azure com uso de --allow-data-loss
	PowerShell	Failover forçado para servidor secundário via PowerShell com uso de -AllowDataLoss

Restauração geográfica

Se você não habilitou a replicação geográfica ativa ou os grupos de failover, então, como último recurso, você pode usar a restauração geográfica para se recuperar de uma interrupção. A restauração geográfica usa backups replicados geograficamente como a origem. Você pode restaurar um banco de dados em qualquer servidor lógico em qualquer região do Azure pelos backups replicados geograficamente mais recentes. É possível solicitar uma restauração geográfica mesmo quando uma interrupção tornou o banco de dados ou toda a região inacessível.

Para obter mais informações sobre a restauração geográfica por meio da CLI do Azure, portal do Azure, PowerShell ou API REST, confira Restauração geográfica de um banco de dados SQL do Azure.

Configurar o banco de dados após a recuperação

Se estiver usando o failover geográfico ou a restauração geográfica para se recuperar de uma interrupção, você deverá se certificar de que a conectividade com o novo banco de dados está configurada corretamente para que o funcionamento normal do aplicativo possa ser retomado. Esta é uma lista de verificação de tarefas para preparar para produção o seu banco de dados recuperado.

Importante

É recomendável realizar análises periódicas de sua estratégia de recuperação de desastre para verificar a tolerância ao aplicativo, bem como todos os aspectos operacionais do procedimento de recuperação. As outras camadas da infraestrutura do aplicativo podem exigir reconfiguração. Para obter mais informações sobre as etapas de arquitetura resiliente, examine a Lista de verificação de alta disponibilidade e recuperação de desastres do Banco de Dados SQL do Azure.

Atualizar cadeias de conexão

• Se você estiver usando replicação geográfica ativa ou restauração geográfica, verifique se a conectividade com os novos bancos de dados está configurada corretamente para que a função normal do aplicativo possa ser retomada. Já que o banco de dados recuperado residirá em um servidor diferente, você precisa atualizar a cadeia de conexão do seu aplicativo para apontar para esse servidor. Para saber mais sobre como alterar as cadeias de conexão, confira a linguagem de desenvolvimento apropriada para sua biblioteca de conexão.
• Caso esteja usando grupos de failover para se recuperar de uma interrupção e use ouvintes de leitura/gravação e somente leitura nas cadeias de conexão do aplicativo, nenhuma outra ação será necessária, pois as conexões serão direcionadas automaticamente para o novo principal.

Configurar regras de firewall

Você precisa se certificar de que as regras de firewall configuradas no servidor e no banco de dados secundários correspondam àquelas que foram configuradas no servidor e no banco de dados primários. Para obter mais informações, confira Como definir as configurações de firewall.

Configurar logons e usuários do banco de dados

Crie os logons que devem estar presentes no banco de dados master do novo servidor primário e verifique se esses logons têm permissões apropriadas no banco de dados master, se aplicável. Para obter mais informações, confira Segurança após uma recuperação de desastre.

Configurar alertas de telemetria

Você precisa certificar-se de que as configurações de regra de alerta existentes sejam atualizadas para mapear para o novo banco de dados primário e para o outro servidor. Para obter mais informações sobre regras de alerta de banco de dados, consulte Receber notificações de alerta e Acompanhar a integridade do serviço.

Habilitar a auditoria

Se você tiver a auditoria configurada no servidor primário, torne-a idêntica no servidor secundário. Para obter mais informações, consulte Auditoria.

Conteúdo relacionado

Para saber mais, confira:

• Cenários de continuidade.
• Backups automatizados
• Restaure um banco de dados dos backups iniciados pelo serviço.
• Para saber mais sobre opções de recuperação mais rápidas, consulte Replicação geográfica ativa e Grupos de failover.
• Revise as diretrizes de recuperação de desastre e a lista de verificação de alta disponibilidade e recuperação de desastre.