-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Um dos grandes problemas das tecnologias nomeadas como replicação, cluster e grid é saber de fato o que elas são, quais tipos existem e quais finalidades elas atendem. Você falou sobre um monte de coisas como se uma tecnologia ou outra servissem para os mesmos propósitos numa mesma situação. Adivinha: não servem!!!
E mais, se você tiver uma base de 20TB, já vai ter dor de cabeça suficiente para conseguir sobreviver sem o uso de replicação. Dê uma olhada aqui: http://www.midstorm.org/~telles/2007/08/24/cluster-replicacao/ e melhor ainda, leia a documentação do PostgreSQL no capítulo que fala sobre replicação: http://www.postgresql.org/docs/8.3/static/high-availability.html Um grande abraço, Fábio Telles - --- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [email protected] 2009/4/7 charles andre : -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEARECAAYFAknbVaIACgkQLHUDohrbg7EFdwCcDQ0+I9E2E2Nsku1Qsw477XVy /PkAnRT+pzT0tvig1ZNlGylFbgOmJPmB =hWh3 -----END PGP SIGNATURE----- > > Vi que o pgcluster e o pgpooll-II fazem replicação multimaster. > > So que não tenho certeza se essas duas soluções são viaveis. > > Pelo que estudei o pgpool-II em caso de falha para sincronizar > o servidor que saiu do ar ele usa o PITR ou RSYNC e o pgcluster usa > o RSYNC. Em uma base de dados muito grande em torno de 20 TB acho que > essa sincronização não é viavel: o pitr varios arquivos a serem copiados, > controle dos arquivos etc e o rsync trava o sistema de arquivos ppara > poder copiar os dados ? > Ele não deveria sincronizar so os dados que foram alterados depois que o > server caiu em vez de mandar tudo de novo ? > > Outra coisa que percebi é que se tenho 3 master no pgcluster e o 3 nó sai do > ar > qdo ele retornar, gostaria de especificar de onde ele vai sincronizar. Por > exemplo > gostaria que sincroniza-se do no 2 e não do no 1 pelo que entendi ele vai > escolher qualquer > um dos dois que tiver menos carga. > > Um outro problema, tabelas que usam sequence como chave primaria. No > pgpool-II para resolver esse impasse ele tem o paramentro > insert_lock => Replicating a table with SERIAL data type, the SERIAL column > value may differ between the backends. > esse parametro loca a tabela em cada insert into para que o valor da > sequence fique indentico em cada no, para uma grande cargar de dados acho > inviavel. > O pgcluster não vi nada com relação a isso, no meu teste aconteceu o > sequinte: > Fiz un insert para inserir maria no banco o id seria "1" ao inserir maria > conectei no loadbalancer e ele me enviou para o servidor 2 > e fui inserir joão no server 1 e 3 maria fiocu com id "1" e joão id "2" no > server 3 maria ficou com id "2" e joão id "1" os id ficaram > diferentes isso não poderia acorrer. > > > Acho que um dos grandes problemas da replicação multimaster e reolver o > impasse da sequence se alguem tiver alguma outra sugestão ficarei grato. > -- > View this message in context: > http://www.nabble.com/Replica%C3%A7%C3%A3o-Multi-master-pglcuster---pgpool-II-ou-Outro-tp22928770p22928770.html > Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
