Descrever o registro antecipado de gravação
Quando são feitas alterações no banco de dados, como INSERTS ou DELETES, essas alterações são primeiro gravadas em um log e, só em seguida, gravadas em arquivos de dados no disco. Essa operação é chamada de log write-ahead, porque as alterações são gravadas no log, antes de confirmá-las em arquivos de dados. Se houver um problema, como perda de energia, o log sempre contém os dados mais recentes e pode ser usado para garantir que o banco de dados esteja em um estado consistente.
Um segundo benefício é que, ao escrever 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, porque 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 log write-ahead funciona e otimizá-lo para sua carga de trabalho:
- commit_delay - o atraso entre a confirmação da transação e a liberação do log no disco.
- wal_buffers - o número de buffers de página de disco na memória compartilhada para registro de gravação antecipada (WAL).
- max_wal_size - tamanho máximo para deixar a WAL crescer antes de acionar o ponto de verificação automático.
- wal_writer_delay - intervalo de tempo entre os flushes WAL realizados pelo gravador WAL.
- wal_compression - se as gravações de página inteira no arquivo WAL são compactadas.
- wal_level - determina a quantidade de informação que é gravada no WAL. Os valores permitidos são REPLICA ou LOGICAL.
Restauro para um ponto anterior no tempo
O objetivo principal do write-ahead log (WAL) é garantir a consistência e a durabilidade do banco de dados em caso de falha. A versão local do PostgreSQL permite que o log seja usado como um arquivo, permitindo que você restaure para um ponto no tempo usando as definições de configuração archive_mode e archive_command.
O Banco de Dados do Azure para PostgreSQL é um serviço gerenciado, que não permite acesso ao sistema de arquivos subjacente. No entanto, inclui backups completos automáticos do servidor, incluindo todos os bancos de dados. Esse backup permite que você recrie seus dados para um ponto no tempo. Os backups são agendados automaticamente e são feitos uma vez por dia. Se precisar restaurar, você pode 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:
- No portal do Azure, navegue até o banco de dados do Azure para servidor flexível PostgreSQL.
- Na seção Visão geral, selecione sua Configuração.
- Em Backups, localize Período de retenção de backup (em dias). A barra deslizante permite que você selecione o número de dias que deseja que os backups sejam mantidos.
- Selecione Salvar para manter as alterações.