Entendi agora o arquivamento da forma correta.
Apesar do delay entre o slave e o master ficar crescendo mesmo com o slave
aplicando os archives, é como se o postgres só ajustasse esse tempo quando
o vacuum da tabela é finalizado.
O delay chegou a mais de 1h, mas quando passou dessa tabela (160GB)
>
> Não use wal_keep_segments. Ao invés disso, utilize arquivamento (< 9.4)
> ou slots (>= 9.4).
>
>
Se você está usando arquivamento basta configurar o parâmetro
> restore_command no recovery.conf do servidor secundário. O comando a ser
> informado deve buscar onde você está arquivando os logs
On 03-02-2017 16:06, Luiz Carlos L. Nogueira Jr. wrote:
> Você pode simplesmente ajustar o parâmetro wal_keep_segments, caso
> vc tenha espaço em disco para isso claro, e manter mais WALs, assim
> mesmo em momentos em que o volume de WAL gerado é grande, você não
> perderá a
>
>
> Você pode simplesmente ajustar o parâmetro wal_keep_segments, caso vc
> tenha espaço em disco para isso claro, e manter mais WALs, assim mesmo em
> momentos em que o volume de WAL gerado é grande, você não perderá a
> replicação.
>
>
Meu wal_keep_segments = 64
No meu archive_command eu
2017-02-03 15:41 GMT-02:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:
> Pessoal,
>
> O ambiente é o seguinte:
>
> 1-Tenho 500GB de dados (área para dados 1.2TB)
> 2-Maiores tabelas 2 de 200GB
> 3-pg_xlog 20GB
>
> Gostaria e fazer um vacuum full "transparente" na replicação e não sei
Pessoal,
O ambiente é o seguinte:
1-Tenho 500GB de dados (área para dados 1.2TB)
2-Maiores tabelas 2 de 200GB
3-pg_xlog 20GB
Gostaria e fazer um vacuum full "transparente" na replicação e não sei se a
estratégia que uso é a melhor.
Uma vez que fiz numa base menor, notei que o delay entre o
