2014-12-10 18:28 GMT-02:00 Everton Berz <[email protected]>:
> Seguindo no exemplo hipotético do banco, de tempos em tempos teria de se
>> fazer uma fragmentação das tabelas de movimento, pois senão teríamos um
>> inchaço muito grande com o passar do tempo. Li sobre a herança no
>> postgresql, alguém pode citar de repente alguma experiência com esse
>> recurso? Como ficam as chaves estrangeiras na herança?
>>
>>
>>
>
> Existem problemas com FK's na herança. Essa funcionalidade do PostgreSQL
> acabou sendo deixada de lado pois consideraram outras características mais
> importantes (e eu concordo). Eu tentei usar uma vez em um projeto de médio
> porte e desisti.
> Exemplo ( http://www.postgresql.org/docs/9.3/static/ddl-inherit.html ):
> A serious limitation of the inheritance feature is that indexes (including
> unique constraints) and foreign key constraints only apply to single
> tables, not to their inheritance children.
>
>
Mas lembrem-se que herança ainda é extremamente útil para particionamento
de tabelas... :)
E sim, acho que é consenso que é péssimo para usar como "herança" de
fato... ;)
>
>
>> ---
>>
>>
>>
>> Achei interessante os links abaixo e a replicação por streaming é muito
>> legal. Tenho uma dúvida em relação a ela que seria mais ou menos assim:
>> Cliente faz uma operação de pagamento de um título e em seguida consulta o
>> título novamente. No momento do pgto (operação de escrita), minha aplicação
>> executa no servidor máster e na consulta (apenas leitura), minha aplicação
>> consulta em um servidor slave. Pode ocorrer de fazer o pagamento do título
>> e consultar em seguida e ainda não aparecer o pagamento? (pelo que vi pode
>> sim, mas quanto tempo e onde pode ser configurado este tempo? Malefícios de
>> deixar um time baixo?)
>>
>>
>>
>
> Pode, se tiver em replicação assíncrona.
>
Mesmo na replicação síncrona (via streaming replication nativo), pode sim
acontecer de gravar um registro e tentar ler imediatamente do secundário e
o registro ainda não estar disponível. Isso porque a replicação síncrona
garante que os logs de transação foram transmitidos e gravados em disco,
mas não que já foram aplicados (com registros já disponíveis para consulta).
Em aplicações "complexas", uma prática comum é conseguir identificar (pela
aplicação) quais consultas podem suportar um certo atraso e quais não, no
caso uma requisição seguida como descreveu sempre deve fazer a consulta no
servidor primário.
> Nesse teu cenário, eu não vejo malefícios em deixar um time baixo.
> Entretanto, nada garante que será sincronizado antes do usuário invocar na
> tela de consulta no standby.
> Você pode monitorar o lag através desta query e ter uma ideia do tempo
> médio da replicação no seu ambiente.
>
> SELECT CASE WHEN pg_last_xlog_receive_location() =
> pg_last_xlog_replay_location() THEN 0
> ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())
> END AS log_delay;
>
Na minha opinião consultar o lag por tempo é algo muito frágil,
principalmente no caso acima comparar "receive_location" com
"replay_location", e se o primário já estiver bem adiante mais ainda não
enviou? Ou pior, e se perdeu a sincronia? A sua função continuará
retornando 0 como se tudo estivesse bem. Outro problema é a sincronia de
data/hora entre os servidores, mas concordo que esse tem soluções
aceitáveis (NTP, por exemplo).
Uma comparação com maior acurácia seria em bytes e consultando no servidor
primário:
SELECT client_addr, application_name,
pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),
replay_location))
FROM pg_stat_replication;
A consulta acima só vai funcionar a partir da 9.2 (valeu Euler pela
pg_xlog_location_diff, super útil). Em versões anteriores é um pouco mais
trabalhoso.
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
