Proteja os seus dados através de cópias de segurança

Selecione uma versão da documentação:

Esta página descreve a arquitetura de referência de disponibilidade padrão do AlloyDB Omni, que oferece proteção de dados através de cópias de segurança.

Exemplos de utilização

Esta arquitetura de referência suporta os seguintes cenários:

  • Tem bases de dados que podem tolerar algum tempo de inatividade e perda de dados desde a última cópia de segurança.
  • Quer proteger a sua base de dados do AlloyDB Omni contra erros do utilizador, danos ou falhas físicas ao nível da base de dados (em contrário das imagens instantâneas do servidor ou da VM).
  • Quer poder recuperar a sua base de dados no local ou remotamente, possivelmente até um ponto específico no tempo.

Como funciona a arquitetura de referência

A arquitetura de referência de disponibilidade padrão abrange a cópia de segurança e a recuperação das suas bases de dados AlloyDB Omni, quer estejam a ser executadas como uma instância autónoma num servidor anfitrião, como uma máquina virtual (instalar o AlloyDB Omni) ou num cluster do Kubernetes (instalar o AlloyDB Omni no Kubernetes).

Embora a disponibilidade padrão seja uma implementação básica e minimize o hardware ou os serviços adicionais necessários, o objetivo de tempo de recuperação (RTO) aumenta à medida que a base de dados aumenta. Quanto mais dados houver para fazer uma cópia de segurança, mais tempo demora a restaurar e recuperar a base de dados. A perda de dados depende do tipo de cópia de segurança. Se apenas forem feitas cópias de segurança dos ficheiros de dados periodicamente, quando fizer o restauro, vai perder os dados desde a última cópia de segurança.

Reduzir o ORT

A funcionalidade de arquivo contínuo do PostgreSQL permite-lhe alcançar um objetivo de ponto de recuperação (RPO) baixo e ativar a recuperação num determinado momento através de cópias de segurança. Este processo envolve arquivar ficheiros de registo de escrita antecipada (WAL) e transmitir dados WAL, potencialmente para uma localização de armazenamento remoto.

Se os ficheiros WAL forem arquivados apenas quando estiverem cheios ou a intervalos específicos, uma perda completa da base de dados (incluindo os ficheiros WAL atuais) restringe a recuperação ao último ficheiro WAL arquivado, o que significa que o objetivo do ponto de recuperação (RPO) tem de considerar a potencial perda de dados. Por outro lado, a transferência de dados WAL contínua maximiza a ausência de perda de dados.

Quando faz cópias de segurança contínuas, pode fazer a recuperação para um ponto específico no tempo. A recuperação num ponto específico no tempo permite o restauro para um estado anterior a um erro, como a eliminação acidental de tabelas ou atualizações em lote incorretas. No entanto, este método de recuperação afeta o objetivo de ponto de recuperação (OPR), a menos que seja usada uma base de dados auxiliar temporária.

Estratégias de cópia de segurança

Pode configurar as cópias de segurança ao nível do Postgres do AlloyDB Omni para serem armazenadas em armazenamento local ou remoto. Embora o armazenamento local possa ser mais rápido para fazer uma cópia de segurança e recuperar, o armazenamento remoto é normalmente mais robusto para lidar com falhas quando ocorre uma falha num anfitrião ou numa VM inteiros.

Cópias de segurança em sistemas não Kubernetes

Para implementações não Kubernetes, pode agendar cópias de segurança através das seguintes ferramentas do PostgreSQL:

Em alternativa, para pequenas bases de dados, pode optar por fazer uma cópia de segurança lógica da base de dados (usando pg_dump para uma única base de dados ou pg_dumpall para todo o cluster). Pode restaurar através do comando pg_restore.

Cópias de segurança no Kubernetes com o operador AlloyDB Omni

Para o AlloyDB Omni implementado num cluster do Kubernetes, pode configurar cópias de segurança contínuas através de um plano de cópia de segurança para cada cluster de base de dados. Para mais informações, consulte o artigo Fazer uma cópia de segurança e restaurar no Kubernetes.

Pode armazenar cópias de segurança do AlloyDB Omni localmente ou remotamente no Cloud Storage, incluindo opções fornecidas por qualquer fornecedor de nuvem. Para mais informações, consulte a Figura 1, que mostra potenciais destinos de cópia de segurança.

AlloyDB Omni com opções de cópia de segurança

Figura 1. AlloyDB Omni com opções de cópia de segurança.

As cópias de segurança podem ser feitas em opções de armazenamento local ou remoto. Normalmente, as cópias de segurança locais são mais rápidas porque dependem apenas do débito de E/S, enquanto as cópias de segurança remotas têm, geralmente, uma latência mais elevada e uma largura de banda da rede inferior. No entanto, as cópias de segurança remotas oferecem uma proteção ideal, incluindo falhas zonais.

Também pode dividir as cópias de segurança locais em armazenamento local ou partilhado. Embora as opções de armazenamento local sejam afetadas pela falta de opções de recuperação de desastres quando um anfitrião da base de dados falha, o armazenamento partilhado permite que esse armazenamento seja realocado para outro servidor e, em seguida, usado para recuperação. Isto significa que o armazenamento partilhado oferece potencialmente um RTO mais rápido.

Para implementações de armazenamento local e partilhado, os seguintes tipos de cópias de segurança podem ser agendados ou feitos manualmente a pedido:

  • Cópias de segurança completas: cópias de segurança completas de todos os ficheiros de base de dados necessários para a recuperação de dados.
  • Cópias de segurança diferenciais: cópias de segurança apenas das alterações aos ficheiros desde a última cópia de segurança completa.
  • Cópias de segurança incrementais: cópias de segurança apenas das alterações aos ficheiros desde a última cópia de segurança de qualquer tipo.

Recuperação pontual

As cópias de segurança contínuas dos ficheiros de registo de escrita antecipada (WAL) do PostgreSQL suportam a recuperação num determinado momento. Se, após um evento de falha, os ficheiros WAL estiverem intactos e utilizáveis, pode usar estes ficheiros para fazer a recuperação sem perda de dados.

Para controlar a gravação dos ficheiros WAL, pode configurar os seguintes parâmetros:

Parâmetro Descrição

wal_writer_delay

Especifica a frequência com que o escritor WAL descarrega o WAL para o disco, a menos que a gravação seja ativada mais cedo por uma transação que seja confirmada de forma assíncrona. O valor predefinido é 200 ms. Aumentar este valor reduz a frequência de escritas, mas pode aumentar a quantidade de dados perdidos se o servidor falhar.

wal_writer_flush_after

Especifica a quantidade de dados WAL que podem acumular-se antes de o escritor WAL forçar uma descarga para o disco. O valor predefinido é 1 MB. Se for definido como zero, os dados WAL são sempre descarregados imediatamente para o disco.

synchronous_commit

Especifica se a confirmação devolve uma resposta ao utilizador antes de os dados WAL serem descarregados para o disco. A predefinição é on, o que garante que a transação é duradoura. Por outras palavras, a confirmação foi escrita no disco antes de devolver um código de êxito ao utilizador. Se estiver definido como off, existem até três tentativas wal_writer_delay antes de a transação ser escrita no disco.

Monitorização da utilização de WAL

Pode usar os seguintes métodos para observar a utilização do WAL:

Método de observação Descrição

pg_stat_wal

Esta vista padrão tem as colunas wal_write e wal_sync, que armazenam as contagens do número de escritas e sincronizações de WAL. Quando o parâmetro de configuração track_wal_io_timing está ativado, o wal_write_time e o wal_sync_time também são armazenados. Os instantâneos regulares desta vista podem ajudar a apresentar a atividade de gravação e sincronização do WAL ao longo do tempo.
pg_current_wal_lsn() Esta função devolve a posição do número de sequência de registo (LSN) atual, que, quando associada a uma data/hora e recolhida como capturas de ecrã ao longo do tempo, pode fornecer os bytes/segundo de WAL gerados através da função pg_wal_lsn_diff(lsn1, lsn2). Esta função é uma métrica útil para compreender a taxa de transação e o desempenho dos ficheiros WAL.

Streaming de dados WAL para uma localização remota

Quando usa o Barman, os dados WAL também podem ser configurados para streaming em tempo real para uma localização remota para garantir que existe pouca ou nenhuma perda de dados na recuperação. Apesar da transmissão em tempo real, existe uma pequena probabilidade de perder transações comprometidas, uma vez que as gravações de streaming no servidor barman remoto são assíncronas por predefinição. No entanto, é possível configurar o streaming WAL através do modo síncrono que armazena o WAL e envia uma resposta de estado de volta para a base de dados de origem. Tenha em atenção que esta abordagem pode atrasar as transações se tiverem de esperar que esta gravação seja concluída antes de continuar.

Agendamentos de cópias de segurança

Na maioria dos ambientes, as cópias de segurança são normalmente agendadas semanalmente. Segue-se um horário semanal típico de cópias de segurança:

  • Domingo: full backup
  • Segunda e terça: cópia de segurança
  • Quarta-feira: cópia de segurança diferencial
  • Quinta-feira e sexta-feira: cópia de segurança incremental
  • Sábado: cópia de segurança diferencial

Com esta programação típica, um período de recuperação contínuo de uma semana requer espaço de armazenamento para até três cópias de segurança completas, além das cópias de segurança incrementais ou diferenciais necessárias. Esta abordagem suporta a recuperação de uma falha que ocorra durante a cópia de segurança completa no domingo, e a recuperação da base de dados tem de ser alargada ao domingo anterior ao início da cópia de segurança.

Para minimizar o RTO com um potencial de RPO mais elevado, podem ser usadas bases de dados adicionais no modo de recuperação contínua. Isto envolve a reprodução de cópias de segurança e a atualização contínua do ambiente secundário através da arquivo e da reprodução de novos ficheiros WAL. O RPO real, que reflete a potencial perda de dados, depende da frequência das transações, do tamanho do ficheiro WAL e da utilização do streaming WAL.

Restaurar em não Kubernetes

Para implementações não Kubernetes, a restauração de uma base de dados do AlloyDB Omni envolve parar o contentor Docker e, em seguida, restaurar os dados ou restaurar os dados para uma localização diferente e iniciar uma nova instância do Docker com esses dados restaurados. Assim que o contentor for reiniciado, a base de dados fica acessível com os dados restaurados.

Para mais informações sobre as opções de recuperação, consulte os artigos Restaure um cluster do AlloyDB Omni com o pgBackRest e Restaure um cluster do AlloyDB Omni com o Barman.

Restaurar no Kubernetes com o operador

Para restaurar uma base de dados no Kubernetes, o operador oferece a recuperação no mesmo cluster e espaço de nomes do Kubernetes, a partir de uma cópia de segurança com nome ou de um clone a partir de um ponto no tempo (PIT). Para clonar uma base de dados para um cluster do Kubernetes diferente, use o pgBackRest. Para mais informações, consulte os artigos Fazer uma cópia de segurança e restaurar no Kubernetes e Clonar um cluster de base de dados a partir de uma vista geral da cópia de segurança do Kubernetes.

Implementação

Quando escolhe uma arquitetura de referência de disponibilidade, tenha em atenção as seguintes vantagens, limitações e alternativas.

Vantagens

  • Fácil de usar e gerir, e adequado para bases de dados não críticas com RTO/RPO tolerantes.
  • Hardware adicional mínimo necessário
  • As cópias de segurança são sempre necessárias para um plano de recuperação de desastres completo
  • É possível fazer a recuperação para qualquer momento no período de recuperação

Limitações

  • Requisitos de armazenamento possivelmente superiores aos da própria base de dados, dependendo dos requisitos de retenção.
  • Pode demorar a recuperar e pode resultar num OTR mais elevado.
  • Pode resultar na perda de alguns dados, consoante a disponibilidade dos dados WAL atuais após a falha da base de dados, o que pode afetar negativamente o RPO.

Alternativas

  • Considere a arquitetura de disponibilidade melhorada ou premium para melhorar as opções de disponibilidade e recuperação de desastres.

O que se segue?