Visão geral da continuidade dos negócios com o Banco 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á prestes a ser desativado. É altamente recomendável atualizar para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível. Para obter mais informações sobre a migração para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível, veja O que está acontecendo com o Banco de Dados do Azure para PostgreSQL Servidor único?.

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

Recursos que podem ser utilizados para fornecer continuidade dos negócios

Na medida em que você desenvolve o plano de continuidade dos negócios, será necessário entender qual é o tempo máximo aceitável antes que o aplicativo recupere-se completamente após o evento interruptivo - esse é o RTO (Objetivo do Tempo de Recuperação). Além disso, será necessário entender a quantidade máxima de atualizações de dados recentes (intervalo de tempo) que o aplicativo poderá tolerar perder durante a recuperação após um evento interruptivo - esse é o RPO (Objetivo de Ponto de Recuperação).

O Banco de Dados do Azure para PostgreSQL fornece recursos para a continuidade dos negócios que incluem: backups com redundância geográfica com a capacidade de iniciar uma restauração geográfica, além da implantação de réplicas de leitura em uma região diferente. Cada um possui características diferentes para o 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 replicados a partir de outra região. O tempo geral para restaurar e recuperar depende do tamanho dos arquivos de banco de dados e da quantidade de logs a serem recuperados. O tempo geral 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 falha do banco de dados primário devido a uma falha de nível da zona ou de nível de região, efetuar failover com a réplica fornece um RTO mais curto e uma perda de dados reduzida.

Observação

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 HA (Alta Disponibilidade), uma vez que o atraso maior pode significar RTO e OPR maiores. Somente para cargas de trabalho nas quais o atraso permanece menor por meio do horário de pico e horário fora de 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 escala de leitura real para cargas de trabalho pesadas e para cenários de DR (Recuperação de Desastre).

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

Recurso Basic Uso Geral Otimizado para memória
Recuperação Pontual do backup Qualquer ponto de restauração dentro do período de retenção
RTO – Varia
RPO < 15 min		 Qualquer ponto de restauração dentro do período de retenção
RTO – Varia
RPO < 15 min		 Qualquer ponto de restauração dentro do período de retenção
RTO – Varia
RPO < 15 min
Restauração geográfica de backups replicados geograficamente Sem suporte RTO – Varia
RPO < 1 h		 RTO – Varia
RPO < 1 h
Réplicas de leitura RTO – Minutos*
RPO < 5 min*		 RTO – Minutos*
RPO < 5 min*		 RTO – Minutos*
RPO < 5 min*

*Em alguns casos, o RTO e o OPR podem ser muito maiores, dependendo de vários fatores, incluindo a 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 aplicativo ou usuário

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

Você pode executar uma restauração pontual para criar uma cópia do servidor em um ponto no tempo conhecido e ideal. Esse ponto no tempo deve estar dentro do período de retenção de backup que você configurou para o servidor. Depois que os dados forem restaurados para o novo servidor, você poderá substituir o servidor de origem pelo servidor restaurado recentemente, ou copiar os dados necessários do servidor restaurado para o servidor de origem.

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 o servidor, talvez consiga restaurá-lo se a exclusão tiver ocorrido nos últimos 5 dias. Para obter mais informações, confira Restaurar um servidor removido de Banco de Dados do Azure para PostgreSQL.

Recuperar de uma interrupção no data center do Azure

Embora seja raro, um data center do Azure pode ter uma interrupção. Quando uma interrupção ocorre, isso causa uma interrupção dos negócios, que pode durar alguns minutos ou horas.

Uma opção é aguardar até que o servidor retorne online quando a interrupção do data center terminar. Isso funciona para aplicativos que podem ter o servidor offline por algum período de tempo, por exemplo, um ambiente de desenvolvimento. Quando o data center tem uma interrupção, não é possível saber por quanto tempo a interrupção poderá durar, então, essa opção somente funcionará se você não precisar usar o servidor por algum tempo.

Restauração geográfica

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. É possível 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 de conceitos de backup e restauração.

Importante

A restauração geográfica somente será possível se o servidor foi provisionado com armazenamento de backup com redundância geográfica. Se você deseja alternar de backups redundantes localmente para redundantes geo-ativos para um servidor existente, você deve fazer um dump usando o pg_dump do seu servidor existente e restaurá-lo em um servidor recém-criado configurado com backups geo-redundantes.

Réplicas de leitura entre regiões

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

Perguntas frequentes

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

Por padrão, o Banco de Dados do Azure para PostgreSQL não move nem armazena dados do cliente fora da região na qual está implantado. No entanto, os clientes podem 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óximas etapas