Bom dia Flavio,
Neste momento nosso servidor StandBy não está recebendo consultas devido ao
alto delay entre o ultimo archive enviado, e o aplicado no standby. Mas
esta habilitado para receber consultas.
As configurações de max_standby_streaming_delay e max_standby_archive_delay
estão seguindo o padrão do postgres. Não fiz alterações nestes parametros.
max_standby_archive_delay | 30s
max_standby_streaming_delay | 30s
Eles poderiam influenciar?
Quanto as consultas
repositorio=# select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | active_pid
| xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
-------------+--------+-----------+--------+----------+--------+------------+-----------+--------------+--------------+---------------------
bdreplica01 | | physical | | | t | 47368
| 125364835 | | 928/B4000000 |
repositorio=# select * from pg_stat_replication;
pid | usesysid | usename | application_name | client_addr |
client_hostname | client_port | backend_start |
backend_xmin | state | se
nt_location | write_location | flush_location | replay_location |
sync_priority | sync_state
-------+----------+-------------+------------------+--------------+-----------------+-------------+-------------------------------+--------------+-----------+---
------------+----------------+----------------+-----------------+---------------+------------
47368 | 18025 | replication | walreceiver | 10.120.5.201 |
| 50464 | 2017-08-29 15:39:31.591119-03 | |
streaming | 92
9/98687328 | 929/98686000 | 929/98686000 | 88E/91CB7AE0 |
0 | async
O parametro de log checkpoint está habilitado em nosso banco, e a
quantidade de archives gerados simultaneamente é o seguinte.
[root@bdreplica00 config_exporters]# lsof | grep 00000 | grep postgres |
grep -v "deleted" | grep pg_xlog | wc -l
169
[root@bdreplica00 config_exporters]# lsof | grep 00000 | grep postgres |
grep -v "deleted" | grep pg_xlog | wc -l
159
[root@bdreplica00 config_exporters]# lsof | grep 00000 | grep postgres |
grep -v "deleted" | grep pg_xlog | wc -l
189
[root@bdreplica00 config_exporters]# lsof | grep 00000 | grep postgres |
grep -v "deleted" | grep pg_xlog | wc -l
209
O consumo do wal_receiver é baixo comparado ao numero de CPUs que temos. O
processo consome em media 20% de CPU em um nucleo. Possuimos 20 nucleos.
12819 postgres 20 0 35,692g 3520 1876 S 19,2 0,0 149:28.23
postgres: wal receiver process streaming 933/7C8D8000
40604 postgres 20 0 35,686g 3164 1468 D 2,6 0,0 126:44.17
postgres: startup process recovering 000000010000088E00000097
Os dados do IOSTAT são os seguintes
[root@bdreplica01 config_exporters]# iostat
Linux 3.10.0-327.36.3.el7.x86_64 (bdreplica01) 08/31/2017 _x86_64_ (20 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0,26 0,00 0,77 2,97 0,00 96,01
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
md0 2246,70 26805,26 50759,55 18153260865 34375764472
Quanto a escrita e leitura vejo que a mesma não esta saturada. Em nossa
configuração conseguimos atingir 1,5Gb/s de escrita no disco de banco.
Atualmente este disco é um RAID0 de 17 SSDs. O processo de aplicação de
archives esta consumindo proximo a 16Mb/s.
O problema não poderia estar ligado ao tamanho do archive, que no caso é de
16MB. Outro ponto, a blocagem do disco poderia influenciar neste processo
de restore?
Att,
Em 31 de agosto de 2017 09:25, Flavio Henrique Araque Gurgel <
[email protected]> escreveu:
>
>
> Em qui, 31 de ago de 2017 às 13:24, Daniel Luiz da Silva <
> [email protected]> escreveu:
>
>> *De: *"Marcelo Kruger" <[email protected]>
>> *Para: *"Comunidade PostgreSQL Brasileira" <[email protected].
>> org.br>
>> *Enviadas: *Quinta-feira, 31 de agosto de 2017 7:42:46
>>
>> *Assunto: *Re: [pgbr-geral] Lentidão na aplicação do Archive -
>> Stream Replication
>>
>> Bom dia Fabio,
>> Creio que tenha me expressado da maneira incorreta. Não faço nenhuma
>> alteração para copia de archives uma vez que todo o pg_xlog é transferido
>> para a outra maquina via WAL Sender sem que tenha que fazer alterações
>> tanto no recovery.conf, quanto no postgres.conf de ambas as maquinas.
>> Criamos um slot e definimos o banco como hot standby, o procedimento que
>> por sua vez fará com que o a replica receba os arquivos da maquina master,
>> e isso esta ocorrendo corretamente e de forma instantanea.
>>
>> Entretanto irei seguir as recomendações passadas por você, e irei testar
>> o procedimento do Euler.
>>
>> Agradeço desde já pela atenção.
>>
>> Att,
>>
>> Em 31 de agosto de 2017 06:45, Fábio Telles Rodriguez <
>> [email protected]> escreveu:
>>
>>>
>>>
>>> Em 30 de agosto de 2017 19:21, Marcelo Kruger <
>>> [email protected]> escreveu:
>>>
>>>> Daniel,
>>>>
>>>> Devido ao archive estar por padrão no pg_xlog não foi necessario
>>>> especificar o archive_command.
>>>>
>>> Você está fazendo confusão! Jamais copie arquivos diretamente para
>>> dentro ou para fora do pg_xlog. Deixe que o PostgreSQL gerencie esta área
>>> para você.
>>>
>>> Monte o Standby de acordo com o procedimento normal. Se estiver na
>>> dúvida, siga o procedimento do artigo do Euler Taveira em:
>>> http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html
>>>
>>
>>
>> Marcelo,
>> Esse artigo explica bem como configurar diferentes cenários de
>> replicação. Mas no seu caso, perceba que a princípio, não existe
>> configuração para recebimento do slot de replicação. Então algum problema
>> com configuração de hardware ou rede, pode estar acontecendo.
>>
>
> Gente, vamos todos com muuuuuita calma aí. Um monte de informação jogada e
> nenhuma direção clara pra identificar o problema. Os artigos enviados estão
> ótimos e corretos, mas parece que o OP está seguindo "o manual" e tem uma
> replicação bem padrão configurada, considero que esteja correta.
>
> Ao OP, tenho uma única pergunta - essa base standby recebe consultas de
> leitura?
> Quais são as configurações max_standby_streaming_delay
> e max_standby_archive_delay (parece não importante no seu caso esta última)
> ?
>
> Como está usando slots de replicação, qual o resultado das consultas
> abaixo *no servidor mestre* :
> TABLE pg_replication_slots;
> TABLE pg_stat_replication;
>
> Você tem o parãmetro log_checkpoints habilitado no mestre? Se sim, tem
> como fazer um grep checkpoint no seu log pra gente ver o quanto essa base
> escreve?
>
> No servidor standby, tem como ver se o processo wal_receiver está
> consumindo muita CPU (top, ps) ?
> No servidor standby, poderia nos dizer se a utilisação de disco em escrita
> está saturada (iostat) ?
>
> []s
> Flavio Gurgel
>
>
> _______________________________________________
> 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
