Boa tarde, Pelo que vejo, o ideal em teu caso é manter assíncrono realmente, pois sendo síncrono a perda de performance seria considerável.
O que precisas é ter uma forma de subir automaticamente o servidor slave como master no menor tempo possível caso isto se faça necessário, correto? Uma coisa que poderia ser feita é ter uma camada a mais que gerencie as conexões do banco, os clientes se conectariam a essa camada e ela enviaria os pedidos ao banco - se algum cair, ela que saberá quem está de pé ou não. Mais ou menos o que o pg_pool faz. Uma boa opção poderia ser uma camada da aplicação que se gerencie as conexões, se cair um dos bancos, abre conexões com outro banco, a partir de uma lista de servers. Veja as diversas opções existentes e escolha a melhor, qualquer dúvida poste que alguém da lista poderá ajudá-lo. Boa sorte! 2009/8/6 Walter Maier Neto <[email protected]> > > O risco de perda de dados deve ser minimizado ao máximo, mas além disso, o > custo da indisponibilidade é muito alto. Tolerada por períodos curtos, de 1 > a 2 horas na pior hipótese, mas nunca superior a isso. Mas o objetivo é que, > tanto a perda de dados como a indisponibilidade sejam eliminadas > (estatisticamente); > > Atualmente a solução é assincrona, e esse não é nosso problemas. A > preocupação com replicação sincrona é uma possível perda de performance, > pois o servidor slave está em outro site (por segurança), e mesmo > interligado através de um link profissional, tem performace muito inferior > que uma rede local. Nosso volume de dados é considerável. > > Grato pela referência abaixo, vou dar uma pesquisada e começar os pilotos; > > Att; > > Walter Maier Neto > Guarapuava/PR > > ----- Mensagem original ----- > De: "Charly Frankl" <[email protected]> > Para: "Walter Maier Neto" <[email protected]>, "Comunidade PostgreSQL > Brasileira" <[email protected]> > Enviadas: Quinta-feira, 6 de Agosto de 2009 9:36:43 (GMT-0300) > Auto-Detected > Assunto: Re: [pgbr-geral] Replicação > > Walter, bom dia... > > Para replicação você dispõe de algumas opções no universo PostgreSQL. Para > escolher a ideal no teu caso, tem-se que ver o quanto está disposto a correr > risco de perda de dados (quanto de perda é aceitável), impactos na > performance do sistema, disponibilidade do sistema (por quanto tempo eu > posso ficar com o sistema indisponível), custo operacional de implantação, > tempo gasto para recuperar os dados, dentre outras coisas. > > Tendo ponderado sobre isso, pode-se optar por um modelo síncrono ou > assíncrono. > > Dentre as soluções assíncronas posso destacar: > Slony > Warm Standby > Bucardo > SkyTools > Mammoth > > > Dentre as soluções síncronas: > PgPool-II > Log Shipping > Sequoia > *ParGRES (desenvolvido pelo pessoal do UFRJ... bem interessante) > *GridSQL (desenvolvido pelo pessoal da EnterpriseDB. Tb vale a pena dar uma > olhada) > > > Existem outras soluções também, como o PGCluster... Algumas destas soluções > não se propõem apenas a replicação, mas também a balanço de carga, pool de > conexões... > > > Espero ter ajudado. > > > Att, > > > -- > Charly Frankl > http://javadevilopers.blogspot.com/ > [email protected] > Linux user #391083 > > > > > > 2009/8/5 Walter Maier Neto < [email protected] > > > > > Atualmente temos 4 servidores, todos de trabalho, replicando entre si > (multi-master) com uma aplicação proprietária (de terceiros) que utiliza > dblink e trigger. Mas este modelo está apresentando alguns > problemas/restrições em relação ao ERP que é não é da mesma empresa da > replica. > > Estamos pensando em utilizar replicação para contingência (alta > disponibilidade) e não mais para balanceamento de carga, ou seja, utilizar o > servidor principal para trabalho e o segundário como espelho do primeiro, > sendo somente utilizado em caso de crash no principal; > > Busco mais informações práticas e consultoria especializada sobre o > assunto; > > Grato; > > Walter Maier Neto > > > > > > > > ____________________________________________________________________________________ > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > > > > > > > > ____________________________________________________________________________________ > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- André de Camargo Fernandes
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
