Descrever o registro em log write-ahead

  • 3 minutos

Quando as alterações são feitas no banco de dados, como INSERTS ou DELETES, essas alterações são gravadas primeiro em um log e, em seguida, gravadas apenas em arquivos de dados em disco. Essa operação é chamada de log write-ahead, pois as alterações são gravadas no log, antes de serem confirmadas nos arquivos de dados. Se houver um problema, como a perda de energia, o log sempre armazenará os dados mais recentes e poderá ser usado para garantir que o banco de dados esteja em um estado consistente.

Um segundo benefício é que, escrevendo as alterações no log primeiro, as alterações em tabelas e índices podem ser gravadas em lotes, em vez de individualmente. Esse processo reduz o número de gravações de disco necessárias para manter tabelas e índices atualizados. As gravações no log são rápidas porque são feitas sequencialmente. Gravações mais lentas em tabelas e índices podem ser feitas com segurança em lotes, pois todos os dados podem ser recuperados do log. Para cargas de trabalho que normalmente envolvem muitas pequenas atualizações, o desempenho é melhorado.

Nota

Para implementações locais do PostgreSQL, o arquivo de log é armazenado no diretório pg_wal. O Banco de Dados do Azure para PostgreSQL não fornece acesso ao sistema de arquivos, portanto, você não precisa se preocupar com o armazenamento físico do arquivo de log.

Há vários parâmetros de servidor que permitem controlar como o registro de escrita antecipada funciona e otimizá-los para sua carga de trabalho.

  • commit_delay – o atraso entre a confirmação da transação e a liberação do log para o disco.
  • wal_buffers – o número de buffers de página de disco na memória compartilhada para o WAL (log write-ahead).
  • max_wal_size - tamanho máximo para permitir que o WAL cresça antes de disparar o ponto de verificação automático.
  • wal_writer_delay – esse parâmetro define o intervalo de tempo entre as liberações de WAL executadas pelo gravador de WAL.
  • wal_compression – se as gravações de página inteira no arquivo do WAL são compactadas.
  • wal_level - determina a quantidade de informações gravadas no WAL. Os valores permitidos são REPLICA ou LOGICAL.

Recuperação Pontual

A principal finalidade do WAL (log de gravação antecipada) é garantir a consistência e a durabilidade do banco de dados em caso de uma falha. A versão local do PostgreSQL permite que o log seja usado como um arquivo, permitindo restaurar para um ponto específico no tempo usando as configurações archive_mode e archive_command.

O Banco de Dados do Azure para PostgreSQL é um serviço gerenciado, que não permite o acesso ao sistema de arquivos subjacente. No entanto, ele inclui backups completos automáticos do servidor, incluindo todos os bancos de dados. Esse backup permite recriar seus dados em um ponto no tempo. Os backups são agendados automaticamente e são feitos uma vez por dia. Se você precisar restaurar, poderá restaurar até o número de dias especificado para reter backups, até o máximo de 35 dias. Para especificar por quanto tempo os backups devem ser mantidos:

  1. No portal do Azure, navegue até o servidor flexível do Banco de Dados do Azure para PostgreSQL.
  2. Na seção visão geral, selecione sua configuração .
  3. Em Backups, encontre Período de retenção de backups (em dias). A barra de controle deslizante permite que você selecione o número de dias que deseja que os backups sejam mantidos.
  4. Selecione Salvar para manter suas alterações.