> > > Que desafio bonito! > > Sendo para o setor público, acho que fica lindo. Pode virar um caso > para apresentação; apesar de ser pequeno, é muito crítico (para o > Brasil!) e será muito visível. >
Quem sabe uma PgConzinha com um belo caso de uso? > > >> Temos um sistema onde o usuário espera não ter de reiniciar uma > >> transação mesmo com falha de um servidor, desde que outro possa > >> automaticamente continuá-la num intervalo de até quinze segundos. > >> Quais seriam os componentes mais indicados para essa situação em > >> PostgreSQL hoje? PostgresXL, PostgresXC, pg_pool? Perdoem a > >> ignorância, estou muito enferrujado mesmo. > > > > Eu vejo algo mais como transações preparadas e replicação ordinária > > Poderia explicar melhor? Estou muito enferrujado mesmo, e o colega > não é familiarizado com PostgreSQL. Pelo que estou entendendo, as > transações preparadas (efetivação em duas fases) serviriam para que a > réplica entre no ar como principal com a transação efetivada, confere? > 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. 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. Tabelas temporárias ou não-logadas não podem participar desse tipo de transação. > > > 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. Isso tem um impacto no desempenho, evidentemente. > > 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! > > > > Acho que o conceito pode ser provado sim. > > Não sabes como isso me deixa feliz! > > 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. []s Flavio Gurgel
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
