Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

[Euler Taveira]

On 08-03-2016 12:40, Everton Berz wrote:
> Eu quis dizer que os parâmetros estão comentados no primário. No standby
> são aqueles valores que informei.
>
No primário, max_standby_*_delay não tem efeito; eles valem no
secundário. Isso confirma a minha teoria que os atrasos são ocasionados
pelas consultas de longa duração.

> Sobre não haver cancelamento de consultas, essa é a política adotada, é
> uma exigência da aplicação/negócio.
> 
Se quiserem uma replicação sem atraso, você vai precisar de outro
servidor com os valores igual a zero ou mesmo que não aceite consultas.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

[Everton Berz]

2016-03-08 12:33 GMT-03:00 Euler Taveira :

> On 07-03-2016 14:55, Everton Berz wrote:
> > Primário: os parâmetros max_standby.. estão comentados
> > Standby:
> > #max_standby_archive_delay = 30s
> > max_standby_archive_delay = -1
> > max_standby_streaming_delay = -1
> >
> Eu não entendi... Acima parece descomentados mas você está dizendo que
> estão comentados. O padrão é 30s mas -1 significa que *não* há
> cancelamento de consultas, ou seja, haverá um atraso em aplicar a
> replicação causado pelas consultas longas.
>
> Os parâmetros max_standby_*_delay controlam exatamente a tolerância (i)
> para cancelamento de consultas ou (ii) para atraso na replicação. -1
> significa não cancele consultas e atrase a replicação (se necessário). 0
> significa não atrase a replicação e cancele consultas (se necessário).
>
> O log em anexo não indica que estar havendo "parada" da replicação (o
> LSN está aumentando).
>
>
Eu quis dizer que os parâmetros estão comentados no primário. No standby
são aqueles valores que informei.
Sobre não haver cancelamento de consultas, essa é a política adotada, é uma
exigência da aplicação/negócio.



> > Estamos planejando migrar para 9.5.1.
> >
> A migração para uma nova versão é mais demorada porque deve haver
> homologação e/ou adaptação da aplicação. Ao invés disso, você poderia
> instalar a 9.3.11 (última versão corretiva da 9.3) para não ter
> problemas com bugs conhecidos. A atualização *não* implica em novas
> funcionalidades ou alteração de comportamento e para fazê-la basta
> atualizar os binários e reiniciar o serviço.
>


Ok, vamos analisar isso.
Obrigado!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

[Euler Taveira]

On 07-03-2016 14:55, Everton Berz wrote:
> Primário: os parâmetros max_standby.. estão comentados
> Standby: 
> #max_standby_archive_delay = 30s
> max_standby_archive_delay = -1
> max_standby_streaming_delay = -1
> 
Eu não entendi... Acima parece descomentados mas você está dizendo que
estão comentados. O padrão é 30s mas -1 significa que *não* há
cancelamento de consultas, ou seja, haverá um atraso em aplicar a
replicação causado pelas consultas longas.

Os parâmetros max_standby_*_delay controlam exatamente a tolerância (i)
para cancelamento de consultas ou (ii) para atraso na replicação. -1
significa não cancele consultas e atrase a replicação (se necessário). 0
significa não atrase a replicação e cancele consultas (se necessário).

O log em anexo não indica que estar havendo "parada" da replicação (o
LSN está aumentando).

> Estamos planejando migrar para 9.5.1.
> 
A migração para uma nova versão é mais demorada porque deve haver
homologação e/ou adaptação da aplicação. Ao invés disso, você poderia
instalar a 9.3.11 (última versão corretiva da 9.3) para não ter
problemas com bugs conhecidos. A atualização *não* implica em novas
funcionalidades ou alteração de comportamento e para fazê-la basta
atualizar os binários e reiniciar o serviço.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

[Everton Berz]

2016-03-02 11:52 GMT-03:00 Euler Taveira :

> On 02-03-2016 11:22, Everton Berz wrote:
> > ontem tivemos duas paradas na replicação do primário para o standby, ou
> > seja, o standby não recebeu mais atualizações do primário.
> > Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao
> normal.
> >
> O que você quis dizer com parou de replicar? Dependendo do cenário, uma
> simples consulta pode "parar" a replicação com algum bloqueio (aka
> lock). Quais os valores dos parâmetros max_standby_*_delay?
>
>
"Parou de replicar" = as informações contidas no standby "congelaram". As
informações  não foram mais atualizadas..

Primário: os parâmetros max_standby.. estão comentados
Standby:
#max_standby_archive_delay = 30s
max_standby_archive_delay = -1
max_standby_streaming_delay = -1




> > Não existem mensagens de erro no log do PostgreSQL primário nem no
> standby.
> >
> Quando a conexão de replicação cai de maneira inesperada você tem uma
> mensagem no log. O processo wal sender e/ou wal receiver estava presente
> nos respectivos servidores? Você executou um strace no wal sender?
>
>
Tanto o receiver quanto o sender continuaram presentes e, inclusive,
alterando o identificador que é exibido após a palavra "streaming".
Envio em anexo um trecho da saída do OSWatcher. A primeira parada foi às
4:35.

Não executei strace, vou executar se acontecer novamente.



> Nem o OSWatcher nem o Zabbix exibem problemas de conectividade, disco ou
> SO.
> >
> Isso está parecendo consultas longas com bloqueios.
>
>
Elas existem, e são muitas.
Entretanto em um dos horários que aconteceu o problema não consegui
detectar isso. Utilizei o pg_activity e manualmente na view
pg_stat_activity.



> > Existe alguma maneira de diagnosticar melhor esse problema?
> >
> Qualquer problema na replicação é reportado no log.
>
> Recordo-me que há uma correção na 9.3.11 cuja mensagem de ERRO de
> conexão não era emitida após receber um EOF.
>
> Fix premature clearing of libpq's input buffer when socket EOF is seen
>
> Atualize sua versão.
>
>
Estamos planejando migrar para 9.5.1.


Obrigado
Standby:

zzz ***Tue Mar 1 04:34:31 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:52 
postgres: wal receiver process   streaming 1FFF/77A98000
zzz ***Tue Mar 1 04:35:05 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:53 
postgres: wal receiver process   streaming 1FFF/86F36E18
zzz ***Tue Mar 1 04:35:38 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:53 
postgres: wal receiver process   streaming 1FFF/874AFC70
zzz ***Tue Mar 1 04:36:12 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:54 
postgres: wal receiver process   streaming 1FFF/88B5A000
zzz ***Tue Mar 1 04:36:46 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:55 
postgres: wal receiver process   streaming 1FFF/8B3F9170
zzz ***Tue Mar 1 04:37:20 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:55 
postgres: wal receiver process   streaming 1FFF/8C6AE078
zzz ***Tue Mar 1 04:37:54 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:55 
postgres: wal receiver process   streaming 1FFF/8D97
zzz ***Tue Mar 1 04:38:28 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:56 
postgres: wal receiver process   streaming 1FFF/8EB94000
zzz ***Tue Mar 1 04:39:02 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:56 
postgres: wal receiver process   streaming 1FFF/8F47E000
zzz ***Tue Mar 1 04:39:36 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:56 
postgres: wal receiver process   streaming 1FFF/8F70C000
zzz ***Tue Mar 1 04:40:10 BRT 2016
postgres 23011 22933  19  0.9  0.0 26355312 7480 poll_s S   Jan 31 06:28:56 
postgres: wal receiver process   streaming 1FFF/8F8FF678


Primário:
zzz ***Tue Mar 1 04:34:10 BRT 2016
postgres 30490 25294  19  0.2  0.0 26349912 6292 poll_s S   Jan 31 01:34:39 
postgres: wal sender process replicacao 10.4.16.53(33604) streaming 
1FFF/76058000
zzz ***Tue Mar 1 04:34:44 BRT 2016
postgres 30490 25294  19  0.2  0.0 26349912 6292 poll_s S   Jan 31 01:34:39 
postgres: wal sender process replicacao 10.4.16.53(33604) streaming 
1FFF/794AE000
zzz ***Tue Mar 1 04:35:17 BRT 2016
postgres 30490 25294  19  0.2  0.0 26349912 6292 poll_s S   Jan 31 01:34:39 
postgres: wal sender process replicacao 10.4.16.53(33604) streaming 
1FFF/8717B680
zzz ***Tue Mar 1 04:35:50 BRT 2016
postgres 30490 25294  19  0.2  0.0 26349912 6292 poll_s S   Jan 31 01:34:40 
postgres: wal sender process replicacao 10.4.16.53(33604) streaming 
1FFF/881D0D18
zzz ***Tue Mar 1 04:36:23 BRT 2016
postgres 30490 25294  19  0.2  0.0 26349912 6292 poll_s S   Jan 31 01:34:40 
postgres: wal sender process replicacao 10.4.16.53(33604) streaming 
1FFF/8A15FC68
zzz ***Tue Mar 1 

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

[Everton Berz]

2016-03-02 11:44 GMT-03:00 Flavio Henrique Araque Gurgel :

> Olá
>>
>> ontem tivemos duas paradas na replicação do primário para o standby, ou
>> seja, o standby não recebeu mais atualizações do primário.
>> Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal.
>>
>
> Você faz consultas sobre o standby? Você faz dump sobre o standby?


Sim. Não.


>
>
> Não existem mensagens de erro no log do PostgreSQL primário nem no standby.
>>
>> Nem o OSWatcher nem o Zabbix exibem problemas de conectividade, disco ou
>> SO.
>>
>> Existe alguma maneira de diagnosticar melhor esse problema?
>>
>
> Monitorar a visão pg_stat_replication no servidor principal.
> Lá você pode ver todos os standby conectados e o atraso de replicaçã, seja
> no envio dos dados, no recebimento e na aplicação do outro lado.


Eu usava essa view somente para ver o atraso em segundos. Vou verificar o
restante das informações da view.


>
>
> Seria interessante alguma solução que não fosse aumentar a verbosidade
>> do log, pois posso ter restrições de armazenamento se deixasse em modo
>> debug durante todo o tempo.
>>
>
> Não há necessidade num primeiro momento.
>
> Segue minhas configurações:
>>
>> PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
>>
>
> 9.3.11 disponível, atualize o quanto antes!
>
>
Estamos planejando uma atualização para o 9.5.1


> 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit
>> Red Hat Enterprise Linux Server release 6.7 (Santiago)
>>
>>
>> wal_level = hot_standby
>> archive_mode = on
>> archive_command = '/usr/local/bin/copy_archive_logs.sh %p %f'
>> archive_timeout = 300
>> max_wal_senders = 5
>>
>
> Você tem 5 standby conectados? ou você faz uso de pg_basebackup mais
> alguma outra ferramenta?
>
>
Não, só 1 standby. Não uso pg_basebackup ou similar no standby, somente no
primário.


> wal_keep_segments = 64
>> wal_sync_method = open_sync
>>
>
> Nem sempre a melhor opção, já usou a ferramenta pg_test_fsync?
>


Não conhecia. Vou verificar.

Obrigado!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

[Euler Taveira]

On 02-03-2016 11:22, Everton Berz wrote:
> ontem tivemos duas paradas na replicação do primário para o standby, ou
> seja, o standby não recebeu mais atualizações do primário.
> Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal.
> 
O que você quis dizer com parou de replicar? Dependendo do cenário, uma
simples consulta pode "parar" a replicação com algum bloqueio (aka
lock). Quais os valores dos parâmetros max_standby_*_delay?

> Não existem mensagens de erro no log do PostgreSQL primário nem no standby.
> 
Quando a conexão de replicação cai de maneira inesperada você tem uma
mensagem no log. O processo wal sender e/ou wal receiver estava presente
nos respectivos servidores? Você executou um strace no wal sender?

> Nem o OSWatcher nem o Zabbix exibem problemas de conectividade, disco ou SO.
> 
Isso está parecendo consultas longas com bloqueios.

> Existe alguma maneira de diagnosticar melhor esse problema?
> 
Qualquer problema na replicação é reportado no log.

Recordo-me que há uma correção na 9.3.11 cuja mensagem de ERRO de
conexão não era emitida após receber um EOF.

Fix premature clearing of libpq's input buffer when socket EOF is seen

Atualize sua versão.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

[Flavio Henrique Araque Gurgel]

Olá

ontem tivemos duas paradas na replicação do primário para o standby, ou
seja, o standby não recebeu mais atualizações do primário.
Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal.


Você faz consultas sobre o standby? Você faz dump sobre o standby?


Não existem mensagens de erro no log do PostgreSQL primário nem no standby.

Nem o OSWatcher nem o Zabbix exibem problemas de conectividade, disco ou SO.

Existe alguma maneira de diagnosticar melhor esse problema?


Monitorar a visão pg_stat_replication no servidor principal.
Lá você pode ver todos os standby conectados e o atraso de replicaçã, 
seja no envio dos dados, no recebimento e na aplicação do outro lado.



Seria interessante alguma solução que não fosse aumentar a verbosidade
do log, pois posso ter restrições de armazenamento se deixasse em modo
debug durante todo o tempo.


Não há necessidade num primeiro momento.


Segue minhas configurações:

PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)


9.3.11 disponível, atualize o quanto antes!


4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit
Red Hat Enterprise Linux Server release 6.7 (Santiago)


wal_level = hot_standby
archive_mode = on
archive_command = '/usr/local/bin/copy_archive_logs.sh %p %f'
archive_timeout = 300
max_wal_senders = 5


Você tem 5 standby conectados? ou você faz uso de pg_basebackup mais 
alguma outra ferramenta?



wal_keep_segments = 64
wal_sync_method = open_sync


Nem sempre a melhor opção, já usou a ferramenta pg_test_fsync?

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

[Everton Berz]

Olá

ontem tivemos duas paradas na replicação do primário para o standby, ou
seja, o standby não recebeu mais atualizações do primário.
Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal.

Não existem mensagens de erro no log do PostgreSQL primário nem no standby.

Nem o OSWatcher nem o Zabbix exibem problemas de conectividade, disco ou SO.

Existe alguma maneira de diagnosticar melhor esse problema?

Seria interessante alguma solução que não fosse aumentar a verbosidade do
log, pois posso ter restrições de armazenamento se deixasse em modo debug
durante todo o tempo.


Segue minhas configurações:

PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-16), 64-bit
Red Hat Enterprise Linux Server release 6.7 (Santiago)


wal_level = hot_standby
archive_mode = on
archive_command = '/usr/local/bin/copy_archive_logs.sh %p %f'
archive_timeout = 300
max_wal_senders = 5
wal_keep_segments = 64
wal_sync_method = open_sync


Obrigado
--
Everton
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral