Recuperação de desastres geográficos no Banco de Dados do Azure para PostgreSQL - Servidor flexível
APLICA-SE A: 
Banco de Dados do Azure para PostgreSQL - Servidor Flexível
Se houver um desastre em toda a região, o Azure pode fornecer proteção contra desastres regionais ou de grande porte geográfico com recuperação de desastres usando outra região. Para obter mais informações sobre a arquitetura de recuperação de desastres do Azure, consulte Arquitetura de recuperação de desastres do Azure para Azure.
O servidor flexível do Banco de Dados do Azure para PostgreSQL fornece recursos que protegem os dados e reduzem o tempo de inatividade para seus bancos de dados de missão crítica durante eventos de tempo de inatividade planejados e não planejados. Criado com base na infraestrutura do Azure que oferece resiliência e disponibilidade robustas, o servidor flexível do Banco de Dados do Azure para PostgreSQL oferece recursos de continuidade de negócios que fornecem proteção contra falhas, atendem aos requisitos de tempo de recuperação e reduzem a exposição à perda de dados. Ao arquitetar seus aplicativos, você deve considerar a tolerância ao tempo de inatividade - o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e a exposição à perda de dados - o RPO (Recovery Point Objetive, objetivo de ponto de recuperação). Por exemplo, seu banco de dados crítico para os negócios requer um tempo de atividade mais rigoroso do que um banco de dados de teste.
Compare a replicação geográfica com o armazenamento de backup com redundância geográfica
Tanto a replicação geográfica com réplicas de leitura quanto o backup geográfico são soluções para recuperação de desastres geográficos. No entanto, eles diferem nos detalhes de suas ofertas. Para escolher a solução certa para o seu sistema, é importante entender e comparar suas características.
| Funcionalidade | Georreplicação | Geo-backup |
|---|---|---|
| Failover automático | No | Não |
| O usuário deve atualizar a cadeia de conexão após o failover | Não | Sim |
| Pode estar em região não emparelhada | Sim | No |
| Suporta escala de leitura | Sim | No |
| Pode ser configurado após a criação do servidor | Sim | No |
| Restaurar para um point-in-time específico | No | Não |
| Capacidade garantida | Sim | No |
Backup e restauração com redundância geográfica
O backup e a restauração com redundância geográfica permitem restaurar o servidor em uma região diferente em caso de desastre. Ele também fornece pelo menos 99,999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
O backup com redundância geográfica pode ser configurado somente no momento da criação do servidor. Quando o servidor é configurado com backup com redundância geográfica, os dados de backup e os logs de transações são copiados para a região emparelhada de forma assíncrona por meio da replicação de armazenamento.
Para obter mais informações sobre backup e restauração com redundância geográfica, consulte Backup e restauração com redundância geográfica.
Réplicas de leitura
Réplicas de leitura entre regiões podem ser implantadas para proteger seus bancos de dados contra falhas no nível da região. As réplicas de leitura são atualizadas de forma assíncrona usando o Banco de Dados do Azure para PostgreSQL, a tecnologia de replicação física do servidor flexível e podem atrasar a principal. As réplicas de leitura são suportadas em camadas de computação otimizadas para fins gerais e memória.
Para obter mais informações sobre recursos e considerações de réplica de leitura, consulte Ler réplicas.
Deteção, notificação e gerenciamento de interrupções
Se o servidor estiver configurado com backup com redundância geográfica, você poderá executar a restauração geográfica na região emparelhada. Um novo servidor é provisionado e recuperado para os últimos dados disponíveis que foram copiados para esta região.
Você também pode usar réplicas de leitura entre regiões. Em caso de falha de região, você pode executar a operação de recuperação de desastres promovendo sua réplica de leitura para ser um servidor autônomo que pode ser gravado em leitura. Espera-se que o RPO seja de até 5 minutos (perda de dados possível), exceto se houver falha regional grave, o RPO pode estar próximo do atraso de replicação no momento da falha.
Para obter mais informações sobre a redução e recuperação de tempo de inatividade não planejado após um desastre regional, consulte Mitigação de tempo de inatividade não planejado.