Em qua, 26 de out de 2016 às 15:27, Cleiton Luiz Domazak < [email protected]> escreveu:
> 2016-10-26 11:19 GMT-02:00 Cleiton Luiz Domazak <[email protected]> > : > > > > 2016-10-26 11:13 GMT-02:00 Flavio Henrique Araque Gurgel <[email protected] > >: > > > > O que quer dizer com "não existissem"? Eles não cairam no seu bucket? > > > Sim, nem no bucket e nem no archive_status, é como eles tivessem sido > criados pelo banco, mas não existissem para o archive_command > > > Pergunta : Seu banco está escrevendo? > Qual o resultado de: > select pg_current_xlog_location(); > ? > Se você fizer um: > select pg_switch_xlog(); > Há um arquivamento feito? > > > Sim, o arquivamento está funcionando. > > Eu não perguntei se o arquivamento está funcionando. A pergunta foi: seu banco está escrevendo? Por isso pedi o teste do pg_switch_xlog. > > postgres=# \x > Expanded display is on. > postgres=# SELECT *, > postgres-# current_setting('archive_mode')::BOOLEAN > postgres-# AND (last_failed_wal IS NULL > postgres(# OR last_failed_wal <= last_archived_wal) > postgres-# AS is_archiving, > postgres-# CAST (archived_count AS NUMERIC) > postgres-# / EXTRACT (EPOCH FROM age(now(), stats_reset)) > postgres-# AS current_archived_wals_per_second > postgres-# FROM pg_stat_archiver; > -[ RECORD 1 ]--------------------+------------------------------ > archived_count | 147 > last_archived_wal | 000000010000011B00000078 > last_archived_time | 2016-10-26 11:19:04.131357-02 > <04%2013%2013%2057%2002> > failed_count | 0 > last_failed_wal | > last_failed_time | > stats_reset | 2016-10-26 08:52:26.66709-02 > is_archiving | t > current_archived_wals_per_second | 0.0166593669872578 > > Note que não há nenhum arquivamento falho. > > O que reparei agora, é que alguns archives desses que não são processados, > acabaram sendo arquivados. > > # cat ../pg_log/postgresql-Wed.log | grep '000000010000011B0000006F' > DETAIL: Uploading "pg_xlog/000000010000011B0000006F" to > "s3://bkp-postgresql-wale-local-hmg/wal_005/000000010000011B0000006F.lzo". > STRUCTURED: time=2016-10-26T13:10:01.724498-00 > <01%2072%2044%2098%2000> pid=54026 action=push-wal > key=s3://bkp-postgresql-wale-local-hmg/wal_005/000000010000011B0000006F.lzo > prefix= seg=000000010000011B0000006F state=begin > DETAIL: Archiving to > "s3://bkp-postgresql-wale-local-hmg/wal_005/000000010000011B0000006F.lzo" > complete at 1577.14KiB/s. > STRUCTURED: time=2016-10-26T13:10:02.240725-00 > <02%2024%2007%2025%2000> pid=54026 action=push-wal > key=s3://bkp-postgresql-wale-local-hmg/wal_005/000000010000011B0000006F.lzo > prefix= rate=1577.14 seg=000000010000011B0000006F state=complete > > > Minha dúvida é, pq eles foram criados e não processados pelo > archive_command, e agora, depois de 2 horas depois são arquivados? > Provavelmente porque seu banco não teve escrita no período e, agora, veio uma rajada de escrita qualquer. Banco que não escreve não gera wal e não faz checkpoint. Para forçar arquivamento, você precisa configurar a GUC archive_timeout. Note que isso vai forçar o banco a arquivar 16MiB, mesmo sem necessidade se o arquivo estiver parcialmente cheio. > > E uma curiosidade, a diretório pg_xlog, está sempre com 130 arquivos(wal > segments), não importa o horário. > > Meu wal_keep_segments está setado para 30. > A quantidade de arquivos depende de outras configurações, dependendo da sua versão. Até 9.4, depende de checkpoint_segments e checkpoint_completion_target (normalmente a quantidade de arquivos é igual a 2*checkpoint_segments+checkpoint_segments*checkpoint_completion_target+wal_keep_segments). A partir da 9.5 depende de max_wal_size. []s Flavio Gurgel
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
