Daniel, Devido ao archive estar por padrão no pg_xlog não foi necessario especificar o archive_command.
Att, Em 30 de agosto de 2017 16:37, 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 16:23:54 > *Assunto: *Re: [pgbr-geral] Lentidão na aplicação do Archive - > Stream Replication > > Daniel, > O arquivo im_the_master é apenas uma trigger para transitar o servidor do > stand-by para a produção. É um arquivo vazio, nosso processo cria este > arquivo quando identifica que o servidor principal não esta respondendo. > > Quanto ao shared_buffer haviamos lido esta questão do tamanho. Chegamos a > reduzir o shared, mas o tempo de processamento do archive ficou na mesma > media de tempo. > > Att, > > Marcelo, > Como está o archive_command no slave? > > Em 30 de agosto de 2017 16:16, 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 16:03:21 >> *Assunto: *Re: [pgbr-geral] Lentidão na aplicação do Archive - >> Stream Replication >> >> 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, >> >> Marcelo, >> >> Normalmente não se utiliza o shared_buffer maior que 8GB, justamente >> porque tem esses malefícios com WAL e recovery caso necessário. Se quiser >> pesquisar dentro do arquivario do forum PostgreSQL Brasil, existe vários >> tópicos sobre as desvantagens de ser maior que 8GB. É interessante >> acompanhar o pg_buffercache do seu cluster, para saber se os arquivos >> dentro do buffer fica muito tempo, com isso, conseguirá comparar se o >> tamanho do shared_buffer está suficiente ou não. >> O que existe dentro do comando im_the_master ? >> >> 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]> >>> *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]> >>>> *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 >> >> >> _______________________________________________ >> 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
