Bom dia pessoal, faz um tempo que venho colocando o que vem ocorrendo em uma replicação que fiz aqui no ambiente na empresa onde trabalho. Novo fato que não tinha visto ainda. Minha replicação funciona bem até o sábado. Eis que lembrei de que rodamos um vaccum full no banco todo sábado, e pelo horário que parou de replicar, é bem o horário em seguida que roda o vaccum. O que pode interferir na replicação o vaccum? Ou é pura coincidência?
De segunda a sexta eu rodo o vaccum analyze todos os dias e no sábado rodamos o full. *Segue meu scripit de vaccum* #!/bin/bash #INICIO=`date +%d/%m/%Y-%H:%M:%S` LOG="/var/log/banco/vacuum_`date +%Y-%m-%d`.log" echo "Inicio do vacuum analyze em `date +%d/%m/%Y-%H:%M:%S`" >> $LOG ## roda o vacuum analyze /usr/lib/postgresql/9.3/bin/vacuumdb -U postgres -d banco -z echo "Fim do vacuum analyze em `date +%d/%m/%Y-%H:%M:%S`" >> $LOG echo "####################################################" echo "Inicio do vacuum full em `date +%d/%m/%Y-%H:%M:%S`" >> $LOG ## roda o vacuum full /usr/lib/postgresql/9.3/bin/vacuumdb -U postgres -d banco -f echo "Fim do vacuum full em `date +%d/%m/%Y-%H:%M:%S`" >> $LOG Att, Diógenes V. Bittencourt Em 14 de junho de 2016 12:38, Euler Taveira <[email protected]> escreveu: > On 14-06-2016 11:55, Diógenes Vargas de Bittencourt wrote: > > Obrigado Euler, eu dei uma estudada sobre o PITR como indicado, mas o > > que entendi, me corrija se estiver errado, é que o PITR serviria como um > > backup incremental em tempo real, para que eu possa restaurar o banco em > > um momento específico, eu achei bem legal a proposta desta função, mas o > > que estamos usando aqui no nosso ambiente é somente streaming, e o que > > entendi, é que além do streaming seria feito um backup incremental o > > tempo todo no servidor. No meu caso como o servidor slave perde o > > sincronismo com o master, essa retomada do estado 100% do slave seria > > através do backup incremental que ele está fazendo? Eu ativaria o pitr > > no servidor slave, e nele iria realizar a recuperação em caso de falta > > de sincronismo? Bah, travou o nintendo! > > > Na replicação nativa, o PostgreSQL pode alternar entre "streaming" e > aplicação do WAL caso restore_command esteja habilitado (é uma das > maneiras de trabalhar com replicação). Se o registro do WAL solicitado > pelo slave não estiver mais no pg_xlog do servidor principal, o > PostgreSQL alterna para aplicação do WAL (via restore_command) até que > ele possa voltar para "streaming" novamente. A ideia aqui não é usar > PITR; neste caso, *não* deixar "perder" a réplica é a função do > restore_command. > > Caso queira destacar os arquivos do WAL que não são necessários para > replicação, você pode utilizar o archive_cleanup_command no recovery.conf. > > > -- > Euler Taveira 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 >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
