Re: [pgbr-geral] Replicação Multi-Master
Treços do teu email: "Há tabelas "globais" onde apenas um servidor pode gravar" - Se esse servidor cair ??? Ou seja você centralizou, qual a diferença de colocar a aplicação em um data center, ou seja se você depende de um central não há porque ter as "locais" afinal não vai funcionar sem as "globais" não é? Ou entendi errado? "Meu ERP usa um framework de persistência" - Opção de cada desenvolver, eu por experiência recomendo passar longe desse tipo de coisa. Tomara que não acontece com você mas o dia que resolver dar pau, reze. "grava numa tabela separada todos os comandos INSERT, UPDATE e DELETE" - Já citado antes a questão da integridade, mas como você falou dependendo do tipo de aplicação pode ser tolerável, mas não no meu ponto de vista. Hoje já temos infra suficiente para manter um link decente e se a desculpa for a rede que pode cair, vide a NFe e o SPED. "um processo que roda no CRON das lojas envia estes comandos para o servidor central" - No meu ponto de vista não é uma solução elegante. "O servidor central, por sua vez, envia para todas as lojas todas as atualizações que recebeu, também minuto a minuto." - Você centraliza, distribui e centraliza novamente. Se o teu servidor precisa mandar as atualização para as filiais porque não centraliza tudo de uma vez e deixa só o PDV de fora. São apenas ponderações baseado no email que você mandou, não estou dizendo que está errado, apenas que pode ser melhor e mais confiável. Abraço, Fabiano Machado Dias > Pode dar um exemplo dos "muitos pontos de falha" que você mencionou? Eu já > disse: não dá pra pensar que uma replicação multi-master vai estar com os > dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma > modificação feita numa filial pode levar 2 ou 3 minutos para chegar em > outra. > > Em 8 de julho de 2010 17:15, escreveu: > >> >> PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar >> independente. O que me referi foi a forma que você implementou o >> sistema. >> >> Att, >> Fabiano Machado Dias >> >> >> > > -- > Atenciosamente, > Alexsander da Rosa > Linux User #113925 > > "Extremismo na defesa da liberdade não é defeito. > Moderação na busca por justiça não é virtude." > -- Barry Goldwater > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
Pode dar um exemplo dos "muitos pontos de falha" que você mencionou? Eu já disse: não dá pra pensar que uma replicação multi-master vai estar com os dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação feita numa filial pode levar 2 ou 3 minutos para chegar em outra. Em 8 de julho de 2010 17:15, escreveu: > > PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar > independente. O que me referi foi a forma que você implementou o sistema. > > Att, > Fabiano Machado Dias > > > -- Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude." -- Barry Goldwater ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar independente. O que me referi foi a forma que você implementou o sistema. Att, Fabiano Machado Dias > Sabia que a legislação exige que os caixas com ECF continuem emitindo > cupons > mesmo com a rede LOCAL derrubada? Se você cortar com um alicate o cabo de > rede, o PDV tem que continuar funcionando. Isto existe para evitar que > sonegadores parem de emitir cupons mas sigam vendendo, com a desculpa de > que > "o sistema está fora do ar". A integridade vai pro espaço por exigência da > legislação... procure no Google sobre coisas como PAF, ECF, TEF, etc. > > Todas as grandes redes de supermercados possuem bancos de dados locais, um > em cada caixa. Alguns são MySQL, outros são arquivos DBF, mas todos -- por > exigência legal -- possuem dados locais. Neste contexto, pensar em > "hospedar > em Data Center" não faz o menor sentido: o Walmart, por exemplo, recebe > dados das filiais em nivel GLOBAL de hora em hora. Para uma rede menor, um > atraso de um minuto está de bom tamanho. > > Em 8 de julho de 2010 15:09, Ralf Schlindwein > escreveu: > >> Faça uma relação hospedar em um DataCenter confiável X valor >> funcionários >> parados. >> Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e >> Servidor e fique feliz somente gerenciando a sua TI. >> >> >> >> >> >> Em 8 de julho de 2010 15:02, Alexsander Rosa >> escreveu: >> >>> Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que >>> tem >>> gente que acha aceitável deixar os funcionários de braços cruzados >>> informando aos clientes "o sistema está fora do ar", mas no comércio o >>> furo >>> é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos >>> postes >>> foram roubados várias vezes seguidas, logo após a reposição. Somente >>> quando >>> a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar >>> mais >>> de alguns dias online. >>> >>> Se a replicação multi-master tiver sido prevista desde o início, a >>> integridade pode ser mantida dentro de alguma tolerância se algumas >>> restrições forem usadas. Existem várias coisas que a aplicação não >>> permite >>> fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. >>> Não >>> dá pra pensar que uma replicação multi-master vai estar com os dados >>> 100% >>> iguais em todos os servidores ao mesmo tempo, é óbvio que uma >>> modificação >>> feita numa filial pode levar 2 ou 3 minutos para chegar em outra. >>> >>> Em 8 de julho de 2010 14:03, escreveu: >>> >>> Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição. Meu amigo, você já pensou em centralizar essa sua aplicação? Você tem muitos pontos de falha, só por curiosidade como fica a integridade do seu sistema? Att, Fabiano Machado Dias > -- > Atenciosamente, > Alexsander da Rosa > Linux User #113925 > > "Extremismo na defesa da liberdade não é defeito. > Moderação na busca por justiça não é virtude." > -- Barry Goldwater > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ajuda com Monitoramento do BD.
Olá, Em 7 de julho de 2010 23:00, Carlos Augusto Machado escreveu: > Caros, > > Estou fazendo meu TCC sobre melhoria de performance em BD implementados > sobre o PostgreSQL. > Muito legal :) > > O trabalho tem duas seções específicas, as quais estou começando a > desenvolver exemplos práticos: > - Otimização de índices > - Otimização de consultas > Primeira dúvida. O que você chama de otimização de índices? Criação de um índice para ver se melhora a performance? > > Em ambos os casos, vou precisar monitorar um BD para apresentar os > problemas antes de otimizar, as soluções dadas e como ficou o desempenho > após a solução. > Você tem um banco de dados para isso? > > Para isso, venho até a lista para pedir apoio e dicas. > Meu ambiente de trabalho é um notebook com Windows Seven, PostgreSQL 8.4, > 3GB RAM. > Também posso simular ambientes com máquina virtual rodando Windows XP ou > Linux. > Isso não seria problema. > > Quanto ao monitoramento, pensei em usar uma ferramenta própria para essa > atividade. > Que tipo de ferramenta? Você já pensou em utilizar as views de sistema? - pg_stat_activity - pg_stat_user_tables - pg_stat_user_indexes Além disso tem o pg_fouine [1] onde você pode gerar as consultas utilizadas pelo sistema. > Estudei o BenchmarkSQL, porém ele analisa a configuração do ambiente e > hardware, usando um esquema de BD próprio para seu tipo de teste (criando > tabelas próprias e definindo pesos para consultas). > Você pode usar o pgtune [2] para auxiliar e ajudar na configuração dos parâmetros de configuração. No entanto, se eu precisar analisar o BD de uma aplicação qualquer, pelo que > entendi, o benchmarkSQL não vai ser tão útil. > Então pergunto, há alguma ferramenta que faça o monitoramento de um BD já > existente? (PS. Preferencialmente livre e que rode em Windows). > Como assim ferramenta de um BD já existente? > > Uma alternativa que verifiquei é o uso do comando EXPLAIN. Esse comando se > aplica mais para a otimização de consultas e, nesse caso, eu preciso saber > antecipadamente quais as consultas que deverão ser analisadas. > O comando EXPLAIN mostra o plano de execução de cada consulta, porém para ele funcionar bem é necessário que as estatísticas do banco estejam atualizadas, vide comando ANALYZE do PostgreSQL. > A dúvida é como descobrir quais são as consultas que precisam ser analisada > em um BD qualquer. > Isso depende muito. Aconselho em primeiro lugar você aplicar o pg_fouine para ler as consultas geradas pela aplicação, a partir dai você tem que trabalhar nas consultas que podem trazer um ganho maior para um contexto global. > > Por fim, alguem sabe indicar onde poderia encontrar BDs PostgreSQL para > teste, sem precisar criar um ou mais específicos para o trabalho? > Isso é muito complicado, dificilmente você vai achar um banco pronto de testes para você aplicar testes de desempenho, eu iria sugerir você montar um ambiente para isso, e popular com bastantes dados as tabelas para ai sim pode trabalhar esta questão. Um bom ponto de início pode ser o pagila [3]. [1] http://pgfouine.projects.postgresql.org/ [2] http://pgfoundry.org/projects/pgtune/ [3] http://pgfoundry.org/projects/dbsamples/ > -- > Att, > Carlos Augusto Machado > Email: gguto...@gmail.com > MSN: gutinhomach...@gmail.com > Fone: (49) 88532089 > > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Re -Replicação Multi Master
Pessoal, Seguinte temos hoje, um banco local, 2 bancos em filiais diferentes, rodando a mesma aplicação, com o pgpool consigo sincronizar estes dados , seja daonde esse dado for inserido, so que o grande detalhe do pgpool, é que estamos sincronizando via conexão de internet, e ele está lento para tal tarefa, tem como fazer que ele só faça inserts e drops, sem realizar selects nestes nós do pgpool? Pois é nesta hora que ele acaba ficando lento. Lucas Lima ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Ajuda com Monitoramento do BD.
Caros, Estou fazendo meu TCC sobre melhoria de performance em BD implementados sobre o PostgreSQL. O trabalho tem duas seções específicas, as quais estou começando a desenvolver exemplos práticos: - Otimização de índices - Otimização de consultas Em ambos os casos, vou precisar monitorar um BD para apresentar os problemas antes de otimizar, as soluções dadas e como ficou o desempenho após a solução. Para isso, venho até a lista para pedir apoio e dicas. Meu ambiente de trabalho é um notebook com Windows Seven, PostgreSQL 8.4, 3GB RAM. Também posso simular ambientes com máquina virtual rodando Windows XP ou Linux. Quanto ao monitoramento, pensei em usar uma ferramenta própria para essa atividade. Estudei o BenchmarkSQL, porém ele analisa a configuração do ambiente e hardware, usando um esquema de BD próprio para seu tipo de teste (criando tabelas próprias e definindo pesos para consultas). No entanto, se eu precisar analisar o BD de uma aplicação qualquer, pelo que entendi, o benchmarkSQL não vai ser tão útil. Então pergunto, há alguma ferramenta que faça o monitoramento de um BD já existente? (PS. Preferencialmente livre e que rode em Windows). Uma alternativa que verifiquei é o uso do comando EXPLAIN. Esse comando se aplica mais para a otimização de consultas e, nesse caso, eu preciso saber antecipadamente quais as consultas que deverão ser analisadas. A dúvida é como descobrir quais são as consultas que precisam ser analisada em um BD qualquer. Por fim, alguem sabe indicar onde poderia encontrar BDs PostgreSQL para teste, sem precisar criar um ou mais específicos para o trabalho? -- Att, Carlos Augusto Machado Email: gguto...@gmail.com MSN: gutinhomach...@gmail.com Fone: (49) 88532089 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
Boa Tarde a todos... Ótima observação Alexsander e isso falando dos relacionais, até chegar no RPAS, Oracle Retail. Não vi com bons olhos a solução dele, para não falar outra coisa... [] Att, Kaui Aires DBA (Oracle, PostgreSql), System Analyst, Security Analyst Skype: kauiaires Campaign: "Before you ask: Search on google.com" Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. Em 8 de julho de 2010 15:37, Alexsander Rosa escreveu: > Sabia que a legislação exige que os caixas com ECF continuem emitindo > cupons mesmo com a rede LOCAL derrubada? Se você cortar com um alicate o > cabo de rede, o PDV tem que continuar funcionando. Isto existe para evitar > que sonegadores parem de emitir cupons mas sigam vendendo, com a desculpa de > que "o sistema está fora do ar". A integridade vai pro espaço por exigência > da legislação... procure no Google sobre coisas como PAF, ECF, TEF, etc. > > Todas as grandes redes de supermercados possuem bancos de dados locais, um > em cada caixa. Alguns são MySQL, outros são arquivos DBF, mas todos -- por > exigência legal -- possuem dados locais. Neste contexto, pensar em "hospedar > em Data Center" não faz o menor sentido: o Walmart, por exemplo, recebe > dados das filiais em nivel GLOBAL de hora em hora. Para uma rede menor, um > atraso de um minuto está de bom tamanho. > > Em 8 de julho de 2010 15:09, Ralf Schlindwein escreveu: > >> Faça uma relação hospedar em um DataCenter confiável X valor funcionários >> parados. >> Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e >> Servidor e fique feliz somente gerenciando a sua TI. >> >> >> >> >> >> Em 8 de julho de 2010 15:02, Alexsander Rosa >> escreveu: >> >>> Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem >>> gente que acha aceitável deixar os funcionários de braços cruzados >>> informando aos clientes "o sistema está fora do ar", mas no comércio o furo >>> é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes >>> foram roubados várias vezes seguidas, logo após a reposição. Somente quando >>> a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais >>> de alguns dias online. >>> >>> Se a replicação multi-master tiver sido prevista desde o início, a >>> integridade pode ser mantida dentro de alguma tolerância se algumas >>> restrições forem usadas. Existem várias coisas que a aplicação não permite >>> fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não >>> dá pra pensar que uma replicação multi-master vai estar com os dados 100% >>> iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação >>> feita numa filial pode levar 2 ou 3 minutos para chegar em outra. >>> >>> Em 8 de julho de 2010 14:03, escreveu: >>> >>> Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição. Meu amigo, você já pensou em centralizar essa sua aplicação? Você tem muitos pontos de falha, só por curiosidade como fica a integridade do seu sistema? Att, Fabiano Machado Dias > -- > Atenciosamente, > Alexsander da Rosa > Linux User #113925 > > "Extremismo na defesa da liberdade não é defeito. > Moderação na busca por justiça não é virtude." > -- Barry Goldwater > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
Sabia que a legislação exige que os caixas com ECF continuem emitindo cupons mesmo com a rede LOCAL derrubada? Se você cortar com um alicate o cabo de rede, o PDV tem que continuar funcionando. Isto existe para evitar que sonegadores parem de emitir cupons mas sigam vendendo, com a desculpa de que "o sistema está fora do ar". A integridade vai pro espaço por exigência da legislação... procure no Google sobre coisas como PAF, ECF, TEF, etc. Todas as grandes redes de supermercados possuem bancos de dados locais, um em cada caixa. Alguns são MySQL, outros são arquivos DBF, mas todos -- por exigência legal -- possuem dados locais. Neste contexto, pensar em "hospedar em Data Center" não faz o menor sentido: o Walmart, por exemplo, recebe dados das filiais em nivel GLOBAL de hora em hora. Para uma rede menor, um atraso de um minuto está de bom tamanho. Em 8 de julho de 2010 15:09, Ralf Schlindwein escreveu: > Faça uma relação hospedar em um DataCenter confiável X valor funcionários > parados. > Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e > Servidor e fique feliz somente gerenciando a sua TI. > > > > > > Em 8 de julho de 2010 15:02, Alexsander Rosa > escreveu: > >> Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem >> gente que acha aceitável deixar os funcionários de braços cruzados >> informando aos clientes "o sistema está fora do ar", mas no comércio o furo >> é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes >> foram roubados várias vezes seguidas, logo após a reposição. Somente quando >> a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais >> de alguns dias online. >> >> Se a replicação multi-master tiver sido prevista desde o início, a >> integridade pode ser mantida dentro de alguma tolerância se algumas >> restrições forem usadas. Existem várias coisas que a aplicação não permite >> fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não >> dá pra pensar que uma replicação multi-master vai estar com os dados 100% >> iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação >> feita numa filial pode levar 2 ou 3 minutos para chegar em outra. >> >> Em 8 de julho de 2010 14:03, escreveu: >> >> Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição. >>> >>> Meu amigo, você já pensou em centralizar essa sua aplicação? >>> >>> Você tem muitos pontos de falha, só por curiosidade como fica a >>> integridade do seu sistema? >>> >>> Att, >>> Fabiano Machado Dias >>> >>> -- Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude." -- Barry Goldwater ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Para onde envio sugestões para o ma nual do pg 9.0?
Andre Fernandes escreveu: > Estava mexendo com ECPG e percebi que o manual nao menciona qualquer > coisa quanto a Hosts arrays, mas, felizmente, isso existe no ECPG. Acho > que isso e algo muito importante de ser mencionado no manual, a > documentaçao do ECPG parece estar um pouco desatualizada com tudo que > existe, e, no meu caso pelo menos, atrapalha muito. > Sera que alguem aqui sabe para quem seria bacana mencionar isso para que > talvez no manual da versao 9.0 atualizem as informacoes do ECPG? > Documentar melhor o ECPG já está no TODO [1] a algum tempo. :( Existe uma pessoa [2] trabalhando na melhoria da documentação, espero que isso entre para a versão 9.0. Se tu quiser contribuir com documentação, basta mandar suas sugestões para pgsql-docs [3]. [1] http://wiki.postgresql.org/wiki/TODO [2] http://archives.postgresql.org/pgsql-docs/2010-07/msg00060.php [3] http://www.postgresql.org/community/lists/ -- 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
Re: [pgbr-geral] Replicação Multi-Master
Faça uma relação hospedar em um DataCenter confiável X valor funcionários parados. Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e Servidor e fique feliz somente gerenciando a sua TI. Em 8 de julho de 2010 15:02, Alexsander Rosa escreveu: > Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem > gente que acha aceitável deixar os funcionários de braços cruzados > informando aos clientes "o sistema está fora do ar", mas no comércio o furo > é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes > foram roubados várias vezes seguidas, logo após a reposição. Somente quando > a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais > de alguns dias online. > > Se a replicação multi-master tiver sido prevista desde o início, a > integridade pode ser mantida dentro de alguma tolerância se algumas > restrições forem usadas. Existem várias coisas que a aplicação não permite > fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não > dá pra pensar que uma replicação multi-master vai estar com os dados 100% > iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação > feita numa filial pode levar 2 ou 3 minutos para chegar em outra. > > Em 8 de julho de 2010 14:03, escreveu: > > Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição. >> >> Meu amigo, você já pensou em centralizar essa sua aplicação? >> >> Você tem muitos pontos de falha, só por curiosidade como fica a >> integridade do seu sistema? >> >> Att, >> Fabiano Machado Dias >> >> > Eu desenvolvi uma replicação que está sendo usada pelos meus clientes >> (ex: >> > www.casadopapel.com.br), mas meu ERP foi projetado levando isto em >> > consideração. Há tabelas "globais" onde apenas um servidor pode gravar >> -- >> > a >> > aplicação não deixa os usuários das lojas gravarem em tabelas como >> > "alíquotas de ICMS" ou "lista de UF". As demais são tabelas "locais" e >> > todas >> > possuem como parte da chave uma coluna "número da loja"; por exemplo o >> > pedido 1234 feito na loja 7 fica com número 1234/7. >> > >> > Meu ERP usa um framework de persistência que grava numa tabela separada >> > todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON >> > das >> > lojas envia estes comandos para o servidor central (a topologia é >> estrela) >> > de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as >> > lojas >> > todas as atualizações que recebeu, também minuto a minuto. >> > >> > > -- > Atenciosamente, > Alexsander da Rosa > Linux User #113925 > > "Extremismo na defesa da liberdade não é defeito. > Moderação na busca por justiça não é virtude." > -- Barry Goldwater > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Ralf Schlindwein Analista de Sistemas ralfoa...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem gente que acha aceitável deixar os funcionários de braços cruzados informando aos clientes "o sistema está fora do ar", mas no comércio o furo é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes foram roubados várias vezes seguidas, logo após a reposição. Somente quando a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais de alguns dias online. Se a replicação multi-master tiver sido prevista desde o início, a integridade pode ser mantida dentro de alguma tolerância se algumas restrições forem usadas. Existem várias coisas que a aplicação não permite fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não dá pra pensar que uma replicação multi-master vai estar com os dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação feita numa filial pode levar 2 ou 3 minutos para chegar em outra. Em 8 de julho de 2010 14:03, escreveu: > Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição. > > Meu amigo, você já pensou em centralizar essa sua aplicação? > > Você tem muitos pontos de falha, só por curiosidade como fica a > integridade do seu sistema? > > Att, > Fabiano Machado Dias > > > Eu desenvolvi uma replicação que está sendo usada pelos meus clientes > (ex: > > www.casadopapel.com.br), mas meu ERP foi projetado levando isto em > > consideração. Há tabelas "globais" onde apenas um servidor pode gravar -- > > a > > aplicação não deixa os usuários das lojas gravarem em tabelas como > > "alíquotas de ICMS" ou "lista de UF". As demais são tabelas "locais" e > > todas > > possuem como parte da chave uma coluna "número da loja"; por exemplo o > > pedido 1234 feito na loja 7 fica com número 1234/7. > > > > Meu ERP usa um framework de persistência que grava numa tabela separada > > todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON > > das > > lojas envia estes comandos para o servidor central (a topologia é > estrela) > > de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as > > lojas > > todas as atualizações que recebeu, também minuto a minuto. > > > -- Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude." -- Barry Goldwater ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição. Meu amigo, você já pensou em centralizar essa sua aplicação? Você tem muitos pontos de falha, só por curiosidade como fica a integridade do seu sistema? Att, Fabiano Machado Dias > Eu desenvolvi uma replicação que está sendo usada pelos meus clientes (ex: > www.casadopapel.com.br), mas meu ERP foi projetado levando isto em > consideração. Há tabelas "globais" onde apenas um servidor pode gravar -- > a > aplicação não deixa os usuários das lojas gravarem em tabelas como > "alíquotas de ICMS" ou "lista de UF". As demais são tabelas "locais" e > todas > possuem como parte da chave uma coluna "número da loja"; por exemplo o > pedido 1234 feito na loja 7 fica com número 1234/7. > > Meu ERP usa um framework de persistência que grava numa tabela separada > todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON > das > lojas envia estes comandos para o servidor central (a topologia é estrela) > de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as > lojas > todas as atualizações que recebeu, também minuto a minuto. > > Em 8 de julho de 2010 11:35, Lima - Lojas Fricke Ltda > escreveu: > >> Bom dia pessoal, >> >> Estamos implementando uma replicação (sincronização) de bases com o >> Postgres, >> Testamos o Pgpool mas ele não está funcionando legal com nossa >> aplicação, tem outro produto que faça isso melhor? >> >> -- >> Lucas Lima >> >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > > -- > Atenciosamente, > Alexsander da Rosa > Linux User #113925 > > "Extremismo na defesa da liberdade não é defeito. > Moderação na busca por justiça não é virtude." > -- Barry Goldwater > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
> Estamos implementando uma replicação (sincronização) de bases com o > Postgres, Testamos o Pgpool mas ele não está funcionando legal com > nossa aplicação, tem outro produto que faça isso melhor? > > -- Lucas Lima Seria mais simpático você fornecer o erro ou comportamento que você está chamando de "não está funcionando legal" pgpool e pgpool2 são softwares maduros, perfeitamente integrados com o PostgreSQL e não dá pra citar um produto "melhor". Ele pode apenas não estar adequado à sua solução ou vice-versa. Flavio Henrique A. Gurgel tel. 55-11-2125.4786 cel. 55-11-8389.7635 www.4linux.com.br FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
Eu desenvolvi uma replicação que está sendo usada pelos meus clientes (ex: www.casadopapel.com.br), mas meu ERP foi projetado levando isto em consideração. Há tabelas "globais" onde apenas um servidor pode gravar -- a aplicação não deixa os usuários das lojas gravarem em tabelas como "alíquotas de ICMS" ou "lista de UF". As demais são tabelas "locais" e todas possuem como parte da chave uma coluna "número da loja"; por exemplo o pedido 1234 feito na loja 7 fica com número 1234/7. Meu ERP usa um framework de persistência que grava numa tabela separada todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON das lojas envia estes comandos para o servidor central (a topologia é estrela) de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as lojas todas as atualizações que recebeu, também minuto a minuto. Em 8 de julho de 2010 11:35, Lima - Lojas Fricke Ltda escreveu: > Bom dia pessoal, > > Estamos implementando uma replicação (sincronização) de bases com o > Postgres, > Testamos o Pgpool mas ele não está funcionando legal com nossa > aplicação, tem outro produto que faça isso melhor? > > -- > Lucas Lima > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude." -- Barry Goldwater ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Para onde envio sugestões para o ma nual do pg 9.0?
Bom dia, Estava mexendo com ECPG e percebi que o manual nao menciona qualquer coisa quanto a Hosts arrays, mas, felizmente, isso existe no ECPG. Acho que isso e algo muito importante de ser mencionado no manual, a documentaçao do ECPG parece estar um pouco desatualizada com tudo que existe, e, no meu caso pelo menos, atrapalha muito. Sera que alguem aqui sabe para quem seria bacana mencionar isso para que talvez no manual da versao 9.0 atualizem as informacoes do ECPG? Abraços, -- André de Camargo Fernandes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação Multi-Master
Olá, Em 8 de julho de 2010 11:35, Lima - Lojas Fricke Ltda escreveu: > Bom dia pessoal, > > Estamos implementando uma replicação (sincronização) de bases com o > Postgres, > Testamos o Pgpool mas ele não está funcionando legal com nossa > aplicação, tem outro produto que faça isso melhor? > Não existe replicação A melhor que replicação B, e sim a replicação mais adequada ao ambiente. Você poderia descrever o seu ambiente. Qual a necessidade da replicação? Você precisa replicar todos os dados ou apenas uma porcentagem dos dados? A réplica precisa ficar disponível para consulta e/ou escrita ou apenas os dados replicados já são suficientes? > > -- > Lucas Lima > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Replicação Multi-Master
Bom dia pessoal, Estamos implementando uma replicação (sincronização) de bases com o Postgres, Testamos o Pgpool mas ele não está funcionando legal com nossa aplicação, tem outro produto que faça isso melhor? -- Lucas Lima ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] view entre dois bancos
então até poderia fazer ele em um só, mas o problema é que um dos bancos é de uma outra aplicação, que compartilha os dados com outros sistemas.. mas obigado pela ajuda de vcs...vou ver qual é a melhor solução quanto a performance. obrigado. anderson. Em 8 de julho de 2010 08:22, JotaComm escreveu: > Olá, > > Em 7 de julho de 2010 17:58, Anderson escreveu: > >> olá pessoal tudo blz gostaria de saber se há como criar uma view entre >> duas tabelas de bancos diferentes, os bancos estão no mesmo servidor. >> > > Sim. Isso é possível e para isso você pode usar o DBLink. Em meu blog tem > um exemplo de como fazer isso. > > Mas faço uma pergunta. Não seria melhor você ter um banco só e dividi-lo em > esquemas, assim você pode acessa-los diretamente simplesmente fazendo JOIN > com os objetos dos esquemas? > > >> >> se alguem puder manda alguma referencia se isso é posivel eu seria muito >> grato. >> >> até + >> >> anderson. >> >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > []s > -- > JotaComm > http://jotacomm.wordpress.com > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] view entre dois bancos
Olá, Em 7 de julho de 2010 17:58, Anderson escreveu: > olá pessoal tudo blz gostaria de saber se há como criar uma view entre > duas tabelas de bancos diferentes, os bancos estão no mesmo servidor. > Sim. Isso é possível e para isso você pode usar o DBLink. Em meu blog tem um exemplo de como fazer isso. Mas faço uma pergunta. Não seria melhor você ter um banco só e dividi-lo em esquemas, assim você pode acessa-los diretamente simplesmente fazendo JOIN com os objetos dos esquemas? > > se alguem puder manda alguma referencia se isso é posivel eu seria muito > grato. > > até + > > anderson. > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
