2016-09-02 11:48 GMT-03:00 Flavio Henrique Araque Gurgel <fha...@gmail.com>:
>
> Quem sabe uma PgConzinha com um belo caso de uso?

Dentro!  Depois de seis anos e meio de burocracia, estou muito a fim
de voltar à vida (técnica).


> A transação preparada sobrevive a falhas do serviço de banco de dados ou do
> servidor. Uma réplica (ou mesmo o antigo mestre reinicializado) guarda a
> transação no estado em que ela estava. Exemplo :
> Servidor principal:
> BEGIN;
> PREPARE TRANSACTION  xxx; --xxx é seu identificador
> INSERT...
> UPDATE...
> DELETE...
> --CRASH--
>
> Sobe o servidor secundário (previamente em replicação síncrona):
> COMMIT PREPARED xxx;
> Continua a vida.

Bonito.


> Note que esta implementação tem várias nuances, por exemplo, existe o risco
> de "esquecer" a transação aberta e isso tem custos altos (como tuplas que
> não são recuperadas pelo autovacuum, bloqueios que não são liberados, etc),
> logo, a aplicação tem que ser bem escrita.

A aplicação é nossa, então isso não seria problema, em princípio.


>> > já garante o requisito se em replicação síncrona.
>>
>> Quiseste dizer sem replicação síncrona?
>
> Não, a replicação *tem de ser síncrona* senão você corre o risco de não ter
> algo replicado a tempo e o usuário não poderá continuar o que estava
> fazendo.

Agora entendi.  Não consegui entender a tua frase, achei que fosse
erro de digitação (em tempos de teclados de celular…)


> Isso tem um impacto no desempenho, evidentemente.

Provavelmente é irrelevante.  Nossas maiores bases são muito pequenas,
e essa é minúscula.


>> > Você precisará de algo pra fazer o fail-over automático, algumas
>> > soluções
>> > que me vêm à cabeça são o clássico pgpool2 ou o moderno Patroni em
>> > https://github.com/zalando/patroni
>>
>> Pesquisaremos, obrigado!

Caramba, etcd e CoreOS… estou muito desatualizado!  Nem sei por onde começar aí.


> Calma lá, analise todos os requisitos, até aqui você nos deu um pedaço do
> bolo. Possível, digamos que é, claro. Mas são muitas variáveis, acho que
> cabe um estudo e um POC bem caprichado (o governo adora POC ;) ) e uma boa
> consultoria seria de bom tom, mas isso você sabe e já até falou.

Os colegas que têm 'todos os requisitos' estão em cópia, espero que
entrem na comunidade.  Mas de qualquer maneira conversaremos
internamente.


-- 
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191              gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691        ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a