On 26-01-2017 12:19, Danilo Silva wrote:
> Pessoal,
>
> Atualmente utilizo a versão 9.3 com replicação nativa para um escravo,
> fazendo cópia dos archives para o escravo + servidor de backup.
>
> Como podemos identificar a necessidade ou não de rodar um VACUUM FULL?
>
Se vc der uma pesquisada no histórico [1] desta lista irá encontrar
diversas discussões a respeito de como detectar inchaço de objetos
> Como teste, rodei o VACUUM FULL apenas em uma tabela de 700mb e o
> diretório pg_xlog cresceu 400mb a mais e levou um tempo para ser
> liberado esse espaço adicional, esse comportamento é normal?
>
Sim. O VACUUM FULL reescreve os datafiles da sua tabela (heap + toast +
indexes), e isso quer dizer que ele faz "literalmente" uma cópia física
dos datafiles, ou seja, ele consome espaço em disco além do já utilizado
pelos datafiles atuais.
E além dos datafiles como qualquer operação transacional normal do
PostgreSQL (com exceção de Unlogged Tables) ele além de reescrever os
datafiles também escreve os logs de transações (diretório xlog).
Ele é implementado desta forma porque precisa garantir as
características "Atomicidade" e "Durabilidade" do ACID através das
técnicas de Write-ahead Logging [2]. E como os wal files são gerados
(pg_xlog) a replicação física poderá se beneficiar pois usa os registros
dos logs de transação para aplicar a mudança nas páginas também no(s)
slave(s).
> Em média, quanto tempo leva para o espaço em disco ocupado pelo VACUUM
> FULL ser liberado?
>
Difícil mensurar isso porque, por exemplo, seu servidor pode estar
retendo wal files porque seu procedimento de archive pode estar
demorando por latência de rede ou algo do gênero. Com archive_mode
ligado e o archive_command devidamente configurado o PostgreSQL só irá
reciclar o wal (remover segmentos antigos do pg_xlog) quando o
arquivamento for bem sucedido. Entao se vc faz um "scp" ou "rsync", por
exemplo, o sinal de que o segmento foi copiado com sucesso para outro
local só será enviado ao PostgreSQL após o comando ser executado.
Note que eu apenas "imaginei" um cenário baseado nas informações que
você forneceu, mas existem outras variáveis a considerar.
Att,
[1] https://www.postgresql.org.br/historico
[2] https://en.wikipedia.org/wiki/Write-ahead_logging
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
