Orientação para recuperação de desastres - Azure SQL Managed Instance

Aplica-se a: Azure SQL Managed Instance

Azure SQL Managed Instance fornece um SLA de disponibilidade classe empresarial para suportar uma grande variedade de aplicações, incluindo aquelas críticas para a missão, que precisam estar sempre disponíveis. O Azure SQL Managed Instance também tem capacidades de continuidade de negócio prontas para uso que pode implementar para uma recuperação rápida de desastres em caso de interrupção regional. Este artigo contém informações valiosas para rever antes da implementação da aplicação.

Embora nos esforcemos continuamente para garantir disponibilidade, há momentos em que o serviço Azure SQL Managed Instance sofre interrupções que causam a indisponibilidade da sua base de dados e, consequentemente, afetam a sua aplicação. 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.

Interrupção do serviço

No caso de uma falha no serviço Azure SQL Managed Instance, pode encontrar detalhes adicionais relacionados com a interrupção nos seguintes locais:

  • Banner do portal Azure

    Se a sua subscrição for identificada como afetada, há um alerta de falha de Serviço no seu portal de Azure Notificações:

    Captura de ecrã do portal Azure de uma notificação de um problema de serviço Azure SQL Managed Instance.

  • Ajuda + suporte ou suporte + resolução de problemas

    Quando criar um ticket de suporte a partir de Ajuda + suporte ou Suporte + resolução de problemas, existem informações sobre quaisquer problemas que afetem os 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 de pedidos de novo suporte .

    Captura de ecrã da página Ajuda+Suporte mostrando uma notificação de um problema de saúde do serviço ativo.

  • Estado de funcionamento do serviço

    A página Service Health no portal Azure contém informações sobre o estado global do Azure centro de dados. Procure por 'saúde do serviço'' na barra de pesquisa do portal Azure, depois veja problemas de serviço na categoria eventos ativos. Também pode ver a saúde de recursos individuais na página de Saúde de Recursos de qualquer recurso, no menu de Ajuda . A seguir está uma captura de ecrã de exemplo da página Saúde do Serviço, com informações sobre um problema ativo de serviço no Sudeste Asiático.

    Captura de ecrã da página de Saúde do Serviço do portal Azure durante um problema de serviço no Sudeste Asiático, mostrando o problema e um mapa dos recursos afetados.

  • Notificação por e-mail

    Se configurou os alertas, é enviada uma notificação por email a partir de azure-noreply@microsoft.com quando uma falha de serviço afeta a sua subscrição e recursos. O corpo do email normalmente começa com "O alerta do registo de atividades ... foi desencadeado por um problema de serviço para a subscrição do Azure... ". Para mais informações sobre alertas de saúde de serviço, consulte Receba alertas de registo de atividade em notificações de serviço Azure usando Azure portal.

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 equipas do Azure trabalham arduamente para restaurar a disponibilidade dos serviços o mais rapidamente possível, mas dependendo da causa raiz, por vezes pode demorar horas. Se o seu aplicativo puder tolerar um tempo de inatividade significativo, você pode apenas aguardar a conclusão da recuperação. Neste caso, nenhuma ação da sua parte é necessária. Veja a saúde dos recursos individuais na página de Saúde dos Recursos de qualquer recurso, no menu de Ajuda . Consulte a página de Saúde dos Recursos para as 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 strings de ligação da aplicação ou o uso de redirecionamento DNS, podendo 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 a aplicação é implementada para produção, deve realizar monitorização regular do estado da aplicação e afirmar que a recuperação só é justificada quando houver falhas prolongadas de conectividade do nível da aplicação para a base 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ções para a recuperação de interrupções

Se a interrupção do Azure SQL Managed Instance numa região não foi mitigada durante um período prolongado e estiver a afetar o acordo de nível de serviço (SLA) da sua aplicação, considere os seguintes passos:

Failover (sem perda de dados) para uma instância secundária geo-replicada

Se os grupos failover estiverem ativados, verifique se o estado dos recursos da instância primária e secundária é Online no portal Azure. Se assim for, o plano de dados tanto para a instância primária como para a secundária está saudável.

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

Observação

Um failover requer sincronização total dos dados antes de mudar de função 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 tenha sucesso, mas vale a pena tentar como primeira opção de recuperação.

Failover forçado (potencial perda de dados) para uma instância secundária geo-replicada

Se o failover não for concluído corretamente e apresentar erros, ou se o estado da base de dados primária não for Online, considere cuidadosamente o failover forçado com potencial perda de dados na região secundária.

Para iniciar um failover forçado, utilize:

Restauração Geográfica

Se ainda não ativaste os grupos de failover, então, como último recurso, podes usar a geo-restauração para recuperares de uma falha. A restauração geográfica usa backups replicados geograficamente como origem. Pode restaurar uma base de dados em qualquer instância em qualquer região do Azure a partir dos backups geo-replicados mais recentes. Pode solicitar uma restauração geográfica mesmo que uma falha tenha tornado a instância ou toda a região inacessível.

Para mais informações sobre restauros geográficos via Azure CLI, o portal Azure, PowerShell ou a API REST, consulte Geo-restore.

Configure a sua base de dados após a recuperação

Se estiver a usar geo-failover ou geo-restauro para recuperar de uma falha, deve garantir que a conectividade à nova instância está devidamente configurada para que a função normal da aplicação possa ser retomada. Esta é uma lista de tarefas para preparar a produção da sua base de dados recuperada.

Importante

Recomenda-se realizar exercícios periódicos da sua estratégia de recuperação de desastres para verificar a tolerância da aplicação, bem como todos os aspetos operacionais do processo de recuperação. As outras camadas da infraestrutura da sua aplicação podem precisar de reconfiguração. Para mais informações sobre os passos da arquitetura resiliente, consulte a lista de verificação de alta disponibilidade e recuperação de desastres.

Atualizar cadeias de conexão

  • Se estiver a usar geo-restore, deve garantir que a ligação à nova instância está devidamente configurada para que a função normal da aplicação possa ser retomada. Como a tua base de dados recuperada reside numa instância diferente, precisas de atualizar a connection string da tua aplicação para apontar para esse servidor. Para mais informações sobre a alteração de cadeias de ligação, consulte a linguagem de desenvolvimento apropriada para a sua biblioteca de ligações.
  • Se estiver a usar grupos de failover para recuperar de uma falha e usar ouvintes de leitura-escrita e apenas leitura nas cadeias de ligação da sua aplicação, então não é necessária mais nenhuma ação, pois as ligações são automaticamente direcionadas para o novo primário.

Configurar as regras de firewall

Certifique-se de que as regras NSG e da tabela de roteamento configuradas para a instância secundária correspondem às configuradas na instância primária. Consulte Configuração de sub-redes assistida por serviço para saber mais.

Configurar logins e utilizadores da base de dados

Crie os logins que devem estar presentes na master base de dados na instância secundária e garanta que esses logins têm as permissões adequadas na master base de dados, se existirem.

Configurar alertas de telemetria

Certifica-te de que as definições atuais das tuas regras de alerta estão atualizadas para mapear para a nova instância principal. Para mais informações sobre as regras de alerta da base de dados, consulte Receber Notificações de Alerta e Acompanhar a Saúde do Serviço.

Habilitar auditoria

Se tiver a auditoria configurada na instância principal, torne-a idêntica na instância secundária. Para mais informações, consulte Auditoria do SQL Server na instância gerida do Azure SQL e Inicie a auditoria da instância gerida de Azure SQL.

Conteúdo relacionado

Para saber mais, consulte:

  • Last updated on