> wal_level = hot_standby
> checkpoint_segments = 30
> archive_mode = on
> archive_command = 'scp -C %p postgresql@host_remoto.com:~/remote_logs/%f'
> max_wal_senders = 1
> wal_keep_segments = 45

Seu pg_xlog vai ter:
16 MB * (30+45) + 16 MB * checkpoint_completion_target

Se o tamanho acima bater, está tudo certo.

> [SLAVE]
> hot_standby = on
> [SLAVE recovery.conf]
> standby_mode = 'on'
> restore_command = 'cp /home/postgresql/remote_logs/%f %p'
> archive_cleanup_command = '/usr/local/postgresql/last/bin/pg_archivecleanup
> /home/postgresql/remote_logs/ %r'
> Reparei que os 8~9 últimos arquivos do meu pg_xlog são mais antigos (segundo
> o timestamp) que o último arquivo (segundo a sequencia do nome). Segue uma
> listagem do diretório

Isso é normal. O servidor primário deixa arquivos prontos pra usar
antes de eles serem necessários. Questão de performance.

> No momento da listagem, o arquivo mais novo (segundo timestamp) é o 84,
> entretanto, tem 8 arquivos (85 - 8C) "maiores" que ele. Quando um novo
> arquivo é finalizado, ele toma o lugar do mais antigo (no caso, o 85), e o
> último arquivo da sequencia (no caso, o 70), vira o maior da sequencia (no
> caso, o 8D). A quantidade de arquivos se mantem, como esperado, afinal, o
> mais antigo (85), foi substituído.

Tudo certo.

> Para efeitos de replicação, está ok. O banco sempre replica o arquivo mais
> novo (segundo timestamp) imediatamente após este ser finalizado.
> Tem algum motivo para esse comportamento peculiar na rotatividade dos
> arquivos wal ou esse é um comportamento esperado? Devo fornecer alguma
> informação a mais?

Totalmente esperado e normal.

> Eu não estou tendo qualquer problema com esse comportamento, mas como achei
> bastante peculiar resolvi compartilhar aqui.

É exatamente o funcionamento do PostgreSQL.
Veja que você aprendeu bastante sobre arquivos WAL na sua análise, parabéns!

[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a