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
