Use a restauração geográfica para recuperar um aplicativo SaaS multilocatário a partir de backups de banco de dados

Aplica-se a:Banco de Dados SQL do Azure

Este tutorial explora um cenário completo de recuperação de desastres para um aplicativo SaaS multilocatário implementado com o banco de dados por modelo de locatário. Você usa a restauração geográfica para recuperar os bancos de dados de catálogo e locatário de backups com redundância geográfica mantidos automaticamente em uma região de recuperação alternativa. Depois que a interrupção for resolvida, você usará a replicação geográfica para repatriar bancos de dados alterados para sua região original.

A restauração geográfica é a solução de recuperação de desastres de menor custo para o Banco de Dados SQL do Azure. No entanto, a restauração a partir de backups com redundância geográfica pode resultar em perda de dados de até uma hora. Pode levar um tempo considerável, dependendo do tamanho de cada banco de dados.

Nota

Recupere aplicativos com o menor RPO e RTO possível usando replicação geográfica em vez de restauração geográfica.

Este tutorial explora os fluxos de trabalho de restauração e repatriação. Saiba como:

• Sincronize as informações de configuração do banco de dados e do pool elástico com o catálogo do locatário.
• Configure um ambiente de imagem espelhada em uma região de recuperação que inclua aplicativos, servidores e pools.
• Recupere bancos de dados de catálogo e locatário usando a restauração geográfica.
• Use a replicação geográfica para repatriar o catálogo de locatários e os bancos de dados de locatários alterados depois que a interrupção for resolvida.
• Atualize o catálogo à medida que cada banco de dados é restaurado (ou repatriado) para controlar o local atual da cópia ativa do banco de dados de cada locatário.
• Certifique-se de que o aplicativo e o banco de dados do locatário estejam sempre colocalizados na mesma região do Azure para reduzir a latência.

Antes de iniciar este tutorial, conclua os seguintes pré-requisitos:

• Implante o banco de dados SaaS de Wingtip Tickets por aplicativo de locatário. Para implantar em menos de cinco minutos, consulte Implantar e explorar o banco de dados SaaS de tíquetes Wingtip por aplicativo locatário.
• Instale o Azure PowerShell. Para obter detalhes, consulte Introdução ao Azure PowerShell.

Introdução ao padrão de recuperação de restauração geográfica

A recuperação de desastres (DR) é uma consideração importante para muitos aplicativos, seja por motivos de conformidade ou continuidade de negócios. Se houver uma interrupção prolongada do serviço, um plano de DR bem preparado pode minimizar a interrupção dos negócios. Um plano de DR baseado em restauração geográfica deve atingir várias metas:

• Reserve toda a capacidade necessária na região de recuperação escolhida o mais rápido possível para garantir que ela esteja disponível para restaurar bancos de dados de locatário.
• Estabeleça um ambiente de recuperação de imagem espelhada que reflita a configuração original do pool e do banco de dados.
• Permita o cancelamento do processo de restauração no meio do voo se a região original voltar a ficar online.
• Habilite o provisionamento de locatários rapidamente para que a integração de novos locatários possa ser reiniciada o mais rápido possível.
• Seja otimizado para restaurar locatários em ordem de prioridade.
• Seja otimizado para colocar os inquilinos online o mais rápido possível, fazendo etapas em paralelo onde for prático.
• Seja resiliente a falhas, reinicializável e idempotente.
• Repatriar bancos de dados para sua região original com impacto mínimo para os locatários quando a interrupção for resolvida.

Nota

O aplicativo é recuperado na região emparelhada da região na qual o aplicativo é implantado. Para obter mais informações, consulte Regiões emparelhadas do Azure.

Este tutorial usa recursos do Banco de Dados SQL do Azure e da plataforma Azure para enfrentar esses desafios:

• Modelos do Azure Resource Manager, para reservar toda a capacidade necessária o mais rápido possível. Os modelos do Azure Resource Manager são usados para provisionar uma imagem espelhada dos servidores originais e pools elásticos na região de recuperação. Um servidor e um pool separados também são criados para provisionar novos locatários.
• EDCL (Elastic Database Client Library ), para criar e manter um catálogo de banco de dados de locatário. O catálogo estendido inclui informações de configuração de pool e banco de dados atualizadas periodicamente.
• Recursos de recuperação de gerenciamento de estilhaços do EDCL, para manter as entradas de local do banco de dados no catálogo durante a recuperação e a repatriação.
• Restauração geográfica, para recuperar os bancos de dados de catálogo e locatário de backups com redundância geográfica mantidos automaticamente.
• As operações de restauração assíncronas, enviadas em ordem de prioridade de locatário, são enfileiradas para cada pool pelo sistema e processadas em lotes para que o pool não fique sobrecarregado. Estas operações podem ser canceladas antes ou durante a execução, se necessário.
• Replicação geográfica, para repatriar bancos de dados para a região original após a interrupção. Não há perda de dados e impacto mínimo no locatário quando você usa a replicação geográfica.
• Aliases DNS do SQL Server, para permitir que o processo de sincronização do catálogo se conecte ao catálogo ativo, independentemente de seu local.

Obtenha os scripts de recuperação de desastres

Os scripts DR usados neste tutorial estão disponíveis no banco de dados SaaS de tíquetes Wingtip por repositório GitHub de locatário. Confira as orientações gerais para conhecer as etapas para baixar e desbloquear os scripts de gerenciamento de Wingtip Tickets.

Importante

Como todos os scripts de gerenciamento de Wingtip Tickets, os scripts DR são de qualidade de amostra e não devem ser usados na produção.

Rever o estado de funcionamento da aplicação

Antes de iniciar o processo de recuperação, revise o estado normal de integridade do aplicativo.

1. No navegador da Web, abra o hub de eventos Wingtip Tickets (http://events.wingtip-dpt.<user.trafficmanager.net, substitua <user>> pelo valor de usuário da sua implantação).

   Role até a parte inferior da página e observe o nome e o local do servidor de catálogo no rodapé. O local é a região na qual você implantou o aplicativo.

   Gorjeta

   Passe o mouse sobre o local para ampliar a tela.

   

2. Selecione o locatário da Sala de Concertos Contoso e abra a página do evento.

   No rodapé, observe o nome do servidor do locatário. O local é o mesmo que o local do servidor de catálogo.

   

3. No portal do Azure, revise e abra o grupo de recursos no qual você implantou o aplicativo.

   Observe os recursos e a região na qual os componentes do serviço de aplicativo e o Banco de dados SQL são implantados.

Sincronizar a configuração do locatário no catálogo

Nesta tarefa, você inicia um processo para sincronizar a configuração dos servidores, pools elásticos e bancos de dados no catálogo do locatário. Essas informações são usadas posteriormente para configurar um ambiente de imagem espelhada na região de recuperação.

Importante

Para simplificar, o processo de sincronização e outros processos de recuperação e repatriação de longa duração são implementados nesses exemplos como trabalhos ou sessões locais do PowerShell que são executados sob o login do usuário cliente. Os tokens de autenticação emitidos quando você faz login expiram após várias horas e os trabalhos falharão. Em um cenário de produção, os processos de longa execução devem ser implementados como serviços confiáveis do Azure de algum tipo, executados sob uma entidade de serviço. Consulte Usar o Azure PowerShell para criar uma entidade de serviço com um certificado.

1. No ISE do PowerShell, abra o arquivo ...\Learning Modules\UserConfig.psm1. Substitua <resourcegroup> e nas linhas 10 e <user> 11 pelo valor usado quando você implantou o aplicativo. Guarde o ficheiro.

2. No ISE do PowerShell, abra o script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1.

   Neste tutorial, você executa cada um dos cenários neste script do PowerShell, portanto, mantenha esse arquivo aberto.

3. Defina o seguinte:

   $DemoScenario = 1: Inicie um trabalho em segundo plano que sincroniza as informações de configuração do servidor locatário e do pool no catálogo.

4. Para executar o script de sincronização, selecione F5.

   Essas informações são usadas posteriormente para garantir que a recuperação crie uma imagem espelhada dos servidores, pools e bancos de dados na região de recuperação.

   

Deixe a janela do PowerShell em execução em segundo plano e continue com o restante deste tutorial.

Nota

O processo de sincronização se conecta ao catálogo por meio de um alias DNS. O alias é modificado durante a restauração e repatriação para apontar para o catálogo ativo. O processo de sincronização mantém o catálogo atualizado com quaisquer alterações de configuração de banco de dados ou pool feitas na região de recuperação. Durante o repatriamento, estas alterações são aplicadas aos recursos equivalentes na região de origem.

Visão geral do processo de recuperação de restauração geográfica

O processo de recuperação de restauração geográfica implanta o aplicativo e restaura bancos de dados de backups para a região de recuperação.

O processo de recuperação faz o seguinte:

1. Desabilita o ponto de extremidade do Gerenciador de Tráfego do Azure para o aplicativo Web na região original. A desativação do ponto de extremidade impede que os usuários se conectem ao aplicativo em um estado inválido caso a região original fique online durante a recuperação.

2. Provisiona um servidor de catálogo de recuperação na região de recuperação, restaura geograficamente o banco de dados de catálogo e atualiza o alias activecatalog para apontar para o servidor de catálogo restaurado. Alterar o alias do catálogo garante que o processo de sincronização do catálogo sempre seja sincronizado com o catálogo ativo.

3. Marca todos os locatários existentes no catálogo de recuperação como offline para impedir o acesso aos bancos de dados de locatários antes que eles sejam restaurados.

4. Provisiona uma instância do aplicativo na região de recuperação e a configura para usar o catálogo restaurado nessa região. Para manter a latência ao mínimo, o aplicativo de exemplo foi projetado para sempre se conectar a um banco de dados de locatário na mesma região.

5. Provisiona um servidor e um pool elástico nos quais novos locatários são provisionados. A criação desses recursos garante que o provisionamento de novos locatários não interfira na recuperação de locatários existentes.

6. Atualiza o novo alias de locatário para apontar para o servidor para novos bancos de dados de locatários na região de recuperação. A alteração desse alias garante que os bancos de dados de quaisquer novos locatários sejam provisionados na região de recuperação.

7. Provisiona servidores e pools elásticos na região de recuperação para restaurar bancos de dados de locatário. Esses servidores e pools são uma imagem espelhada da configuração na região original. O provisionamento antecipado de pools reserva a capacidade necessária para restaurar todos os bancos de dados.

   Uma interrupção em uma região pode colocar uma pressão significativa sobre os recursos disponíveis na região emparelhada. Se você depende da restauração geográfica para DR, recomenda-se reservar recursos rapidamente. Considere a replicação geográfica se for crítico que um aplicativo seja recuperado em uma região específica.

8. Habilita o ponto de extremidade do Gerenciador de Tráfego para o aplicativo Web na região de recuperação. A habilitação desse ponto de extremidade permite que o aplicativo provisione novos locatários. Nesta fase, os inquilinos existentes ainda estão offline.

9. Envia lotes de solicitações para restaurar bancos de dados em ordem de prioridade.

   • Os lotes são organizados para que os bancos de dados sejam restaurados em paralelo em todos os pools.

   • As solicitações de restauração são enviadas de forma assíncrona para que sejam enviadas rapidamente e enfileiradas para execução em cada pool.

   • Como as solicitações de restauração são processadas em paralelo em todos os pools, é melhor distribuir locatários importantes em muitos pools.

10. Monitora o serviço para determinar quando os bancos de dados são restaurados. Depois que um banco de dados de locatário é restaurado, ele é marcado online no catálogo e uma soma de versão de linha para o banco de dados de locatário é registrada.

    • Os bancos de dados de locatários podem ser acessados pelo aplicativo assim que forem marcados online no catálogo.

    • Uma soma de valores rowversion no banco de dados do locatário é armazenada no catálogo. Esta soma funciona como uma impressão digital que permite ao processo de repatriação determinar se a base de dados foi atualizada na região de recuperação.

Executar o script de recuperação

Importante

Este tutorial restaura bancos de dados de backups com redundância geográfica. Embora esses backups normalmente estejam disponíveis em 10 minutos, pode levar até uma hora. O script é pausado até que estejam disponíveis.

Imagine que há uma interrupção na região em que o aplicativo é implantado e execute o script de recuperação:

1. No ISE do PowerShell, no script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, defina o seguinte valor:

   $DemoScenario = 2: Recupere o aplicativo em uma região de recuperação restaurando a partir de backups com redundância geográfica.

2. Para executar o script, selecione F5.

   • O script é aberto em uma nova janela do PowerShell e, em seguida, inicia um conjunto de trabalhos do PowerShell que são executados em paralelo. Esses trabalhos restauram servidores, pools e bancos de dados para a região de recuperação.

   • A região de recuperação é a região emparelhada associada à região do Azure na qual você implantou o aplicativo. Para obter mais informações, consulte Regiões emparelhadas do Azure.

3. Monitore o status do processo de recuperação na janela do PowerShell.

   

Nota

Para explorar o código para os trabalhos de recuperação, revise os scripts do PowerShell na pasta ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\RecoveryJobs.

Revisar o estado do aplicativo durante a recuperação

Enquanto o ponto de extremidade do aplicativo está desativado no Gerenciador de Tráfego, o aplicativo não está disponível. O catálogo é restaurado e todos os locatários são marcados offline. O ponto de extremidade do aplicativo na região de recuperação é então habilitado e o aplicativo fica online novamente. Embora o aplicativo esteja disponível, os locatários aparecem offline no hub de eventos até que seus bancos de dados sejam restaurados. É importante projetar seu aplicativo para lidar com bancos de dados de locatários offline.

• Depois que o banco de dados de catálogo for recuperado, mas antes que os locatários estejam online novamente, atualize o hub de eventos Wingtip Tickets em seu navegador da Web.

  • No rodapé, observe que o nome do servidor de catálogo agora tem um sufixo -recovery e está localizado na região de recuperação.

  • Observe que os locatários que ainda não foram restaurados estão marcados como offline e não podem ser selecionados.

    

  • Se você abrir a página de eventos de um locatário diretamente enquanto o locatário estiver offline, a página exibirá uma notificação offline do locatário. Por exemplo, se a Sala de Concertos da Contoso estiver offline, tente abrir http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall>.

    

Provisionar um novo locatário na região de recuperação

Mesmo antes de os bancos de dados de locatários serem restaurados, você pode provisionar novos locatários na região de recuperação. Novos bancos de dados de locatários provisionados na região de recuperação são repatriados com os bancos de dados recuperados posteriormente.

1. No ISE do PowerShell, no script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, defina a seguinte propriedade:

   $DemoScenario = 3: provisionar um novo locatário na região de recuperação.

2. Para executar o script, selecione F5.

3. A página de eventos do Hawthorn Hall é aberta no navegador quando o provisionamento é concluído.

   Observe que o banco de dados Hawthorn Hall está localizado na região de recuperação.

   

4. No navegador, atualize a página do hub de eventos Wingtip Tickets para ver o Hawthorn Hall incluído.

   Se você provisionou o Hawthorn Hall sem esperar que os outros locatários restaurem, outros locatários ainda podem estar offline.

Rever o estado recuperado do pedido

Quando o processo de recuperação termina, o aplicativo e todos os locatários estão totalmente funcionais na região de recuperação.

1. Depois que a exibição na janela do console do PowerShell indicar que todos os locatários foram recuperados, atualize o hub de eventos.

   Todos os inquilinos aparecem online, incluindo o novo inquilino, Hawthorn Hall.

   

2. Clique em Contoso Concert Hall e abra sua página de eventos.

   No rodapé, observe que o banco de dados está localizado no servidor de recuperação localizado na região de recuperação.

   

3. No portal do Azure, abra a lista de grupos de recursos.

   Observe o grupo de recursos que você implantou, mais o grupo de recursos de recuperação, com o sufixo -recovery. O grupo de recursos de recuperação contém todos os recursos criados durante o processo de recuperação, além de novos recursos criados durante a interrupção.

4. Abra o grupo de recursos de recuperação e observe os seguintes itens:

   • As versões de recuperação dos servidores catalog e tenants1, com o sufixo -recovery. Os bancos de dados de catálogo e locatário restaurados nesses servidores têm os nomes usados na região original.

   • O servidor SQL tenants2-dpt-user-recovery<>. Esse servidor é usado para provisionar novos locatários durante a interrupção.

   • O serviço de aplicativo chamado events-wingtip-dpt-recoveryregion-user<><>, que é a instância de recuperação do aplicativo de eventos.

     

5. Abra o servidor SQL tenants2-dpt-user-recovery<>. Observe que ele contém o banco de dados hawthornhall e o pool elástico Pool1. O banco de dados hawthornhall é configurado como um banco de dados elástico no pool elástico Pool1.

Alterar os dados do inquilino

Nesta tarefa, você atualiza um dos bancos de dados de locatários restaurados. O processo de repatriação copia bancos de dados restaurados que foram alterados para a região original.

1. No navegador, localize a lista de eventos da Sala de Concertos da Contoso, percorra os eventos e observe o último evento, Serious Strauss.

2. No ISE do PowerShell, no script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, defina o seguinte valor:

   $DemoScenario = 4: Excluir um evento de um locatário na região de recuperação.

3. Para executar o script, selecione F5.

4. Atualize a página de eventos da Sala de Concertos da Contoso (http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall>) e observe que o evento Serious Strauss está ausente.

Neste ponto do tutorial, você recuperou o aplicativo, que agora está sendo executado na região de recuperação. Você provisionou um novo locatário na região de recuperação e modificou os dados de um dos locatários restaurados.

Nota

Outros tutoriais no exemplo não foram projetados para serem executados com o aplicativo no estado de recuperação. Se você quiser explorar outros tutoriais, certifique-se de repatriar o aplicativo primeiro.

Visão geral do processo de repatriação

O processo de repatriação reverte o aplicativo e seus bancos de dados para sua região original depois que uma interrupção é resolvida.

O processo:

1. Interrompe qualquer atividade de restauração em andamento e cancela todas as solicitações de restauração de banco de dados pendentes ou em andamento.

2. Reativa nos bancos de dados de locatários da região original que não foram alterados desde a interrupção. Estas bases de dados incluem as que ainda não foram recuperadas e as recuperadas, mas não foram alteradas posteriormente. Os bancos de dados reativados são exatamente como acessados pela última vez por seus locatários.

3. Provisiona uma imagem espelhada do servidor e do pool elástico do novo locatário na região original. Após a conclusão dessa ação, o novo alias de locatário é atualizado para apontar para este servidor. A atualização do alias faz com que a integração de novos locatários ocorra na região original em vez da região de recuperação.

4. Usa a replicação geográfica para mover o catálogo da região de recuperação para a região original.

5. Atualiza a configuração do pool na região original para que seja consistente com as alterações feitas na região de recuperação durante a interrupção.

6. Cria os servidores e pools necessários para hospedar quaisquer novos bancos de dados criados durante a interrupção.

7. Usa replicação geográfica para repatriar bancos de dados de locatários restaurados que foram atualizados após a restauração e todos os novos bancos de dados de locatários provisionados durante a interrupção.

8. Limpa os recursos criados na região de recuperação durante o processo de restauração.

Para limitar o número de bancos de dados de inquilinos que precisam ser repatriados, as etapas 1 a 3 são feitas prontamente.

A etapa 4 só será concluída se o catálogo na região de recuperação tiver sido modificado durante a interrupção. O catálogo será atualizado se novos locatários forem criados ou se qualquer configuração de banco de dados ou pool for alterada na região de recuperação.

É importante que a etapa 7 cause o mínimo de interrupção para os locatários e nenhum dado seja perdido. Para atingir este objetivo, o processo utiliza a replicação geográfica.

Antes de cada banco de dados ser replicado geograficamente, o banco de dados correspondente na região original é excluído. O banco de dados na região de recuperação é replicado geograficamente, criando uma réplica secundária na região original. Após a conclusão da replicação, o locatário é marcado offline no catálogo, o que interrompe todas as conexões com o banco de dados na região de recuperação. O banco de dados é então submetido a failover, fazendo com que quaisquer transações pendentes sejam processadas no secundário para que nenhum dado seja perdido.

No failover, as funções do banco de dados são invertidas. O secundário na região original torna-se o banco de dados primário de leitura-gravação e o banco de dados na região de recuperação torna-se um secundário somente leitura. A entrada do locatário no catálogo é atualizada para fazer referência ao banco de dados na região original e o locatário é marcado online. Neste momento, o repatriamento da base de dados está concluído.

Os aplicativos devem ser escritos com lógica de repetição para garantir que eles se reconectem automaticamente quando as conexões são interrompidas. Quando eles usam o catálogo para intermediar a reconexão, eles se conectam ao banco de dados repatriado na região original. Embora a breve desconexão muitas vezes não seja notada, você pode optar por repatriar bancos de dados fora do horário comercial.

Depois que um banco de dados é repatriado, o banco de dados secundário na região de recuperação pode ser excluído. Em seguida, o banco de dados na região original depende novamente da restauração geográfica para proteção contra DR.

Na etapa 8, os recursos na região de recuperação, incluindo os servidores e pools de recuperação, são excluídos.

Executar o script de repatriação

Vamos imaginar que a interrupção seja resolvida e execute o script de repatriação.

Se você seguiu o tutorial, o script reativa imediatamente o Fabrikam Jazz Club e o Dogwood Dojo na região original porque eles permanecem inalterados. Em seguida, repatria o novo inquilino, Hawthorn Hall, e Contoso Concert Hall porque foi modificado. O roteiro também repatria o catálogo, que foi atualizado quando Hawthorn Hall foi provisionado.

1. No ISE do PowerShell, no script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, verifique se o processo de Sincronização de Catálogo ainda está em execução em sua instância do PowerShell. Se necessário, reinicie-o definindo:

   $DemoScenario = 1: Comece a sincronizar as informações de configuração do servidor do locatário, do pool e do banco de dados no catálogo.

   Para executar o script, selecione F5.

2. Em seguida, para iniciar o processo de repatriação, defina:

   $DemoScenario = 5: Repatrie o aplicativo para sua região original.

   Para executar o script de recuperação em uma nova janela do PowerShell, selecione F5. A repatriação leva vários minutos e pode ser monitorada na janela do PowerShell.

3. Enquanto o script estiver em execução, atualize a página do hub de eventos (http://events.wingtip-dpt.<user.trafficmanager.net>).

   Repare que todos os inquilinos estão online e acessíveis ao longo deste processo.

4. Selecione o Fabrikam Jazz Club para abri-lo. Se você não modificou esse locatário, observe no rodapé que o servidor já foi revertido para o servidor original.

5. Abra ou atualize a página de eventos da Sala de Concertos da Contoso. Observe no rodapé que, inicialmente, o banco de dados ainda está no servidor -recovery.

6. Atualize a página de eventos da Sala de Concertos da Contoso quando o processo de repatriação for concluído e observe que o banco de dados agora está na sua região original.

7. Atualize o hub de eventos novamente e abra o Hawthorn Hall. Observe que seu banco de dados também está localizado na região original.

Limpar os recursos da região de recuperação após o repatriamento

Após a conclusão da repatriação, é seguro excluir os recursos na região de recuperação.

Importante

Exclua esses recursos imediatamente para interromper todo o faturamento por eles.

O processo de restauração cria todos os recursos de recuperação em um grupo de recursos de recuperação. O processo de limpeza exclui esse grupo de recursos e remove todas as referências aos recursos do catálogo.

1. No ISE do PowerShell, no script ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, defina:

   $DemoScenario = 6: Excluir recursos obsoletos da região de recuperação.

2. Para executar o script, selecione F5.

Depois de limpar os scripts, o aplicativo está de volta onde começou. Neste ponto, você pode executar o script novamente ou experimentar outros tutoriais.

Projetando o aplicativo para garantir que o aplicativo e o banco de dados estejam colocalizados

O aplicativo foi projetado para sempre se conectar a partir de uma instância na mesma região do banco de dados do locatário. Esse design reduz a latência entre o aplicativo e o banco de dados. Essa otimização pressupõe que a interação entre aplicativos e bancos de dados seja mais chata do que a interação entre usuários.

Os bancos de dados de locatários podem estar espalhados pelas regiões de recuperação e originais por algum tempo durante a repatriação. Para cada banco de dados, o aplicativo procura a região na qual o banco de dados está localizado fazendo uma pesquisa de DNS no nome do servidor locatário. O nome do servidor é um alias. O nome do servidor com alias contém o nome da região. Se o aplicativo não estiver na mesma região do banco de dados, ele redirecionará para a instância na mesma região do servidor. O redirecionamento para a instância na mesma região do banco de dados minimiza a latência entre o aplicativo e o banco de dados.

Próximos passos

Neste tutorial, ficou a saber como:

• Use o catálogo do locatário para armazenar informações de configuração atualizadas periodicamente, o que permite que um ambiente de recuperação de imagem espelhada seja criado em outra região.
• Recupere bancos de dados na região de recuperação usando a restauração geográfica.
• Atualize o catálogo de locatários para refletir os locais do banco de dados de locatários restaurados.
• Use um alias DNS para permitir que um aplicativo se conecte ao catálogo do locatário sem reconfiguração.
• Use a replicação geográfica para repatriar bancos de dados recuperados para sua região original depois que uma interrupção for resolvida.

Experimente o tutorial Recuperação de desastres para um aplicativo SaaS multilocatário usando replicação geográfica de banco de dados para aprender a usar a replicação geográfica para reduzir drasticamente o tempo necessário para recuperar um aplicativo multilocatário de grande escala.

Recursos adicionais

Tutoriais adicionais que se baseiam no aplicativo SaaS Wingtip