Discussion:
[pgbr-geral] Acúmulo de Wal no servidor Master
Felippi Cunegundes Laender
2018-04-04 12:14:03 UTC
Permalink
Olá a todos.

O Assunto wal me deixa um pouco confuso as vezes. Quando acho que estou
entendendo alguma coisa, vem os problemas e pronto, não entendi nada do que
estudei.

Meu cenário é o seguinte: Fiz uma replicação com repmgr para testar e
funcionou beleza. Após meus testes de tornar master em standby, standby em
master, etc excluí o servidor de standby mantendo as configurações de
replicação no master.

Sobre o postgresql.conf no período de replicação o archive_mode = on e o
archive_command = '/bin/true'. wal_keep_segments = 100. Após ver que meu
/var estava próximo ao estouro, diminuí meu wal_keep_segments = 10, nada
alterou.

Gostaria de saber se tem algum modo efetivo, mais elegante de excluir esses
arquivos wal. A única opção na minha mente é um rm -r nos arquivos mantendo
apenas dois últimos dias.

A versão do postgresql é a 9.4, não tenho mais o servidor de standby e o
acumulo do wal continua.

Obrigado!
Cleiton Luiz Domazak
2018-04-04 12:37:49 UTC
Permalink
2018-04-04 9:14 GMT-03:00 Felippi Cunegundes Laender <
Post by Felippi Cunegundes Laender
Olá a todos.
O Assunto wal me deixa um pouco confuso as vezes. Quando acho que estou
entendendo alguma coisa, vem os problemas e pronto, não entendi nada do que
estudei.
Meu cenário é o seguinte: Fiz uma replicação com repmgr para testar e
funcionou beleza. Após meus testes de tornar master em standby, standby em
master, etc excluí o servidor de standby mantendo as configurações de
replicação no master.
Sobre o postgresql.conf no período de replicação o archive_mode = on e o
archive_command = '/bin/true'. wal_keep_segments = 100. Após ver que meu
/var estava próximo ao estouro, diminuí meu wal_keep_segments = 10, nada
alterou.
Gostaria de saber se tem algum modo efetivo, mais elegante de excluir
esses arquivos wal. A única opção na minha mente é um rm -r nos arquivos
mantendo apenas dois últimos dias.
Siga esse procedimento, só tome cuidado para não inverter os valores :)

https://erpnani.blogspot.com.br/2016/01/postgresql-how-to-clean-pgxlog.html
Post by Felippi Cunegundes Laender
A versão do postgresql é a 9.4, não tenho mais o servidor de standby e o
acumulo do wal continua.
Obrigado!
_______________________________________________
pgbr-geral mailing list
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Felippi Cunegundes Laender
2018-04-04 12:41:18 UTC
Permalink
Cleiton, fantástico. Obrigado pelo link. =)
Salvando nos favoritos.

Em qua, 4 de abr de 2018 às 09:38, Cleiton Luiz Domazak <
Post by Cleiton Luiz Domazak
2018-04-04 9:14 GMT-03:00 Felippi Cunegundes Laender <
Post by Felippi Cunegundes Laender
Olá a todos.
O Assunto wal me deixa um pouco confuso as vezes. Quando acho que estou
entendendo alguma coisa, vem os problemas e pronto, não entendi nada do que
estudei.
Meu cenário é o seguinte: Fiz uma replicação com repmgr para testar e
funcionou beleza. Após meus testes de tornar master em standby, standby em
master, etc excluí o servidor de standby mantendo as configurações de
replicação no master.
Sobre o postgresql.conf no período de replicação o archive_mode = on e o
archive_command = '/bin/true'. wal_keep_segments = 100. Após ver que meu
/var estava próximo ao estouro, diminuí meu wal_keep_segments = 10, nada
alterou.
Gostaria de saber se tem algum modo efetivo, mais elegante de excluir
esses arquivos wal. A única opção na minha mente é um rm -r nos arquivos
mantendo apenas dois últimos dias.
Siga esse procedimento, só tome cuidado para não inverter os valores :)
https://erpnani.blogspot.com.br/2016/01/postgresql-how-to-clean-pgxlog.html
Post by Felippi Cunegundes Laender
A versão do postgresql é a 9.4, não tenho mais o servidor de standby e o
acumulo do wal continua.
Obrigado!
_______________________________________________
pgbr-geral mailing list
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Fabrízio de Royes Mello
2018-04-04 13:51:20 UTC
Permalink
Post by Cleiton Luiz Domazak
2018-04-04 9:14 GMT-03:00 Felippi Cunegundes Laender <
Post by Felippi Cunegundes Laender
Olá a todos.
O Assunto wal me deixa um pouco confuso as vezes. Quando acho que estou
entendendo alguma coisa, vem os problemas e pronto, não entendi nada do que
estudei.
Post by Cleiton Luiz Domazak
Post by Felippi Cunegundes Laender
Meu cenário é o seguinte: Fiz uma replicação com repmgr para testar e
funcionou beleza. Após meus testes de tornar master em standby, standby em
master, etc excluí o servidor de standby mantendo as configurações de
replicação no master.
Post by Cleiton Luiz Domazak
Post by Felippi Cunegundes Laender
Sobre o postgresql.conf no período de replicação o archive_mode = on e o
archive_command = '/bin/true'. wal_keep_segments = 100. Após ver que meu
/var estava próximo ao estouro, diminuí meu wal_keep_segments = 10, nada
alterou.
Post by Cleiton Luiz Domazak
Post by Felippi Cunegundes Laender
Gostaria de saber se tem algum modo efetivo, mais elegante de excluir
esses arquivos wal. A única opção na minha mente é um rm -r nos arquivos
mantendo apenas dois últimos dias.
Post by Cleiton Luiz Domazak
Siga esse procedimento, só tome cuidado para não inverter os valores :)
https://erpnani.blogspot.com.br/2016/01/postgresql-how-to-clean-pgxlog.html

Muito cuidado com a recomendação desse post, pois o pg_resetxlog deve ser
utilizado em último caso, inclusive a documentação oficial cita o que segue
no primeiro parágrafo:

"pg_resetxlog clears the write-ahead log (WAL) and optionally resets some
other control information stored in the pg_control file. This function is
sometimes needed if these files have become corrupted. It should be used
only as a last resort, when the server will not start due to such
corruption."

Vide: https://www.postgresql.org/docs/9.4/static/app-pgresetxlog.html

Att,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Loading...