charles andre escreveu: > 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 ? Mesmo em uma base de dados com dezenas de terabytes, o que você precisa é copiar somente os logs de transação (em sistemas de baixa alteração isso pode ser poucos megabytes). O rsync trava o que?
> Ele não deveria sincronizar so os dados que foram alterados depois que o > server caiu em vez de mandar tudo de novo ? > Sim. E é isso que as técnicas de warm/hot standby e replicação fazem. > 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. Isso porque o pgpool-II tenta resolver um problema (que ao meu ver pertence a própria arquitetura do PostgreSQL) a nível de aplicação. > 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. Como eu disse, esse problema não foi resolvido no PostgreSQL. Espero poder trabalhar nisso (replicação multi-mestre) ao longo desse ano. -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
