Daniel, quanto a questão do checkpoint_completion_target não havia me atentato. E desta forma justificaria o tempo de descarga dos dados em disco. O shared_buffer é elevado em nosso caso pois nosso processamento de dados exige tal configuração de memoria.
Daniel, o arquivo de recovery.conf está da seguinte forma standby_mode = 'on' primary_slot_name = 'bdreplica01' primary_conninfo = 'host=bdreplica00 port=5433 user=replication' trigger_file = '/var/lib/pgsql/9.6/data/im_the_master' Att, Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva <[email protected] > escreveu: > > > ------------------------------ > *De: *"Marcelo Kruger" <[email protected]> > *Para: *"Comunidade PostgreSQL Brasileira" <[email protected]. > org.br> > *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:55:07 > *Assunto: *Re: [pgbr-geral] Lentidão na aplicação do Archive - > Stream Replication > > Daniel, boa tarde. > Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que > tenho 350GB de archives no slave que não foram aplicados ainda. Ou seja, o > processo de WAL Sender envia o arquivo, mas o Slave leva muito tempo para > aplicar na base de dados. > > Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso > será o tempo aproximado para processar o arquivo, o tempo de envio deverá > ser curto. > > Apos finalizar o archive no master o envio para o slave e instantaneo. > Contudo notamos que para gerar um arquivo de 16MB no pg_xlog do master está > levando mais de 10 minutos. E temos operação massiva de inserção e > alteração, que não justificaria a demora para finalizar este archive. > > Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da > base, inclusive, esse cluster está configurado com uma valor bem alto de > shared_buffer, então para ler essa memória e descarregar poderá levar mais > tempo que previsto. Ler esse link [1] > O seu checkpoint_timeout está em 10 minutos, porém o > checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor > default, como está comentado, e valor no comentário é 0.9, significa que > será feito uma descarga da memória para o disco de arquivos WAL a cada +-5 > minutos (10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos ( > 10 minutos * 0.9), se configurado dessa forma. É importante intender como > funciona esse processo. > > Mas existe algum problema na slave ainda. Como está configurado seu > "recovery.conf"? Esse arquivo deveria ler os arquivos que chega > instantaneamente. > > [1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html > > Att, > > > > Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva < > [email protected]> escreveu: > >> >> >> ------------------------------ >> *De: *"Marcelo Kruger" <[email protected]> >> *Para: *"Comunidade PostgreSQL Brasileira" <[email protected]. >> org.br> >> *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:14:04 >> *Assunto: *Re: [pgbr-geral] Lentidão na aplicação do Archive - >> Stream Replication >> >> Lucas, boa tarde. >> Não é utilizado Parallel Query no Slave. >> >> Att, >> >> Em 30 de agosto de 2017 14:07, Lucas Viecelli <[email protected]> >> escreveu: >> >>> >>>> Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da >>>> replica. >>>> >>>> Gostaria de apoio para resolver este problema de lentidão no momento do >>>> recovery destes archives >>>> >>>> 12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 >>>> postgres: wal receiver process streaming 8D8/A623D4B8 >>>> >>>> >>>> 40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 >>>> postgres: startup process recovering 000000010000088600000038 >>>> >>>> >>> Marcelo, você está usando o recurso de Parallel Query nessa banco Slave? >>> Se sim, as consultas são demoradas? >>> -- >>> >>> Atenciosamente. >>> >>> *Lucas Viecelli* >>> >>> <http://www.leosoft.com.br/coopcred> >>> >>> _______________________________________________ >>> pgbr-geral mailing list >>> [email protected] >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >> >> Marcelo, >> >> Faz o seguinte teste, identifica um arquivo WAL gerado dentro da pg_xlog/ >> no server master agora, e acompanha quanto tempo esse arquivo demorar para >> chegar no slave. Além disso, faz uma consulta em alguma tabela que está no >> servidor master, recupera algumas linhas, e verifica quanto tempo +- demora >> para chegar essa informação no slave. >> >> Obrigado. >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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 >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
