2013/12/3 Guimarães Faria Corcete DUTRA, Leandro <[email protected]> > 2013/12/3 Matheus de Oliveira <[email protected]>: > > > > …o pgPool-II irá conectar a servidores PostgreSQL e redirecionar seus > > comandos. Ele é inteligente em identificar o que for atualização > > (INSERT/UPDATE/DELTE/ALTER TABLE/etc.) e mandá-lo somente ao master, do > que > > é consulta (SELECT) e fazer um round-robin entre o master e slaves > > Vivendo e aprendendo! > > Curiosidade: como ele faz com uma transação que escale de consulta > para atualização mas tenha começado num escravo? Aborta e recomeça, > ou pressupõe que o escravo esteja consistente com o mestre? >
Nesse caso específico ele pressupõe que esteja "atualizado" (consistente ele deve estar sempre, não?). Ou seja, se iniciar no slave, quando executa algum comando de atualização, ele simplesmente "pula" para o master. Nesses casos o ideal era forçar a execução dessa transação toda no master, mas daí já é necessário alteração de aplicação. Há entretanto, parâmetros para ele ignorar um dado slave do balanceamento caso o mesmo fique muito desatualizado (diferença em bytes da inserção do xlog no master e replicação no slave). 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
