Descrição geral da continuidade do negócio com a Base de Dados do Azure para PostgreSQL – Servidor Único

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Único

Importante

O Banco de Dados do Azure para PostgreSQL - Servidor Único está no caminho da desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único PostgreSQL?.

Esta visão geral descreve os recursos que o Banco de Dados do Azure para PostgreSQL fornece para continuidade de negócios e recuperação de desastres. Saiba mais sobre as opções de recuperação de eventos com interrupções que podem causar perda de dados ou fazer com que seu banco de dados e aplicativo fiquem indisponíveis. Saiba o que fazer quando um erro de usuário ou aplicativo afeta a integridade dos dados, uma região do Azure tem uma interrupção ou seu aplicativo requer manutenção.

Recursos que você pode usar para fornecer continuidade de negócios

Ao desenvolver seu plano de continuidade de negócios, você precisa entender o tempo máximo aceitável antes que o aplicativo se recupere totalmente após o evento de interrupção - este é o seu RTO (Recovery Time Objetive, objetivo de tempo de recuperação). Você também precisa entender a quantidade máxima de atualizações de dados recentes (intervalo de tempo) que o aplicativo pode tolerar perder ao se recuperar após o evento de interrupção - este é o seu RPO (Recovery Point Objetive, objetivo de ponto de recuperação).

A Base de Dados do Azure para PostgreSQL proporciona funcionalidades de continuidade empresarial que incluem cópias de segurança georredundantes, com a capacidade de iniciar o georrestauro, e a implementação de réplicas de leitura numa região diferente. Cada funcionalidade tem características diferentes quanto ao tempo de recuperação e à potencial perda de dados. Com o recurso de restauração geográfica, um novo servidor é criado usando os dados de backup que são replicados de outra região. O tempo total que demora a restaurar e recuperar depende do tamanho da base de dados e da quantidade de registos a recuperar. O tempo total para estabelecer o servidor varia de alguns minutos a algumas horas. Com réplicas de leitura, os logs de transações do primário são transmitidos de forma assíncrona para a réplica. No caso de uma interrupção do banco de dados primário devido a uma falha no nível da zona ou da região, o failover para a réplica fornece um RTO mais curto e uma perda de dados reduzida.

Nota

O atraso entre o primário e a réplica depende da latência entre os sites, da quantidade de dados a serem transmitidos e, mais importante, da carga de trabalho de gravação do servidor primário. Cargas de trabalho de gravação pesadas podem gerar um atraso significativo.

Devido à natureza assíncrona da replicação usada para réplicas de leitura, elas não devem ser consideradas como uma solução de alta disponibilidade (HA), uma vez que os atrasos mais altos podem significar RTO e RPO mais altos. Somente para cargas de trabalho em que o atraso permanece menor durante os horários de pico e não pico da carga de trabalho, as réplicas de leitura podem atuar como uma alternativa de HA. Caso contrário, as réplicas de leitura destinam-se a uma verdadeira escala de leitura para cargas de trabalho pesadas prontas e para cenários de DR (recuperação de desastres).

A tabela a seguir compara RTO e RPO em um cenário de carga de trabalho típica:

Capacidade Básica Fins Gerais Com otimização de memória
Restauro para um Ponto Anterior no Tempo a partir de cópia de segurança Qualquer ponto de restauração dentro do período de retenção
RTO - Varia
RPO < 15 minutos		 Qualquer ponto de restauração dentro do período de retenção
RTO - Varia
RPO < 15 minutos		 Qualquer ponto de restauração dentro do período de retenção
RTO - Varia
RPO < 15 minutos
Restauração geográfica a partir de backups replicados geograficamente Não suportado RTO - Varia
RPO < 1 h		 RTO - Varia
RPO < 1 h
Réplicas de leitura RTO - Atas*
RPO < 5 min*		 RTO - Atas*
RPO < 5 min*		 RTO - Atas*
RPO < 5 min*

* RTO e RPO podem ser muito maiores em alguns casos, dependendo de vários fatores, incluindo latência entre sites, a quantidade de dados a serem transmitidos e, principalmente, a carga de trabalho de gravação do banco de dados primário.

Recuperar um servidor após um erro de utilizador ou aplicação

Você pode usar os backups do serviço para recuperar um servidor de vários eventos de interrupção. Um usuário pode excluir acidentalmente alguns dados, inadvertidamente soltar uma tabela importante ou até mesmo soltar um banco de dados inteiro. Um aplicativo pode substituir acidentalmente dados bons por dados incorretos devido a um defeito do aplicativo e assim por diante.

Você pode executar uma restauração point-in-time para criar uma cópia do seu servidor para um bom ponto no tempo. Este ponto anterior no tempo tem de estar dentro do período de retenção da cópia de segurança que configurou para o seu servidor. Depois que os dados forem restaurados no novo servidor, você poderá substituir o servidor original pelo servidor recém-restaurado ou copiar os dados necessários do servidor restaurado para o servidor original.

Recomendamos que você use o bloqueio de recursos do Azure para ajudar a evitar a exclusão acidental do seu servidor. Se você excluiu acidentalmente seu servidor, poderá restaurá-lo se a exclusão tiver acontecido nos últimos 5 dias. Para obter mais informações, consulte Restaurar um banco de dados do Azure descartado para o servidor PostgreSQL.

Recuperar a partir de uma falha do datacenter do Azure

Embora seja raro, um centro de dados do Azure pode ficar indisponível. Quando ocorre uma interrupção, ela causa uma interrupção nos negócios que pode durar apenas alguns minutos, mas pode durar horas.

Uma opção é esperar que o servidor volte a ficar online quando a interrupção do data center terminar. Isso funciona para aplicativos que podem se dar ao luxo de ter o servidor offline por algum período de tempo, por exemplo, um ambiente de desenvolvimento. Quando um data center tem uma interrupção, você não sabe quanto tempo a interrupção pode durar, então essa opção só funciona se você não precisar do servidor por um tempo.

Restauro geográfico

O recurso de restauração geográfica restaura o servidor usando backups com redundância geográfica. Os backups são hospedados na região emparelhada do servidor. Você pode restaurar a partir desses backups para qualquer outra região. A restauração geográfica cria um novo servidor com os dados dos backups. Saiba mais sobre a restauração geográfica no artigo Conceitos de backup e restauração.

Importante

A restauração geográfica só é possível se você provisionou o servidor com armazenamento de backup com redundância geográfica. Se desejar alternar de backups localmente redundantes para backups com redundância geográfica para um servidor existente, você deverá fazer um dump usando pg_dump do servidor existente e restaurá-lo para um servidor recém-criado configurado com backups com redundância geográfica.

Réplicas de leitura entre regiões

Você pode usar réplicas de leitura entre regiões para aprimorar a continuidade de negócios e o planejamento de recuperação de desastres. As réplicas de leitura são atualizadas de forma assíncrona usando a tecnologia de replicação física do PostgreSQL e podem atrasar a principal. Saiba mais sobre réplicas de leitura, regiões disponíveis e como fazer failover no artigo de conceitos de réplicas de leitura.

FAQ

Onde o Banco de Dados do Azure para PostgreSQL armazena dados de clientes?

Por padrão, o Banco de Dados do Azure para PostgreSQL não move nem armazena dados do cliente para fora da região em que está implantado. No entanto, os clientes podem, opcionalmente, optar por habilitar backups com redundância geográfica ou criar réplica de leitura entre regiões para armazenar dados em outra região.

Próximos passos