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

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

Esta visão geral descreve as capacidades que Base de Dados do Azure para PostgreSQL prevê para a continuidade do negócio e recuperação de desastres. Saiba mais sobre opções para recuperar de eventos disruptivos que possam causar perda de dados ou fazer com que a sua base de dados e aplicação fiquem indisponíveis. Saiba o que fazer quando um utilizador ou erro de aplicação afeta a integridade dos dados, uma região do Azure tem uma paragem ou a sua aplicação requer manutenção.

Características que pode usar para proporcionar continuidade ao negócio

À medida que desenvolve o seu plano de continuidade de negócio, precisa de compreender o tempo máximo aceitável antes que a aplicação recupere totalmente após o evento disruptivo - este é o seu Objetivo de Tempo de Recuperação (RTO). Também precisa de compreender a quantidade máxima de atualizações de dados recentes (intervalo de tempo) que a aplicação pode tolerar a perda ao recuperar após o evento disruptivo - este é o seu Objetivo de Ponto de Recuperação (RPO).

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 a funcionalidade Geo-restauro , um novo servidor é criado usando os dados de backup que são replicados a partir 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 lidas, os registos de transações das primárias são assíncronos transmitidos para a réplica. Em caso de interrupção da base de dados primária devido a uma falha ao nível da zona ou a uma falha a nível da região, a falha na réplica fornece um RTO mais curto e uma redução da perda de dados.

Nota

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

Devido à natureza assíncronia da replicação utilizada para réplicas de leitura, não devem ser consideradas como uma solução de Alta Disponibilidade (HA), uma vez que os lags mais elevados podem significar rto e RPO mais elevados. Apenas para cargas de trabalho onde o lag permanece menor através dos tempos de pico e não-pico da carga de trabalho, as réplicas lidas podem funcionar como uma alternativa HA. Caso contrário, as réplicas lidas destinam-se a uma verdadeira escala de leitura para cargas de trabalho pesadas prontas e para cenários DR (Recuperação de Desastres).

A tabela a seguir compara RTO e RPO num cenário típico de carga de trabalho :

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 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
Geo-restauro a partir de backups geo-replicados Não suportado 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*

* O RTO e o RPO podem ser muito mais elevados em alguns casos, dependendo de vários fatores, incluindo a latência entre sites, a quantidade de dados a transmitir, e, importantemente, a base de dados primária escrever carga de trabalho.

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

Pode utilizar as cópias de segurança do serviço para recuperar um servidor de vários eventos disruptivos. Um utilizador pode acidentalmente eliminar alguns dados, deixar cair inadvertidamente uma tabela importante ou mesmo deixar cair uma base de dados inteira. Uma aplicação pode acidentalmente substituir bons dados com dados maus devido a um defeito de aplicação, e assim por diante.

Pode executar um restauro pontual para criar uma cópia do seu servidor num bom momento conhecido. 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 de os dados terem sido restaurados para o novo servidor, pode substituir o servidor original pelo servidor recentemente restaurado ou copiar os dados necessários do servidor restaurado para o servidor original.

Recomendamos que utilize o bloqueio de recursos Azure para evitar a eliminação acidental do seu servidor. Se eliminar acidentalmente o seu servidor, poderá restaurá-lo se a eliminação ocorrer nos últimos 5 dias. Para obter mais informações, consulte Restaurar um servidor Base de Dados do Azure para PostgreSQL caído.

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 paralisação, causa uma perturbação de negócio que pode durar apenas alguns minutos, mas pode durar horas.

Uma opção é esperar que o seu servidor volte a estar online quando a falha do data center terminar. Isto funciona para aplicações que podem dar ao luxo de ter o servidor offline por algum tempo, por exemplo, um ambiente de desenvolvimento. Quando um centro de dados tem uma paragem, não sabe quanto tempo a interrupção pode durar, por isso esta opção só funciona se não precisar do seu servidor durante algum tempo.

Georrestauro

A função de geo-restauro restaura o servidor utilizando cópias de segurança geo-redundantes. As cópias de segurança estão hospedadas na região emparelhada do seu servidor. Você pode restaurar destes backups para qualquer outra região. O geo-restauro cria um novo servidor com os dados das cópias de segurança. Saiba mais sobre o geo-restauro a partir do backup e restaurar o artigo conceitos.

Importante

O geo-restauro só é possível se forte o servidor com armazenamento de backup geo-redundante. Se pretender mudar de cópias de segurança locais redundantes para geo-redundantes para um servidor existente, deve descarregar utilizando pg_dump do seu servidor existente e restaurá-lo para um servidor recém-criado configurado com cópias de segurança geo-redundantes.

Réplicas de leitura transversal

Você pode usar réplicas de leitura de região cruzada para melhorar o seu plano de continuidade de negócios e recuperação de desastres. As réplicas de leitura são atualizadas assíncronea usando a tecnologia de replicação física do PostgreSQL, e podem atrasar a primária. Saiba mais sobre réplicas de leitura, regiões disponíveis e como falhar a partir do artigo de conceitos de réplicas lidos.

FAQ

Onde Base de Dados do Azure para PostgreSQL armazena os dados dos clientes?

Por padrão, Base de Dados do Azure para PostgreSQL não move nem armazena os dados dos clientes para fora da região em que está implantado. No entanto, os clientes podem optar opcionalmente por permitir backups geo-redundantes ou criar réplicas de leitura transversal para armazenar dados noutra região.

Passos seguintes