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

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

O Banco de Dados SQL do Azure fornece uma garantia de alta disponibilidade líder do setor de pelo menos 99,99% para dar suporte a uma ampla variedade de aplicativos, incluindo de missão crítica, que sempre precisam estar disponíveis. O Banco de Dados SQL do Azure também tem recursos de continuidade de negócios turnkey que você executa recuperação rápida de desastres no caso de uma interrupção regional. Este artigo contém informações valiosas a serem analisadas antes da implantação do aplicativo.

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

Falha do serviço

No caso de uma interrupção do serviço do Banco de Dados SQL do Azure, você pode encontrar detalhes adicionais relacionados à interrupção nos seguintes locais:

  • Banner do portal do Azure

    Se a sua subscrição for identificada como afetada, existe um alerta de interrupção de um Problema de Serviço nas 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ê cria um tíquete de suporte da Ajuda + suporte ou Suporte + solução de problemas, há informações sobre quaisquer problemas que afetem seus recursos. Selecione Exibir detalhes da interrupção para obter mais informações e um resumo do impacto. Há também 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..

  • Estado de funcionamento 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 por 'estado de funcionamento do serviço'' na barra de pesquisa no portal do Azure e, em seguida, veja 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 está 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 Asiático:

    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 e-mail

    Se você configurou alertas, uma notificação por e-mail é enviada a partir de quando uma interrupção de azure-noreply@microsoft.com serviço afeta sua assinatura e recurso. O corpo do e-mail normalmente começa com "O alerta do registro de atividades ... foi desencadeada por um problema de serviço para a subscrição do Azure...". Para obter mais informações sobre alertas de integridade do serviço, consulte Receber alertas de log de atividades em notificações de serviço do Azure usando o portal do Azure.

Quando iniciar a recuperação de desastres 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 diligentemente para restaurar a disponibilidade do serviço o mais rápido possível, mas, dependendo da causa raiz, às vezes pode levar horas. Se o seu aplicativo puder tolerar um tempo de inatividade significativo, você pode simplesmente aguardar a conclusão da recuperação. Neste caso, nenhuma ação da sua parte é necessária. Exiba a integridade de recursos individuais na página Integridade do recurso de qualquer recurso no menu Ajuda . Consulte 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 é 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 desastres deve ser executada somente quando a duração da interrupção se aproxima do RTO (Recovery Time Objetive, objetivo de tempo de recuperação) do aplicativo. Quando o aplicativo é implantado na produção, você deve executar o monitoramento regular da integridade do aplicativo e afirmar que a recuperação é garantida somente quando há falha de conectividade prolongada da camada de aplicativo para o banco de dados. Dependendo da tolerância do 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.

Orientação de recuperação de falhas

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 seu aplicativo, considere as seguintes etapas:

Failover (sem perda de dados) para servidor secundário replicado geograficamente

Se os grupos ativos de replicação geográfica ou 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 para o 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.

Nota

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 do serviço, não há garantia de que o failover sem perda de dados será bem-sucedido, mas vale a pena tentar como a primeira opção de recuperação.

Para iniciar um failover, use os seguintes links:

Tecnologia Método Passos
Georreplicação 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 o servidor secundário via CLI do Azure
Portal do Azure Failover para o servidor secundário por meio do portal do Azure
PowerShell Failover para servidor secundário via PowerShell

Failover forçado (perda potencial de dados) para servidor secundário replicado geograficamente

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

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

Tecnologia Método Passos
Georreplicação 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 o servidor secundário por meio da CLI do Azure, mas use --allow-data-loss
PowerShell Failover forçado para o servidor secundário via PowerShell, mas use -AllowDataLoss

Restauro geográfico

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

Para obter mais informações sobre restaurações geográficas por meio da CLI do Azure, do portal do Azure, do PowerShell ou da API REST, consulte Restauração geográfica do Banco de Dados SQL do Azure.

Configure seu banco de dados após a recuperação

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

Importante

Recomenda-se realizar exercícios periódicos de sua estratégia de recuperação de desastres para verificar a tolerância do aplicativo, bem como todos os aspetos operacionais do procedimento de recuperação. As outras camadas da infraestrutura do aplicativo podem exigir reconfiguração. Para obter mais informações sobre etapas de arquitetura resiliente, consulte 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, deverá certificar-se de que a conectividade com os novos bancos de dados esteja configurada corretamente para que a função normal do aplicativo possa ser retomada. Como o banco de dados recuperado reside em um servidor diferente, você precisa atualizar a cadeia de conexão do aplicativo para apontar para esse servidor. Para obter mais informações sobre como alterar cadeias de conexão, consulte a linguagem de desenvolvimento apropriada para sua biblioteca de conexões.
  • Se você estiver usando grupos de failover para se recuperar de uma interrupção e usar ouvintes de leitura-gravação e somente leitura em suas cadeias de conexão de aplicativo, nenhuma ação adicional será necessária, pois as conexões são direcionadas automaticamente para o novo primário.

Configurar as regras de firewall

Você precisa certificar-se de que as regras de firewall configuradas no servidor e no banco de dados correspondem àquelas que foram configuradas no servidor primário e no banco de dados primário. Para obter mais informações, consulte Como definir configurações de firewall (Banco de Dados SQL do Azure).

Configurar logins e usuários de banco de dados

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.

Configurar alertas de telemetria

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

Ativar auditoria

Se a auditoria for necessária para acessar seu banco de dados, você precisará habilitar a Auditoria após a recuperação do banco de dados. Para obter mais informações, consulte Auditoria SQL do Azure para o Banco de Dados SQL do Azure.

Próximos passos