Em 28 de março de 2011 08:46, Antonio Abner Junior <antonio.abne...@gmail.com> 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 <pgbr-geral-requ...@listas.postgresql.org.br> >> >> Send pgbr-geral mailing list submissions to >> pgbr-geral@listas.postgresql.org.br >> >> 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 >> pgbr-geral-requ...@listas.postgresql.org.br >> >> You can reach the person managing the list at >> pgbr-geral-ow...@listas.postgresql.org.br >> >> 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 <antonio.abne...@gmail.com> >> Subject: Re: [pgbr-geral] Alta diposnibilidade/Replicação com Log >> Shipping >> To: Fábio Telles Rodriguez <fabio.tel...@gmail.com> >> Cc: Comunidade PostgreSQL Brasileira >> <pgbr-geral@listas.postgresql.org.br> >> Message-ID: >> <AANLkTi=n7hqNmXVRQho5YXNfqBhgKqsxDcgK=lr-o...@mail.gmail.com> >> 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 <fabio.tel...@gmail.com> >> >> > Em 25 de março de 2011 17:54, Antonio Abner Junior >> > <antonio.abne...@gmail.com> 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: fabio.tel...@gmail.com >> > 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 <fha...@gmail.com> >> Subject: Re: [pgbr-geral] Alta diposnibilidade/Replicação com Log >> Shipping >> To: Comunidade PostgreSQL Brasileira >> <pgbr-geral@listas.postgresql.org.br> >> Message-ID: >> <AANLkTikNsMKpXwsG4HfjC1gRRN=4xejr-e+g-fs84...@mail.gmail.com> >> 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 >> <antonio.abne...@gmail.com> 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 <fabio.tel...@gmail.com> >> >> >> >> Em 25 de março de 2011 17:54, Antonio Abner Junior >> >> <antonio.abne...@gmail.com> 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: fabio.tel...@gmail.com >> >> Skype: fabio_telles >> > >> > >> > >> > -- >> > Antonio Abner Junior -AJ >> > >> > _______________________________________________ >> > pgbr-geral mailing list >> > pgbr-geral@listas.postgresql.org.br >> > 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 <leandro.gfc.du...@gmail.com> >> Subject: Re: [pgbr-geral] Alta diposnibilidade/Replicação com Log >> Shipping >> To: Comunidade PostgreSQL Brasileira >> <pgbr-geral@listas.postgresql.org.br> >> Message-ID: >> <AANLkTinMthDEe1x2SFxXXuXJ=-pujmodzqb0qoufe...@mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> 2011/3/26 Flavio Henrique Araque Gurgel <fha...@gmail.com>: >> > Fiz um desenho >> >> Projeto? >> >> >> >> -- >> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra >> +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org >> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 >> BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm >> >> >> ------------------------------ >> >> Message: 4 >> Date: Sun, 27 Mar 2011 01:54:09 -0300 >> From: Fábio Gibon - Comex System <gi...@comexsystem.com.br> >> Subject: [pgbr-geral] Ultimo reset das estatísticas >> To: "PostgreSQL - BR List" <pgbr-geral@listas.postgresql.org.br> >> 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 <eu...@timbira.com> >> Subject: Re: [pgbr-geral] Ultimo reset das estatísticas >> To: pgbr-geral@listas.postgresql.org.br >> Message-ID: <4d8f403f.7050...@timbira.com> >> 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 >> pgbr-geral@listas.postgresql.org.br >> 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 > pgbr-geral@listas.postgresql.org.br > 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: fabio.tel...@gmail.com Skype: fabio_telles _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
