Diretrizes de recuperação de desastre - Instância Gerenciada de SQL do Azure

Aplica-se a: Instância Gerenciada de SQL do Azure

A Instância Gerenciada de SQL do Azure oferece uma 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. A Instância Gerenciada de 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 empenhemos continuamente para oferecer alta disponibilidade, há momentos em que o serviço de Instância Gerenciada de 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 de Instância Gerenciada de SQL do Azure, você poderá encontrar detalhes adicionais relacionados à interrupção nos seguintes locais:

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

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. Caso seu aplicativo possa tolerar um 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 da Instância Gerenciada de SQL do Azure em uma região não tiver sido mitigada 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 a instância secundária com replicação geográfica

Se os grupos de failover estiverem habilitados, verifique se o status do recurso da instância primária e secundária está Online no portal do Azure. Nesse caso, o plano de dados da instância primária e secundária está íntegro.

Inicie um failover de grupos de failover para a região secundária usando:

• Azure portal
• PowerShell
• CLI do Azure.

Failover forçado (potencial perda de dados) para a instância secundária 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 cuidadosamente um failover forçado com possível perda de dados para a região secundária.

Para iniciar um failover forçado, use:

• Portal do Azure, mas escolha Failover Forçado.
• PowerShell, mas use --allow-data-loss.
• CLI do Azure, mas use -AllowDataLoss.

Restauração geográfica

Se você não habilitou 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. É possível restaurar um banco de dados em qualquer instância em qualquer região do Azure dos backups replicados geograficamente mais recentes. É possível solicitar uma restauração geográfica mesmo quando uma interrupção tornou a instância 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, confira Restauração geográfica.

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

Caso esteja 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 a nova instância 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.

Atualizar cadeias de conexão

• Se estiver usando a restauração geográfica, você deverá se certificar de que a conectividade com a nova instância esteja configurada corretamente para que o funcionamento normal do aplicativo possa ser retomado. Já que o banco de dados recuperado residirá em uma instância 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

Verifique se as regras de NSG e de tabela de rotas configuradas para a instância secundária correspondem às configuradas na instância primária. Confira Configuração de sub-rede auxiliada por serviço para saber mais.

Configurar logons e usuários do banco de dados

Crie os logons que devem estar presentes no banco de dados master na instância primária, e verifique se esses logons têm permissões apropriadas no banco de dados master, se aplicável.

Configurar alertas de telemetria

Verifique se as configurações atuais de regras de alerta estão atualizadas para mapear para a nova instância primária. 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

Caso tenha a auditoria configurada na instância primária, torne-a idêntica na instância secundária. Para obter mais informações, confira Auditoria de SQL do Azure para a Instância Gerenciada de SQL do Azure.

Conteúdo relacionado

Para saber mais, confira:

• Cenários de continuidade.
• Backups automatizados
• Restaure um banco de dados dos backups iniciados pelo serviço.
• Grupos de failover.
• Diretrizes de recuperação de desastres
• Lista de verificação de alta disponibilidade e recuperação de desastre.
• Bancos de dados com redundância de zona