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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
