Re: [pgbr-geral] pg_dump remoto lento
Exatamente Matheus, a Amazon realmente não disponibiliza nenhuma forma de dump, apenas o PITR, mas creio que deva estar no radar deles vocês poder agendar dumps e jogar diretamente ao S3, seria uma ótima funcionalidade, já que hoje nos fazemos esse dump apenas para jogar para o S3 :). Tenho vários bancos rodando na AWS e, por enquanto, nenhum em franca produção com o RDS, somente um pequeno servidor que não é crítico e tem um dump de algumas dezenas de megabytes. Eu, pessoalmente, não gosto de "perder a mão" do sistema operacional onde rodo meus bancos. Apesar de o RDS ter coisas interessantes como IOPS garantido, replicação multizona síncrona e possibilidade de mexer no arquivo de configuração, não se tem controle do S.O. e delega-se isso à Amazon. Tem quem prefira dessa forma. Note que você não pode fazer coisas básicas como fazer um dump dentro do seu servidor, criar tablespaces ou monitorar coisas idiotas como conexões de rede. Você terá dificuldades em tirar SEUS dados do serviço, como já está vendo. Imagine sua base na ordem de centenas de gigabytes e você decide migrar pra outro servidor fora da AWS. Poderá ser impossível ou necessitar de uma interrupção de serviço de vários dias. Mas estou fazendo mais alguns testes, pq pelo que percebi agora, pode ser algum bug de comunicação entre as VPCs. Considere instalar sua máquina na Amazon com seu S.O. de escolha, leva poucos cliques, o PostgreSQL se instala em minutos. E dá pra automatisar tudo, tá na moda hoje usar Docker. Eu tenho automatização com Ansible (um parente do Puppet) e criar uma instância AWS provisionada e pronta, com escravo e backup com Wal-E pro S3 leva alguns minutos. O custo é próximo ao RDS. Para instâncias como o RDS, considere também estudar o serviço da Heroku. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Function para remover session prepared
Olá Fabrízio, Obrigado pela resposta. De fato não é a melhor solução, mas o que ocorre é que realmente a app está fazendo isso de forma indevida, e fica esquecendo estas sessios por lá. O correto seria ajustar no código, porém, infelizmente a instituição que desenvolveu app não está disposto a fazer tal análise. E tome top-posting... Colega, se a "instituição" que desenvolveu o "app" não está disposta a fazer tal análise, ela não deveria ter começado o desenvolvimento. Isso se chama BUG e BUG a gente tem que matar na raiz. Senão você vai sofrer no mármore do inferno da produção ignorada, sozinho, sem piedade, como castigo de omissão :) Como opção, você pode pedir demissão ;) Sou capaz de apostar que é uma aplicação Java que usa Spring Framework, e está rodando sob JBoss ou Tomcat, acertei? []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_dump remoto lento
Em 13 de maio de 2015 04:14, Flavio Henrique Araque Gurgel escreveu: > Exatamente Matheus, a Amazon realmente não disponibiliza nenhuma forma >> de dump, apenas o PITR, mas creio que deva estar no radar deles vocês >> poder agendar dumps e jogar diretamente ao S3, seria uma ótima >> funcionalidade, já que hoje nos fazemos esse dump apenas para jogar para >> o S3 :). >> > > Tenho vários bancos rodando na AWS e, por enquanto, nenhum em franca > produção com o RDS, somente um pequeno servidor que não é crítico e tem um > dump de algumas dezenas de megabytes. > > Eu, pessoalmente, não gosto de "perder a mão" do sistema operacional onde > rodo meus bancos. Apesar de o RDS ter coisas interessantes como IOPS > garantido, replicação multizona síncrona e possibilidade de mexer no > arquivo de configuração, não se tem controle do S.O. e delega-se isso à > Amazon. Tem quem prefira dessa forma. > > Note que você não pode fazer coisas básicas como fazer um dump dentro do > seu servidor, criar tablespaces ou monitorar coisas idiotas como conexões > de rede. Você terá dificuldades em tirar SEUS dados do serviço, como já > está vendo. Imagine sua base na ordem de centenas de gigabytes e você > decide migrar pra outro servidor fora da AWS. Poderá ser impossível ou > necessitar de uma interrupção de serviço de vários dias. > > Mas estou fazendo mais alguns testes, pq pelo que percebi agora, pode >> ser algum bug de comunicação entre as VPCs. >> > > Considere instalar sua máquina na Amazon com seu S.O. de escolha, leva > poucos cliques, o PostgreSQL se instala em minutos. E dá pra automatisar > tudo, tá na moda hoje usar Docker. Eu tenho automatização com Ansible (um > parente do Puppet) e criar uma instância AWS provisionada e pronta, com > escravo e backup com Wal-E pro S3 leva alguns minutos. O custo é próximo ao > RDS. > > Para instâncias como o RDS, considere também estudar o serviço da Heroku. > Utilizamos o RDS apenas para bancos de terceiros em que as equipes responsáveis pelos serviços administram, mas o nosso Core está em uma instancia EC2, justamente para não perdemos o poder sobre o banco totalmente, e sobre coisas simples, como logs por ex. Mas confirmando, realmente o problema era a comunição entre a VPC e a maquina que está como "publica", por serem 2 maquinas da Amazon, a Amazon deveria fazer o roteamento diretamente entre as máquinas, porém isso não está ocorrendo, já abri um chamado e vamos ver o pq disso. Talvez com o RDS esse reteamento não funcione, mas entre maquinas EC2 funciona perfeitamente, latência de 1ms. Muito obrigado a todos pela ajuda. > > []s > Flavio Gurgel > > ___ > 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
[pgbr-geral] Erros no Pgpool
Bom dia pessoal. Estou usando o pgpool pela primeira vez e tenho algumas dúvidas quanto as mensagens que aparecem no log. Hoje tivemos um problema e tive que redirecionar pro banco de Produção, mas não tenho certeza se o erro foi no pgpool ou na aplicação. Tenho recebido os 3 erros abaixo. Alguém sabe se é normal essa quantidade de erros e se isso é "culpa" da aplicação ou a má configuração do pgpool? ERROR: pid 30287: do_query: error message from backend: deadlock detected. Exit this session. ERROR: pid 30740: do_query: error message from backend: cannot execute LOCK TABLE during recovery. Exit this session. LOG: pid 30723: pool_send_and_wait: Error or notice message from backend: : DB node id: 1 backend pid: 80643 statement: UPDATE usuario_acesso SET log_data = now() WHERE id_usuario = 262 message: cannot execute UPDATE in a read-only transaction Desculpem qualquer coisa, Grato desde já. Marcell Marcell Ribeiro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erros no Pgpool
2015-05-13 10:58 GMT-03:00 Marcell Ribeiro : > Bom dia pessoal. Estou usando o pgpool pela primeira vez e tenho algumas > dúvidas quanto as mensagens que aparecem no log. Hoje tivemos um problema e > tive que redirecionar pro banco de Produção, mas não tenho certeza se o > erro foi no pgpool ou na aplicação. > > Tenho recebido os 3 erros abaixo. Alguém sabe se é normal essa quantidade > de erros e se isso é "culpa" da aplicação ou a má configuração do pgpool? > > ERROR: pid 30287: do_query: error message from backend: deadlock detected. > Exit this session. > > ERROR: pid 30740: do_query: error message from backend: cannot execute > LOCK TABLE during recovery. Exit this session. > > LOG: pid 30723: pool_send_and_wait: Error or notice message from > backend: : DB node id: 1 backend pid: 80643 statement: UPDATE > usuario_acesso SET log_data = now() WHERE id_usuario = 262 message: cannot > execute UPDATE in a read-only transaction > Me parece uma configuração errada. O pgPool-II usa LOCK TABLE quando está fazendo replicação própria, por comandos (o que eu não recomendo). Mas você parece estar usando "streaming replication". Poderia passar as configurações do seu pgPool-II e explicar o porquê ou pra quê está usando esta ferramenta? Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Linked Server do SQL Server
Pessoal, boa tarde. PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit. Preciso fazer uma consulta no PostgreSQL que irá retornar um número de colunas dinamicamente, tanto a quantidade como os nomes das colunas são variáveis. Pesquisei e não encontrei nenhuma forma de criar uma consulta que tenha um retorno "SETOF record" dinâmico. Para tal (não sei se é a melhor solução), criei uma função que monta a consulta e grava o resultado em uma tabela temporária. Dessa forma no PostgreSQL eu executo a função que cria a tabela temporária (select ou do) e depois faço um select na tabela temporária. Está da seguinte maneira: select portal.sp_produtos_vencer_lojas(2015,5); select * from tb_tmp_produtos_vencer_lojas; Até ai tudo bem. O problema é que vou precisar ler essas informações de uma base SQL Server via Linked Server (ODBC). Estou fazendo da seguinte forma: SELECT * FROM OPENQUERY(PostgreSQL05,' select portal.sp_produtos_vencer_lojas(2015,5); select * from tb_tmp_produtos_vencer_lojas; ') O problema é que o que está retornando para o SQL Server é o resultado da primeira consulta e não o select na tabela temporária. Como posso resolver essa situação? Obrigado! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Function para remover session prepared
On 13-05-2015 04:21, Flavio Henrique Araque Gurgel wrote: >> Olá Fabrízio, >> >> Obrigado pela resposta. >> >> De fato não é a melhor solução, mas o que ocorre é que realmente a app >> está fazendo isso de forma indevida, e fica esquecendo estas sessios por >> lá. O correto seria ajustar no código, porém, infelizmente a >> instituição que desenvolveu app não está disposto a fazer tal análise. > > E tome top-posting... > +1 Francisco, tome cuidado com o top-posting... desorganiza o histórico da lista. > Colega, se a "instituição" que desenvolveu o "app" não está disposta a > fazer tal análise, ela não deveria ter começado o desenvolvimento. > Eles fazem e continuarão fazendo... a questão toda é que só chamam um cara que entende de banco de dados quando a "caca" está feita e em produção. Mas tb isso é um pouco culpa dos DBAs em modo geral que muitas vezes ajudam no inicio com um modelo inicial completo (velho cascata) e depois só vão atuar com a coisa rodando. Sou muito a favor de que esse profissional tem que estar inserido na equipe de desenvolvimento do inicio ao fim... temos um bom exemplo chamado DevOps. É uma nova buzzword eu sei, mas a idéia por trás da palavra é muito boa, pois a galera de operações atuando muito próximo ao time de desenvolvimento. Infelizmente é uma realidade que presencio pouco ainda nos times de desenvolvimento, mas tal necessidade já tem forçado muitos gestores a repensar essa idéia. > Isso se chama BUG e BUG a gente tem que matar na raiz. Senão você vai > sofrer no mármore do inferno da produção ignorada, sozinho, sem piedade, > como castigo de omissão :) > Bahhh (bem ao estilo gaúcho)... e pior é que precisamos ficar fazendo malabarismos e muitas vezes até gambiarras para poder manter a coisa em pé... :-( > Como opção, você pode pedir demissão ;) > Já fiz isso... foi o primeiro passo para virar empreendedor e hoje estou bem contente e satisfeito pois passo todos os dias fazendo o que mais gosto: "lidar com PostgreSQL" ;-) > Sou capaz de apostar que é uma aplicação Java que usa Spring Framework, > e está rodando sob JBoss ou Tomcat, acertei? > +1. Francisco? Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] manipulação de dados XML
On 12-05-2015 20:35, Santiago - NSR wrote: > Alguém tem algum link ou material sobre a manipulação de tipos de dados XML > ? > Documentação oficial? http://www.postgresql.org/docs/current/interactive/datatype-xml.html http://www.postgresql.org/docs/current/interactive/functions-xml.html Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] manipulação de dados XML
ola...na realidade o que estou procurando é conhecer o conceito de comando como "xpath"...e porque ?...tudo o que possa fazer dentro do banco de dados, faço e deixo o front end apenas para interagir com o usuário. estou desenvolvendo um modulo no meu erp de entrada de notas de via xml. e queria "abusar" do banco de dados salvando o arquivo xml dentro de um campo com type xml e trabalhar diretamente encima dele. queria ver tem alguma documentação encima deste tema. agradeço de qq forma a tua colaboração. Em 13.05.2015 20:38, Fabrízio de Royes Mello escreveu: > On 12-05-2015 20:35, Santiago - NSR wrote: > >> Alguém tem algum link ou material sobre a manipulação de tipos de dados XML ? > > Documentação oficial? > > http://www.postgresql.org/docs/current/interactive/datatype-xml.html [1] > http://www.postgresql.org/docs/current/interactive/functions-xml.html [2] > > Att, > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral [3] Links: -- [1] http://www.postgresql.org/docs/current/interactive/datatype-xml.html [2] http://www.postgresql.org/docs/current/interactive/functions-xml.html [3] 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] manipulação de dados XML
On 14-05-2015 00:19, Santiago-NSR wrote: > ola...na realidade o que estou procurando é conhecer o conceito de > comando como "xpath"...e porque ?...tudo o que possa fazer dentro do > banco de dados, faço e deixo o front end apenas para interagir com o > usuário. > > estou desenvolvendo um modulo no meu erp de entrada de notas > de via xml. e queria "abusar" do banco de dados salvando o arquivo xml > dentro de um campo com type xml e trabalhar diretamente encima dele. > Todas as funcionalidades existentes no postgres estão devidamente documentadas; o que não está documentado não existe. Você *não* explicou o que quer fazer com essas notas XML. Fica difícil dizer se a maneira mais aconselhada é ou não é utilizar o tipo XML. Sobre o XPath, ele é uma linguagem de consultas para documentos XML. A sua sintaxe está fora do escopo do manual do postgres. Vale ressaltar que o tipo XML tem os mesmos problemas que o tipo JSON: * lento para processamento de consultas; * não usa índices GIN e/ou GiST; * (você pode definir índices funcionais mas não se encaixa em todos os cenários). Eu só aconselharia utilizar o tipo XML se o seu uso for puramente para armazenamento (com poucas consultas). Se houver uma quantidade maior de consultas deve haver a possibilidade de usar índices funcionais (estou imaginando que essa tabela vai conter uma quantidade significativa de registros). Você pode optar, se for o caso, pela extração de partes do documento XML (gatilhos? aplicação?) e alimentar algumas colunas. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
