Eu tenho acompanhado a thread, mas para ser sincero, os primeiros posts me desencorajaram de uma resposta ou contribuição devido à confusão de terminologias e semântica
Ora se fala em replicar bases, outra em clusters. Se você puder dar uma descrição melhor, mais completa, e usando a terminologia correta, seria de grande ajuda para podermos ajudar. O Euler já passou uma lista de possíveis requerimentos a serem contemplados, baseado na sua descrição. É possível replicar 100 "bases" sim (isso quer dizer bancos de dados individuais provenientes de um servidor - postmaster - ou 100 servidores *individuais* cada um com um número X de bancos de dados?) Roberto 2011/3/28 Fábio Telles Rodriguez <[email protected]>: > Em 28 de março de 2011 08:46, Antonio Abner Junior > <[email protected]> escreveu: >> >> Euler Taveira, >> >> Quanto as implicações de infra ja havia analisado essas questões no >> entanto, vai ficar a critério do cliente definir a periodicidade da >> sicronização para que eu possa definir >> esses requisitos. >> >> Flavio Henrique, >> >> No meu caso como fiz a correção da minha necessidade é alta disponibilidade >> e sendo assim preciso que seja o database e não tabelas específicas. >> >> Fábio e Euler, >> >> Então é possível realizar esse cenário de alta disponibilidade de 100 bases >> para um único servidor ? Preciso saber se alguém ja passou por essa >> experiência, pois irei fazer um teste/laboratório proavavelmente com 10 >> bases de dados mas antes de demandar recursos, preciso saber se é possível a >> solução ou não com o sgbd PostgreSQL. Pelo que já verifiquei com a >> documentação é possível, mas na prática ainda não conheci nenhum caso ! > > Vamos avaliar as dificuldades, reforçando o que o Euler colocou > inicialmente (que eu acredito que sejam muitas): > > 1) Um servidor standby, em tese deve ter a mesma capacidade da > produção: ou seja: se você tem 100 servidores de produção, você deve > ter a capacidade de suportar a operação destas 100 bases no standby. > Se isso não for feito, quando a produção cair, o standby não vai > suportar o volume de operação da produção; > > *** O correto seria ter um servidor de standby para cada servidor de > produção. Isso faria mais sentido. > > 2) Um standby recebe pelo menos um log do WAL a cada X minutos. Se > você colocar um valor de 30 minutos, por exemplo, significa receber no > MÍNIMO 16MB a cada 30 minutos para cada base, em 100 bases seriam > 1.6GB a cada 30 minutos, no mínimo. Você vai precisar de banda para > receber isso tudo. Não é pouca coisa, certo? Claro, você pode pensar > em compactar os archives antes de enviar pela rede... mas então serão > 100 processos de descompactação rodando no mínimo a cada 30 minutos. > Claro, usar o standby por stream ao invés de log shipping seria muito > mais eficiente. Para isso você teria de utilizar o 9.0. > > 3) Não interessa se em cada filial tem uma, duas ou 100 bases no > cluster (entenda cluster como o conjunto de bases com o mesmo local > criado pelo initdb, mesmos processos e mesma porta), o standby irá > copiar TODO o cluster e não apenas uma parte. O Standby é uma > replicação de via única e que não copia pedaços de uma base. No lado > da produção, você pode ter apenas um cluster, no lado do standby vai > ter 100 clusters, cada um com um diretório único no initdb, com seus > processos únicos e porta única para cada cluster no standby. Você não > pode ter um único cluster no standby para todas as bases de produção. > Isso não é pouca coisa. Cada cluster terá uma meia-dúzia de processos. > 100 clusters, são pelo menos uns 600 processos. Vai precisar de muito > processador para manter tudo isso ativo. > > 4) E cada um destes clusters vão querer a sua quota de shared_memory. > Suponhamos que seja algo modesto, que você user por exemplo 256MB de > shared_memmory por cluster. Você vai precisar de 25GB só para começar > a subir as bases. Pensando em memória total, algo em torno de 64GB > sería o mínimo que você iria precisar. > > 5) A complexidade de administrar tudo isso é meio bizarra. Eu sempre > penso em servidor Standby como algo 1 para 1. Reproduzo fielmente o > ambiente da produção no Standby. Seria mais sensato fazer algo como > pegar as filiais mais próximas e uma ter o standby da outra. De forma > mais pontual. > > 6) Um dos princípios da alta disponibilidade é evitar os pontos de > falha. No caso você está concentrando toda a sua redundância num único > ponto de falha que é o único servidor standby. Quando este sair do ar, > você perde a alta disponibilidade em todos os demais. É um ponto de > falha muito grande, que torna o projeto ineficaz. > > Replicações centralizadas são bons para consolidação dos dados, mas aí > não estamos mais falando de standby. É outra coisa completamente > diferente. > > Uma observação: não utilize mais o modo digest para postar na lista. > > []s > Fábio Telles >> >> valews, >> >> Abner Jr -AJ >> >> 2011/3/27 <[email protected]> >>> >>> Send pgbr-geral mailing list submissions to >>> [email protected] >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> or, via email, send a message with subject or body 'help' to >>> [email protected] >>> >>> You can reach the person managing the list at >>> [email protected] >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of pgbr-geral digest..." >>> >>> >>> Tópicos de Hoje: >>> >>> 1. Re: Alta diposnibilidade/Replicação com Log Shipping >>> (Antonio Abner Junior) >>> 2. Re: Alta diposnibilidade/Replicação com Log Shipping >>> (Flavio Henrique Araque Gurgel) >>> 3. Re: Alta diposnibilidade/Replicação com Log Shipping >>> (Leandro DUTRA) >>> 4. Ultimo reset das estatísticas (Fábio Gibon - Comex System) >>> 5. Re: Ultimo reset das estatísticas (Euler Taveira de Oliveira) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Sat, 26 Mar 2011 12:59:43 -0300 >>> From: Antonio Abner Junior <[email protected]> >>> Subject: Re: [pgbr-geral] Alta diposnibilidade/Replicação com Log >>> Shipping >>> To: Fábio Telles Rodriguez <[email protected]> >>> Cc: Comunidade PostgreSQL Brasileira >>> <[email protected]> >>> Message-ID: >>> <[email protected]> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> Ola Fábio, >>> >>> Melhor falando o que eu preciso realizar é alta disponibilidade com Warm >>> Standby, uma vez que o modelo não permite a replicação(Master/Slave) com >>> Slony ou Londiste. >>> >>> Então a questão é se posso em um único servidor central criar as 100 bases >>> de dados(cluster de dados) em que será o espelho dos servidores >>> principais >>> e sendo assim a minha alta disponibilidade. >>> >>> valew pela força, >>> >>> Abner Junior >>> >>> 2011/3/26 Fábio Telles Rodriguez <[email protected]> >>> >>> > Em 25 de março de 2011 17:54, Antonio Abner Junior >>> > <[email protected]> escreveu: >>> > > >>> > > Galera estou com dúvida com a seguinte situação: >>> > > >>> > > Replicação(espelhamento) de 100 bases de dados(cluster de dados) em >>> > > todo >>> > o >>> > > Brasil para um site central. A forma que mais se adequa a situação é a >>> > > utilização do Warm Standby(Log Shipping) no entanto estou com a >>> > > seguinte >>> > > dúvida ! >>> > > Será possível eu replicar as 100 bases de dados(cluster de dados) para >>> > > um >>> > > único servidor no site sendo que nesse servidor eu criaria um cluster >>> > > de >>> > > dados para cada cluster de dados(site) origem. Estou certo de que para >>> > cada >>> > > cluster de dados no site central será necessário realizar os ajustes >>> > > nas >>> > > configurações de porta, postgresql, pg_hba e etc ! Isso funciona ? >>> > > Alguém >>> > ja >>> > > teve algo parecido ? >>> > >>> > Veja, existem várias formas de replicação. Standby é uma solução para >>> > alta disponibilidade. Me parece que o que você quer é uma solução >>> > "matriz/filial". Dê uma olhada no Slony e no Londiste para isso. Acho >>> > que são ferramentas mais adequadas para o seu caso. Mas.... se a sua >>> > aplicação não estiver modelada para lidar com isso, você verá que >>> > nenhuma solução será boa o suficiente, pois você terá dificuldades em >>> > consolidar os dados na matriz. >>> > >>> > []s >>> > -- >>> > Atenciosamente, >>> > Fábio Telles Rodriguez >>> > blog: http://www.midstorm.org/~telles/ >>> > e-mail / gtalk / MSN: [email protected] >>> > Skype: fabio_telles >>> > >>> >>> >>> >>> -- >>> Antonio Abner Junior -AJ >>> -------------- Próxima Parte ---------- >>> Um anexo em HTML foi limpo... >>> URL: >>> http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20110326/1a526f6f/attachment-0001.htm >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Sat, 26 Mar 2011 14:43:25 -0300 >>> From: Flavio Henrique Araque Gurgel <[email protected]> >>> Subject: Re: [pgbr-geral] Alta diposnibilidade/Replicação com Log >>> Shipping >>> To: Comunidade PostgreSQL Brasileira >>> <[email protected]> >>> Message-ID: >>> <[email protected]> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Fiz um desenho desse tipo com o Rubyrep, usando a versão empacotada >>> com JRuby. Eram 10 bancos de dados. Nem todas as tabelas eram >>> replicadas. >>> A vantagem é que você só precisaria de um servidor, com um cluster >>> (instância) PostgreSQL para receber as réplicas. >>> >>> >>> Em 26 de março de 2011 12:59, Antonio Abner Junior >>> <[email protected]> escreveu: >>> > Ola Fábio, >>> > >>> > Melhor falando o que eu preciso realizar é alta disponibilidade com Warm >>> > Standby, uma vez que o modelo não permite a replicação(Master/Slave) com >>> > Slony ou Londiste. >>> > >>> > Então a questão é se posso em um único servidor central criar as 100 >>> > bases >>> > de dados(cluster de dados) em que será o espelho dos servidores >>> > principais >>> > e sendo assim a minha alta disponibilidade. >>> > >>> > valew pela força, >>> > >>> > Abner Junior >>> > >>> > 2011/3/26 Fábio Telles Rodriguez <[email protected]> >>> >> >>> >> Em 25 de março de 2011 17:54, Antonio Abner Junior >>> >> <[email protected]> escreveu: >>> >> > >>> >> > Galera estou com dúvida com a seguinte situação: >>> >> > >>> >> > Replicação(espelhamento) de 100 bases de dados(cluster de dados) em >>> >> > todo >>> >> > o >>> >> > Brasil para um site central. A forma que mais se adequa a situação é >>> >> > a >>> >> > utilização do Warm Standby(Log Shipping) no entanto estou com a >>> >> > seguinte >>> >> > dúvida ! >>> >> > Será possível eu replicar as 100 bases de dados(cluster de dados) >>> >> > para >>> >> > um >>> >> > único servidor no site sendo que nesse servidor eu criaria um cluster >>> >> > de >>> >> > dados para cada cluster de dados(site) origem. Estou certo de que >>> >> > para >>> >> > cada >>> >> > cluster de dados no site central será necessário realizar os ajustes >>> >> > nas >>> >> > configurações de porta, postgresql, pg_hba e etc ! Isso funciona ? >>> >> > Alguém ja >>> >> > teve algo parecido ? >>> >> >>> >> Veja, existem várias formas de replicação. Standby é uma solução para >>> >> alta disponibilidade. Me parece que o que você quer é uma solução >>> >> "matriz/filial". Dê uma olhada no Slony e no Londiste para isso. Acho >>> >> que são ferramentas mais adequadas para o seu caso. Mas.... se a sua >>> >> aplicação não estiver modelada para lidar com isso, você verá que >>> >> nenhuma solução será boa o suficiente, pois você terá dificuldades em >>> >> consolidar os dados na matriz. >>> >> >>> >> []s >>> >> -- >>> >> Atenciosamente, >>> >> Fábio Telles Rodriguez >>> >> blog: http://www.midstorm.org/~telles/ >>> >> e-mail / gtalk / MSN: [email protected] >>> >> Skype: fabio_telles >>> > >>> > >>> > >>> > -- >>> > Antonio Abner Junior -AJ >>> > >>> > _______________________________________________ >>> > pgbr-geral mailing list >>> > [email protected] >>> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> > >>> > >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Sat, 26 Mar 2011 20:13:29 -0300 >>> From: Leandro DUTRA <[email protected]> >>> Subject: Re: [pgbr-geral] Alta diposnibilidade/Replicação com Log >>> Shipping >>> To: Comunidade PostgreSQL Brasileira >>> <[email protected]> >>> Message-ID: >>> <[email protected]> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> 2011/3/26 Flavio Henrique Araque Gurgel <[email protected]>: >>> > Fiz um desenho >>> >>> Projeto? >>> >>> >>> >>> -- >>> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra >>> +55 (61) 3546 7191 gTalk: xmpp:[email protected] >>> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 >>> BRAZIL GMT-3 MSN: msnim:[email protected] >>> >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Sun, 27 Mar 2011 01:54:09 -0300 >>> From: Fábio Gibon - Comex System <[email protected]> >>> Subject: [pgbr-geral] Ultimo reset das estatísticas >>> To: "PostgreSQL - BR List" <[email protected]> >>> Message-ID: <00d701cbec3b$058a5ad0$6400a8c0@gibon> >>> Content-Type: text/plain; charset="windows-1252" >>> >>> Olá Pessoal, >>> existe alguma informação no banco da data/hora da última vez que as >>> estatísticas foram resetadas? >>> >>> abraços >>> >>> Fábio Henrique Gibon >>> -------------- Próxima Parte ---------- >>> Um anexo em HTML foi limpo... >>> URL: >>> http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20110327/53439b64/attachment-0001.htm >>> >>> ------------------------------ >>> >>> Message: 5 >>> Date: Sun, 27 Mar 2011 10:48:47 -0300 >>> From: Euler Taveira de Oliveira <[email protected]> >>> Subject: Re: [pgbr-geral] Ultimo reset das estatísticas >>> To: [email protected] >>> Message-ID: <[email protected]> >>> Content-Type: text/plain; charset=windows-1252; format=flowed >>> >>> Em 27-03-2011 01:54, Fábio Gibon - Comex System escreveu: >>> > existe alguma informação no banco da data/hora da última vez que as >>> > estatísticas foram resetadas? >>> > >>> Não. Mas haverá tal informação na 9.1. >>> >>> >>> -- >>> 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 >>> >>> >>> Fim da Digest pgbr-geral, volume 27, assunto 65 >>> *********************************************** >> >> >> >> -- >> Antonio Abner Junior -AJ >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > > -- > Atenciosamente, > Fábio Telles Rodriguez > blog: http://www.midstorm.org/~telles/ > e-mail / gtalk / MSN: [email protected] > Skype: fabio_telles > _______________________________________________ > 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
