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

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

SQL do Azure Banco de Dados fornece garantia de alta disponibilidade líder do setor de pelo menos 99,99% para dar suporte à missão crítica e a uma ampla variedade de aplicativos que precisam estar sempre disponíveis. O Banco de Dados SQL do Azure também tem a capacidade de transformar a solução de continuidade dos negócios que permite 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 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, 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.

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • 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.

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • 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. Confira a seguir uma captura de tela de exemplo da página Integridade do Serviço, com informações sobre um problema de serviço ativo no Sudeste da Ásia.

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • Notificação por email

    Se você tiver configurado alertas, uma notificação por email chegará quando uma interrupção de serviço afetar sua assinatura e o recurso. Os emails chegam de "azure-noreply@microsoft.com". O corpo do email 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.

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 em 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 do aplicativo e garantir que a recuperação seja 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 SLA (contrato de nível de serviço) do aplicativo, considere as seguintes etapas:

Failover planejado (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 automático 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 planejado de replicação geográfica ativa ou grupos de failover automático para a região secundária usando o portal do Azure, T-SQL, PowerShell ou CLI do Azure.

Observação

Um failover planejado 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 planejado sem perda de dados terá êxito, mas vale a pena tentar como a primeira opção de recuperação.

Para iniciar um failover planejado, 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 automático 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 não planejado (potencial perda de dados) para o servidor secundário com replicação geográfica

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

Tecnologia Método Etapas
Replicação geográfica ativa CLI do Azure Iniciar um failover forçado via CLI do Azure
Portal do Azure Iniciar um failover forçado via portal do Azure
PowerShell Iniciar um failover forçado via PowerShell
T-SQL Failover não planejado para replicação geográfica secundária via T-SQL
Grupos de failover automático Portal do Azure Failover para servidor secundário via portal do Azure
CLI do Azure Failover para servidor secundário via CLI do Azure com uso de --allow-data-loss
PowerShell Failover 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 grupos de failover automático, 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 para solicitar uma 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 esteja 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.

  • Se você estiver usando grupos de failover automático para se recuperar de uma interrupção e usar 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 certificar-se de que as regras de firewall configuradas no servidor e no banco de dados correspondam àquelas que foram configuradas no servidor primário e no banco de dados primário. Para saber mais, consulte Como definir configurações de firewall (Banco de Dados SQL do Azure).

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 do Banco de Dados SQL do Azure após a 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 a auditoria for necessária para acessar o banco de dados, você precisará habilitar a auditoria após a recuperação do banco de dados. Para obter mais informações, confira Auditoria de SQL do Azure para Banco de Dados SQL do Azure.

Próximas etapas