Re: [pgbr-geral] Transferir Banco Postgres para outra máquina
Se a versão do banco for a mesma. Sugiro que você utilize o pg_basebackup . A transferência é muito eficiente e bem mais rápida do que qualquer outro metodo. Copie as configurações ( postgres ) da primeira máquina para a máquina de destino, lembrando que na máquina original, não deverá haver alterações de dados por parte do cliente. Após a transferência, desligue a servidora original e transfira as conexões de rede dela para a segunda servidora. Att. Em 24 de junho de 2017 21:19, Euler Taveira <eu...@timbira.com.br> escreveu: > Em 24 de junho de 2017 16:26, Luiz Henrique <luiz.henriqu...@gmail.com> > escreveu: > >> >> Desejo transferir de forma definitiva. > > > Uma das formas mais rápidas seria utilizando replicação. Para isso o > hardware/SO deve ser (quase) igual. Uma vez montada a replicação [1], basta > escolher uma janela de manutenção e fazer o failover (pg_ctl promote). > > > [1] http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html > > > -- >Euler Taveira Timbira - > http://www.timbira.com.br/ >PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento > <http://www.timbira.com.br> > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Mauro Fonseca | Gerência de Suporte à Operação - GSOI - PB PRODABEL | Av. Presidente Carlos Luz 1275, Sala 221 | Caiçara | BH/MG 3277-7129 | www.pbh.gov.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Timeout Conexão
Tive algumas experiências com esta mensagem e geralmente era erro falha na rede do usuário. Em 23 de março de 2015 14:01, Pedro B. Alves pedroalve...@gmail.com escreveu: Qual erro é apresentado? Algo nos logs do servidor também? Nos logs não tem nada. ___ 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] Dica de migração do pg_upgrade , migrando os tablespaces para o local correto
É sempre bom tentar contribuir. Em 18 de julho de 2014 04:19, Leonardo Ferreira Guimarães gfodran...@gmail.com escreveu: Toda troca de informações e experiências é muito bem vinda. Obrigado! ___ 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] Dica de migração do pg_upgrade , migrando os tablespaces para o local correto
Espero poder ajudar aqueles que passaram pelos mesmos problemas que eu. Tive alguns problemas na execução do pg_upgrade, pois meus tablespaces ficavam em diretórios diferentes do padrão do postgres e o pg_upgrade não os leva para a nova estrutura. Achei um pequeno e único guia na internet e o readaptei para a migração, pois o mesmo estava um pouco confuso e tinha alguns erros. A migração foi executada dentro de um mesmo disco ou storage, lógico com dois clusters do postgres, um antigo na versão 9.1 e um futuro para a versão 9.3. Estou utilizando o debian e tenho a seguinte estrutura ( mudei os nomes para exemplificar . ) ACONSELHO QUE A MIGRAÇÃO SEJA FEITA EM SERVIDORAS QUE NÃO SEJAM AS DE PRODUÇÃO. Restaurei o backup em máquinas de testes. Cluster da versão 9.1 /postgres-prod/9.1/antigo/dados/ /postgres-prod/9.1/antigo/tablespaces/xx ( xx sao as diversas subpastas de diversos tablespaces, que no meu caso eu tenho ) Novo cluster para a versão 9.3 /postgres-prod/9.3/novo/dados/ /postgres-prod/9.3/novo/tablespaces/yyy ( yy sao as diversas pastas de diversos tablespaces ) O que ocorre, quando migramos seguindo a forma padrão, todos os tablespaces migrados para a versão 9.3, são colocados diretamente debaixo da estrutura anterior, apenas identificados pela versão. Se não fizéssemos o procedimento abaixo, ficariam assim: /postgres-prod/9.1/antigo/tablespaces/PG_9.1_201105231 /postgres-prod/9.1/antigo/tablespaces/PG_9.3_201184324 Como eu desejo: /postgres-prod/9.1/antigo/tablespaces/PG_9.1_201105231 /postgres-prod/9.3/novo/tablespaces/PG_9.3_201184324 isso iria gerar um trabalho imenso, riscos, principalmente no caso de uma base muito grande. No meu caso, migrei aproximadamente 400 Gb e fou migrar uma outra base de 1.2Tb, seguindo a mesma receita. Antes de começar, crie o cluster básico para a versão 9.3. Não o modifique, apenas faça o ajuste de localização dos dados e tablespaces. Crie as pastas dos tablespaces ( novos ) , mantendo as vazias. Ex. /postgres-prod/9.3/novo/tablespaces/ , se houver necessidade de subpastas, você deverá criá-las também, porém vaziastablespaces/vendas ,..tablespaces/notas O procedimento: /usr/lib/postgresql/9.3/bin/pg_upgrade -b /usr/lib/postgresql/9.1/bin/ -B /usr/lib/postgresql/9.3/bin/ -d /postgres-prod/9.1/antigo/dados/ -D /postgres-prod/9.3/novo/dados/ -o ' -c config_file=/etc/postgresql/9.1/antigo/postgresql.conf' -O ' -c config_file=/etc/postgresql/9.3/novo/postgresql.conf' -u 'postgres' Performing Consistency Checks - Checking cluster versions ok Checking database user is a superuser ok Checking for prepared transactions ok Checking for reg* system OID user data typesok Checking for contrib/isn with bigint-passing mismatch ok Creating dump of global objects ok Creating dump of database schemas APERTE CONTROL z , nesse ponto, para que a execução seja pausada. Edite o pg_upgrade_dump_globals.sql e altere o local dos tablespaces , mudando para o local da versão 9.3. Como exemplo, os tablespaces na 9.1 ficavam na pasta : /postgres-prod/9.1/antigo/tablespaces/ e voce deverá mudá-los para /postgres-prod/9.3/novo/tablespaces/ Salve o arquivo e vamos continuar a execução da migração, para isso dê o comando abaixo: fg 1( Isso é Sistema Operacional ). Aguarde o termino da migração e siga as orientações que serão colocadas em tela, tipo: analyze e delete da versão antiga, claro, isso após ter bastante certeza que está tudo ok. Minha sugestão é que você crie pequenos clusters de teste, um na versão 9.1 e outro na 9.3 e faça neles os testes. Espero poder ajudar. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configuração do PG_HBA.CONF
Não sei se é o caso, mas vale a pena perguntar. A sua conexão com banco não está sendo feita através do pgpool (local ) ? Se for esse o caso, verifique o pool_hba.conf, pois ele pode estar permitindo as conexões. ᐧ Em 13 de março de 2014 11:07, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Ja havia trocado mas mesmo assim estar permitindo via PGADMIN sem senha. Provavelmente você deixou o PgAdmin salvar a senha. Apague o arquivo .pgpass e pumba. Se você mudar a senha do PostgreSQL também funciona. []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
Re: [pgbr-geral] PostgreSQL x Storage
Tenho os dados em storage com uma base de aproximadamente 500 Gb e sem problemas. Acredito ser fibra ou mesmo formatação dos discos do storage. Em 19 de novembro de 2012 23:18, Bruno Silva bemanuel...@gmail.comescreveu: Tivemos problemas parecidos e era a fibra. Enviado pelo meu Nexus Em 19/11/2012 20:14, Tiago Adami adam...@gmail.com escreveu: Em 19 de novembro de 2012 17:40, Fábio Gibon gi...@comexsystem.com.br escreveu: Pessoal, um cliente comprou uma storage e está fazendo testes com o PGDATA nesta, porém está recebendo muitos erros de leitura. O problema não é o PostgreSQL, será que não tem disco com problema? Os discos/storage é zerado, isto não é garantia eu sei, mas nem pensei nesta hipótese ainda. Eu não manjo muito de storage e a parte física. Mas já vi problema parecido quando houve problemas no cabo que liga a controladora do servidor à unidade de storage. Que tipo de erros ele esta recebendo? Que tipo de configuração está o Storage? Fez RAID? Via HW ou SW? Não tive acesso ainda, mas me disseram que é RAID 5 e veio assim do fabricante (não sabem nada mais do que isto). Se cabeamento for descartado, não há como verificar os logs da controladora? Como você identificaria um disco com problema? Pode ser isso, apesar de que a controladora deveria descartar o disco sem interromper o serviço em caso de falha (depende também do número de discos, se for um RAID 5 com 3 discos as operações de R/W /deverão/ ser interrompidas. Os erros são: BRT ERRO: não pôde ler bloco 134230 no arquivo base/123495397/123497034.1: leu somente 0 de 8192 bytes Já que é para testes, vou passar um teste fácil para identificar erros de disco que um técnico fez em minha presença: 1) Apague todos os arquivos dos discos - formate se possível; 2) Crie um arquivo com zeros de no máximo 49% do tamanho da unidade lógica (partição) - acredito que isso foi feito usando o dd para Linux/Unix; 3) Copie o arquivo na mesma unidade lógica (partição); Parece um teste ridículo, mas quando a escrita do arquivo estava quase atingindo 10% (conferido por um outro terminal via SSH e rodando o comando timer -t 2 df -h - acho que foi isso) a escrita foi abortada com um erro na controladora. No meu caso foi necessário apenas fazer o downgrade da versão do SO que tinha incompatibilidades com a versão do virtualizador Xen Server rodando e o problema foi resolvido. Bem, agora vi que seu SO é Windows. Tente copiar um arquivo grande o suficiente para fazer os pedaços se espalharem multiplamente entre os discos, e depois copie-o para a mesma partição e veja o resultado para simular operação de R/W. Se nenhum erro acontecer, acredito que você já poderá descartar erros de disco/controladora/drivers. -- TIAGO J. ADAMI http://www.adamiworks.com @tiadami ___ 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 mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x Storage
Fábio, Para esse caso, utilizamos Raid 1 Gurgel, Usamos linux e não Windows. Na verdade, eu apenas disse que utilizamos uma base bem grante, +ou- 500 Gb e em storage. Funciona há anos, desde a versão 8.3 do Postgres e sem quaisquer tipo de problemas. Mauro. Em 20 de novembro de 2012 12:46, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Em 20-11-2012 11:34, Fábio Telles Rodriguez escreveu: Em 20 de novembro de 2012 11:13, Fábio Gibon gi...@comexsystem.com.br mailto:gi...@comexsystem.com.br escreveu: Mauro, que RAID vc usa? Ah, eles estão com a seguinte estrutura lá... ligaram o storage em uma rede gigabit (no mesmo switch do server do banco) e configuraram no server com ISCSI. (lembrando, server é Windows). Eu não sou um mega fã de usar Windows com Postgres, mas as pessoas dizem que funciona bem. Eu não sou um fã de usar RAID 5, mas funciona, não há de se negar. Eu não sou um fã de se usar discos SATA, mas ok, funciona. Eu não gosto de iSCSI, mas funciona. Mas pera aí... usar iSCSI sem usar placas HBA (usando porta gigabit normal), e ainda colocar o storage iSCSI no mesmo switch da rede normal... cara, vocês estão pedindo não? Vocês querem mesmo ter problemas. Tão pedindo por isso. Faz o seguinte meu amigo... pega os discos e coloca dentro do servidor. Vai por mim, ou brinca direito com storage (Fibre Channel ou Infini Band ao invés de iSCSI, discos Fibre Channel, RAID 10, duas HBAs em cada server e configuração fabric bem ajustada) ou então... coloca os discos dentro do server mesmo. Vai ficar mais rápido e mais fácil de manter. Claro... dá para fazer do outro jeito... sempre dá para ter uma alternativa sub ótima. Mas vale a pena mesmo? Se o orçamento não permite fazer de um jeito bacana, simplifica. Uma BOA controladora SAS e discos locais de 15Krpm fazem o Postgres rodar muito bem. Todas as dicas que todos deram aqui são ótimas. Mas todas são relacionadas a melhor desempenho, melhor estratégia, etc, etc. O que o colega está enfrentando é *erro* e nada do que vi aqui verifica *erros* (exceto uma dica l atrás e não vi resposta). Ao Mauro: Você conectou via iSCSI seu storage usando rede normal. Até aí, já tentou as estratégias de troubleshooting: - verificou no painel de controle, nos avisos do Windows, se há algum erro? - verificou a versão do driver iSCSI que está usando, se não há atualizações? - verificou a gravação/leitura direta de arquivos no dispositivo, como outro colega já recomendou antes? - tentou passar um scandisk a procura de erros no sistema de arquivos? - o sistema de arquivos é NTFS padrão do Windows mesmo? - seu sistema operacional está atualizado (a.k.a. Windows Update)? - como está particionado o disco iSCSI (via painel de controle, algum aplicativo maluco tipo Norton)? []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] exportar grants
Em 28 de setembro de 2012 10:29, Euler Taveira eu...@timbira.com escreveu: On 28-09-2012 10:14, Flavio Henrique Araque Gurgel wrote: Aproveita que tá migrando e já instala o 9.1.6 Não há porque ficar na 9.1.3, pelo contrário, há riscos e houve avisos na comunidade de bug crítico com risco de *perda de dados*. Você está sendo generalista. Os dados a que se refere aquele bug são mapas de visibilidade das tabelas (que podem ser reconstruídos se forem removidos); por precaução, é recomendado fazer um REINDEX após a atualização para 9.1.6 ou 9.2.1. Por fim, está bem claro: Table data proper cannot be corrupted by this bug. -- Euler Taveira de Oliveira - 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 Caso você queira ver os grants, usuarios, etc... poderá exportá-los, fazer os ajustes necessarios e depois importa-los na 9.1.x /usr/lib/postgresql/ 8.4/bin/pg_dumpall -p 5600 --globals global.sql Lembre-se de mudar a porta. Edite o global.sql e faça os ajustes que desejar. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Migração PostgreSQL 8.3 para 9.1
Em 28 de setembro de 2012 11:11, Fabrízio de Royes Mello fabriziome...@gmail.com escreveu: Em 28 de setembro de 2012 11:00, Marcone marconepe...@gmail.comescreveu: [...] Na migração do banco em si não há nada diferente e extraordinário, mas tome cuidado com as aplicações já que o casting automático que existia na 8.3 entrou em desuso nas versões seguintes, mas se necessário também pode-se fazer um arranjo (não é o ideal) para continuarem funcionando. [...] Na verdade os tipos de dados não-caracter que eram convertidos automaticamente para TEXT (implicit cast) que existia na 8.2 foi removido na 8.3 (veja release notes [1]). Isso fez com que várias aplicações quebrassem por não fazer os casts de forma explicita. Recomendo ler as release notes de lançamento das versões intermediárias a sua migração para vc verificar outras incompatibilidades e poder ajustar adequadamente sua transição. Att, [1] http://www.postgresql.org/docs/8.3/interactive/release-8-3.html#AEN87992 -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Outra coisa, é possível eu ter duas versões com portas diferentes rodando ao mesmo tempo no mesmo servidor, certo? Sim, é possível. Tanto da mesma versão ou versão difrente, desde que com portas diferentes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Distribuição Linux Servidor
Em 28 de setembro de 2012 12:14, Fabiano Machado Dias fabi...@wolaksistemas.com.br escreveu: Em 28-09-2012 12:04, Luiz Rafael Culik escreveu: Ola Pessoalmente Mil vezes linha RH do que debian para servidor postgresql []s Luiz Eu já tenho a opinião contrária, antes um Debian do que qualquer outra distro baseada em Red Hat, outra coisa, estou falando de Debian e não Ubuntu ou outra distro baseada nele! Minha opinião: Debian + XFS ReiserFS era uma boa opção antigamente, mas o seu desenvolvimento está praticamente estagnado, XFS é confiável e tem um desempenho muito bom. Além disso você pode personalizar algumas opções no File System que é bem fácil no Debian, coisa que as vezes só recompilando o Kernel em outras distros. Me lembro de uma palestra que sempre quis ver e nunca tive a oportunidade que era Debian, o melhor SO para o melhor banco ou algo assim! Não é Fike? rsrs Abraço, Fabiano Machado Dias ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Debian + Xfs , facil de instalar e atualizar. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco Postgres Multi Empresa
Posso sugerir também, a criação de cluster´s, assim cada empresa teria seu proprio postgres, ficando cada uma com sua própria configuração/otimização e porta. Isso facilita também, caso haja a necessidade de parar uma das empresas, sem afetar as outras. Utilizamos aqui, a seguinte configuração do diretório de dados. Isso em storage. /pgproducao/9.1/empresax /pgproducao/9.1/empresay Att. Em 20 de setembro de 2012 10:59, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: Hoje uso o postgres 9.0 na empresa que trabalho...agora surgiu a necessidade de tornar o sistema multi empresa. Alguem poderia me dar algumas opnioes? Usar schemas? Cada empresa fica relativamente isolada e a programação não muda nada, mas é mais complicado de administrar e de cruzar informações. Nessa opção, é conveniente criar um esquema para as informações ‘de referência’, cadastros centrais, como UFs, CEPs c. Usar tabelas com códigoEmpresa Prefiro… ___ 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] Versão no 9.2 no Backports do Debian
Jean, Utilize o guia que você encontro neste endereço: http://blog.anantshri.info/howto-add-ppa-in-debian/ . É um script para que você passe a incluir repositórios ppa para o debian. Após ter seguido o roteiro do blog, faça a inclusão propriamente dita do repositório para o postgres 9.2 add-apt-repository ppa:pitti/postgresql Pronto, agora é só dar apt-get update e os pacotes da versão 9.2 do postgres estarão disponíveis para serem instalados. Espero ter contribuído. Em 14 de setembro de 2012 08:12, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Em 14/09/2012 às 00:09 horas, pgbr-ge...@listas.postgresql.org.brescreveu: O Bruno, tava brincando. Também ajudo na lista. Só, dentro da minha limitação, vou esperar o pacote pra Debian. Leva na esportiva. Tô tranquilo, mas as vezes a gente tem de tomar cuidado. Agora quem te puxou a orelha não fui eu! Fui eu. Da próxima vez puxo mais forte :) []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748www.4linux.com.br email: fla...@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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Versão no 9.2 no Backports do Debian
Não Jean, O script permite adicionar ppa no seu /etc/apt/sources.list, após isso e ao você dar um aptitude update ou apt-get, os pacotes ficarão disponíveis para instalação. Faça um aptitude search postgres | grep 9.2 e você verá que eles estarão disponíveis para serem instalados. Em 14 de setembro de 2012 14:34, Jean Domingues ejdom...@yahoo.com.brescreveu: Jean, Utilize o guia que você encontro neste endereço: http://blog.anantshri.info/howto-add-ppa-in-debian/ . É um script para que você passe a incluir repositórios ppa para o debian. Após ter seguido o roteiro do blog, faça a inclusão propriamente dita do repositório para o postgres 9.2 add-apt-repository ppa:pitti/postgresql Pronto, agora é só dar apt-get update e os pacotes da versão 9.2 do postgres estarão disponíveis para serem instalados. Espero ter contribuído. Mauro, pra isso eu teria que ter o arquivo .deb gerado. (se é que eu entendi). ___ 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] 2 ou mais postgre no mesmo servidor
Roberto, O que você está querendo é sim cluster. Temos diversos funcionando aqui na empresa e cada um com sua própria configuração, otimização e área de dados. Na criação do primeiro cluster ele pega a primeira porta livre. Ex. 5432 , para o segundo cluster, a próxima porta , no caso 5433 . O postgres instalado é apenas um (ou mais de um caso seja necessario versoes diferentes ), mas permitindo configurações distintas. Lembrando: pg_createcluster versaodoposgres cluster , existem outros parametros, mas eu prefiro criar na forma básica e alterar no postgresql.conf de cada um deles. Em 24 de julho de 2012 11:33, Roberto Mello roberto.me...@gmail.comescreveu: 2012/7/24 Marcos Aurelio marcos.cava...@gmail.com: Um bom dia a todos. Na ultma vez eu havia postado sobre ter o postgresql instalado e escutando em duas portas distintas a 5433 e 5432. Deu uma estudada os servidores e validei que se trata de dois bancos instalados no mesmo servidor. Como faço pra obter o mesmo resultado ? Voces poderiam me indicar alguma documentação a respeito ? Esse tipo de configuração é considerada cluster de banco ? O mesmo programa (postmaster) estaria rodando, mas usando configurações distintas, dessa forma um processo postmaster usaria uma área de dados num local do disco e escutaria em uma porta, e outro processo usaria outra área e porta. Não seria cluster. Apenas um mesmo programa rodando com configurações diferentes. Para um, o outro é completamente irrelevante, a não ser que você os ligue de alguma maneira, que vai depender do que você quer fazer. Roberto ___ 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] Nome de DB alterado durante replicação off
Tulio, Para amenizar seu problema, posso sugerir um backup a quente. Funciona na versao 9.1 . O comando abaixo, que deverá ser rodado na maquina 2, faz um backup completo da maquina1 que deverá estar online, Dessa forma, você não terá problemas com o seu ambiente. O que tem que ser feito antes. Na maquina 2, você deverá esvaziar todos os dados, mantendo apenas o diretorio totalmente vazio e as permissoes necessarias a ele, para o postgres. No meu caso, em linux, mantive: /meupostgres/dados ( permissão linux para o diretorio dados - chmod 0700 ) se o seu diretorio de logs ficar dentro do meupostgres, não esqueça de criá-lo e mudar o dono para o usuário postgres, isso não afetará a transferência dos dados, mas você terá problemas para levantar o postgres depois. não se esqueça de copiar o seu recovery.conf para o diretorio /meupostgres/dados , após a transferencia. A transferência é super rápida, mas é claro, depende da rede entre as 2 maquinas. Vamos a linha de comando: - A transferencia deverá ser feita pelo usuario postgres .banco1, a servidora master, que deverá online .porta, porta da sevidora master . -D , o diretorio da servidora local. É claro que ela está parada. Não se preocupe com os archives. Ela deixará tudo pronto com o sincronismo. Agora, antes de levantar o banco transferido, confira mais uma vez se você colocou o recovery.conf no diretório de dados. Levante o postgres e ela estará totalmente sincronizada. Espero ter ajudado. Se tiver dúvidas, tentarei ajudar. Abraço. /usr/lib/postgresql/9.1/bin/pg_basebackup -h banco1 -p 5600 -x -D /meupostgres/dados -P -v Em 8 de março de 2012 16:40, Tulio Santos tuliogust...@yahoo.com.brescreveu: 1) Vc faz arquivamento dos XLOG no master? Sim, mas apenas do Master diretamente no Slave.. e por conta do periodo inativo acabei por perder-los. 2) Que mensagem aparece no log do slave ao iniciá-lo? Observando agora, ele esta procurando arquivos de segmentos que não existem... Estou pensando nessa solução: 1- gerar um dumpall no master.. 2- dropar bases do slave.. (sem estar ligado ao master) 3- restaurar no slave... 4- ressincronizar.. Se tiverem uma outra ideia.. to aceitando. Att, Tulio -- *De:* Fabrízio de Royes Mello fabriziome...@gmail.com *Para:* Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br *Enviadas:* Quinta-feira, 8 de Março de 2012 13:13 *Assunto:* Re: [pgbr-geral] Nome de DB alterado durante replicação off Em 8 de março de 2012 12:23, Tulio Santos tuliogust...@yahoo.com.brescreveu: Bom dia pessoal, Tenho dois servidores trabalhando em replicação streaming. A slave esteve inativa durante um curto periodo (aprox. 1 dia), porem, neste periodo o nome de uma das bases foi alterado. Como a replicação entenderá esta situação? O OID da base foi alterado ao modificar o nome, certo? A slave saberá identificar a qual base deverá se referir? Duas perguntas: 1) Vc faz arquivamento dos XLOG no master? 2) Que mensagem aparece no log do slave ao iniciá-lo? Att, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ 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 mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] walsender
Pois é Gurgel, Este procedimento foi executado e estava funcionando sem problemas enquanto dava a carga no ambiente. Inclusive quando ele foi iniciado, eu fiz alguns testes e as réplica eram executadas sem problemas, via stream. Apenas após a carga, foi dado um restart no postgres e a mensagem apareceu. A única diferença é que no restore, eu havia salvado um globals para a criação das roles, inclusive a role do postgres. Eu acredito que a origem surgiu aí, mas ainda não consegui entender o motivo. Veja o hba. hostreplication postgres 192.168.0.1/32 trust hostreplication postgres 192.168.0.2/32 trust Abraços, Mauro. Em 20 de dezembro de 2011 16:08, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Tenho 2 servidoras ligadas em cluster ( 9.1) hotstandby. Dei uma carga na primeira e o sincronismo ocorreu certinho para a segunda máquina, porém, após o término, parei todo cluster e quando o iniciei, ele passou a dar a seguinte mensagem: BRST FATAL: deve ser role de replicacao para iniciar walsender A iniciacao foi feita tanto atraves do root, quanto do usuario postgres. Alguém tem alguma dica ? Você precisa de um usuário com a flag REPLICATION habilitada. No mestre: CREATE ROLE blablabla REPLICATION; Ainda no mestre, no pg_hba.conf host replication blablabla x.y.z.k/32 md5 No escravo, use a role criada acima para conexão. Isso é configurado no recovery.conf. []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
Re: [pgbr-geral] walsender
Gurgel, Observando novamente o role, percebi que o parametro REPLICATION não existia para o usuário postgres. Acredito que por ter vindo de uma versão anterior, onde não havia réplica, e sido sobreposto. O adicionei e tudo voltou ao normal. Agradeço por sua disposição em ajudar. Um grande abraço. Mauro. Em 21 de dezembro de 2011 09:28, mauro fonseca mfons...@pbh.gov.brescreveu: Pois é Gurgel, Este procedimento foi executado e estava funcionando sem problemas enquanto dava a carga no ambiente. Inclusive quando ele foi iniciado, eu fiz alguns testes e as réplica eram executadas sem problemas, via stream. Apenas após a carga, foi dado um restart no postgres e a mensagem apareceu. A única diferença é que no restore, eu havia salvado um globals para a criação das roles, inclusive a role do postgres. Eu acredito que a origem surgiu aí, mas ainda não consegui entender o motivo. Veja o hba. hostreplication postgres 192.168.0.1/32 trust hostreplication postgres 192.168.0.2/32 trust Abraços, Mauro. Em 20 de dezembro de 2011 16:08, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Tenho 2 servidoras ligadas em cluster ( 9.1) hotstandby. Dei uma carga na primeira e o sincronismo ocorreu certinho para a segunda máquina, porém, após o término, parei todo cluster e quando o iniciei, ele passou a dar a seguinte mensagem: BRST FATAL: deve ser role de replicacao para iniciar walsender A iniciacao foi feita tanto atraves do root, quanto do usuario postgres. Alguém tem alguma dica ? Você precisa de um usuário com a flag REPLICATION habilitada. No mestre: CREATE ROLE blablabla REPLICATION; Ainda no mestre, no pg_hba.conf host replication blablabla x.y.z.k/32 md5 No escravo, use a role criada acima para conexão. Isso é configurado no recovery.conf. []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
Re: [pgbr-geral] walsender
Mais uma vez agradeço a presteza e as boas dicas. Abraços, Mauro. Em 21 de dezembro de 2011 11:44, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Gurgel, Observando novamente o role, percebi que o parametro REPLICATION não existia para o usuário postgres. Acredito que por ter vindo de uma versão anterior, onde não havia réplica, e sido sobreposto. O adicionei e tudo voltou ao normal. Agradeço por sua disposição em ajudar. Legal que deu tudo certo pra você. Só uma dica, use um usuário a parte para a replicação, e evite que seja um superusuário. Um usuário só com a flag REPLICATION e sem a flag SUPERUSER tem menos poderes de acesso, o que torna as coisas mais seguras pra você. O usuário com a flag REPLICATION tem todos os direitos necessários para fazer replicação, e não tem nenhum outro direito de fazer mais nada (exceto se você liberar explicitamente). []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] walsender
Companheiros, Tenho 2 servidoras ligadas em cluster ( 9.1) hotstandby. Dei uma carga na primeira e o sincronismo ocorreu certinho para a segunda máquina, porém, após o término, parei todo cluster e quando o iniciei, ele passou a dar a seguinte mensagem: BRST FATAL: deve ser role de replicacao para iniciar walsender A iniciacao foi feita tanto atraves do root, quanto do usuario postgres. Alguém tem alguma dica ? Abraço e obrigado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Pgpool ii 3.1
Boa tarde pessoal, Estou fazendo um teste de migracao da versao 8.4 para a 9.1.1, utilizando pg_dump | pg_restore . Se utilizo o diretamente atraves da porta do postgres 5432 , ou seja, postgres para postgres , funciona direitinho. Porém, se utilizo o pgpool, atraves da porta , tem sido apresentado o seguinte erro: 2011-10-21 11:40:26 ERROR: pid 26949: kind mismatch among backends. Possible last query was: SET search_path = autorizacao, pg_catalog kind details are: 0[C] 1[E: valor é inválido para parâmetro search_path: autorizacao, pg_catalog] * Utilizei o pgpool, para aproveitar e testa-lo, pois futuramente ele que recebera as requisicoes do banco. Alguem ja passou por isso ou tem alguma ideia para solucionar ? 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] Pgpool ii 3.1
Flavio, Obrigado. Baseado no que voce falou, concluí que o nro de conexoes aceitas pelo pgpool, era maior do que o estava configurado no postgres. Vou deixar o teste sendo feito e ver se isso resolveu e depois reporto aqui. Mais uma vez obrigado Em 21 de outubro de 2011 14:35, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Estou fazendo um teste de migracao da versao 8.4 para a 9.1.1, utilizando pg_dump | pg_restore . Se utilizo o diretamente atraves da porta do postgres 5432 , ou seja, postgres para postgres , funciona direitinho. Porém, se utilizo o pgpool, atraves da porta , tem sido apresentado o seguinte erro: 2011-10-21 11:40:26 ERROR: pid 26949: kind mismatch among backends. Possible last query was: SET search_path = autorizacao, pg_catalog kind details are: 0[C] 1[E: valor é inválido para parâmetro search_path: autorizacao, pg_catalog] * Utilizei o pgpool, para aproveitar e testa-lo, pois futuramente ele que recebera as requisicoes do banco. Alguem ja passou por isso ou tem alguma ideia para solucionar ? Em que modo está funcionando o pgpool? Você começou com ambos os backends (cada um dos bancos de dados) zerados? As configurações de ambos os backends são iguais? O que o pgpool está dizendo é que um dos backends não está aceitando o nome do schema no search_path, o outro está. []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
Re: [pgbr-geral] Migracao de versao - erro no pgrestore
Amigos, Primeiro gostaria de agradecer aos companheiros que me ajudaram, Euler, Flavio, Dickson, Fabrizio e a todos os outros que estão sempre dispostos a gastar um pouquinho de seu tempo para contribuir com outros menos providos de conhecimento, tal qual é o meu caso. Consegui efetuar a migração (testes) da 8.4 , porém desisti de passar pela 9.04 e fui direto para a 9.1. É que em uma servidora menor, a migração para 9.04 foi sem problemas e na outra, tive falhas. Como não localizava a falha, reinstalei e reconfigurei tudo, porem com a 9.1 . Desativei a restauracao paralela, conforme orientacao do Euler . Estarei na em Sao Paulo, na PGBR2011, ouvindo e tentando conseguir um pouco mais de conhecimento com os amigos que lá se apresentarão. Mais uma vez agradeço a todos. Em 7 de outubro de 2011 14:49, Euler Taveira de Oliveira eu...@timbira.comescreveu: On 07-10-2011 10:57, mauro fonseca wrote: É que as informações principais, ficaram no primeiro post. Mas veja, a servidora tem 128Gb de Ram e 32Nucleos . O restore é porta a porta: pg_dump bd_banco1 --disable-triggers -p 5430 -b -v -Fc | pg_restore --disable-triggers -d bd_banco2 -j 12 1ok 2erro Você não entendeu... Eu estava dizendo quando tentou restaurar a partir do arquivo. Como eu disse no último email, infelizmente restauração paralela não funciona com pipe. :( Tente sem utilizar a opção -j ou divida a sua cópia de segurança em vários pedaços e restaure-os paralelamente. Se o seu tempo de parada não permite, sugiro que utilize streaming replication para transferir os dados de um lado para o outro. -- Euler Taveira de Oliveira - 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Migracao de versao - erro no pgrestore
Fabrizio, Gerei um dump para disco e o restaurei a partir dele. Dá o mesmo erro. Exatamente a 125minutos de processamento. O interessante é que eu o restaurei em uma servidora de capacidade bem inferior e ele foi restaurado sem problemas. A única diferença é que na servidora inferior está com a versão 9.1 e na nova, a 9.04. Acredito que a exista falha de configuração na servidora onde ocorre o erro. Já chequei tudo, sysctl , limits, configuração do postgres e nada. Já instalei inúmeras servidoras e até então nunca havia visto esta falha. O meu grande problema é que quando eu tiver que migrar o ambiente de produção real, que é gigantesco, a janela será minima, por se tratar de um serviço que necessita estar realmente no ar. Por isso o pg_dump/restore porta a porta. Se alguem tiver mais uma ideia, serei grato. Em 6 de outubro de 2011 09:05, Fabrízio de Royes Mello fabriziome...@gmail.com escreveu: Em 6 de outubro de 2011 08:07, mauro fonseca mfons...@pbh.gov.brescreveu: Se alguém mais tiver uma dica, seria grato. Terei que migrar este ambiente em breve, mas além tempo que será tomado, este erro está complicando a migração. Vc tentou realizar o procedimento em 2 etapas? 1) pg_dump -Fc -Z9 -f dump.bkp nome_da_base_de_origem 2) pg_restore -Fc -d nome_da_base_de_destino dump.bkp Cordialmente, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ 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] Migracao de versao - erro no pgrestore
Dickson, Vou tentar seguir sua idéia para ver se detecto o problema. Fatiarei o frango. Como eu disse para o Fabrizio, a restauração em uma servidora de menor capacidade funcionou sem problemas, lógico que com um tempo bem maior. Porém, preciso detectar a falha, para no momento propicio , onde será executada a migração real, não ter surpresas. Obrigado pela ajuda. Em 6 de outubro de 2011 08:43, Dickson S. Guedes lis...@guedesoft.netescreveu: Em 6 de outubro de 2011 08:07, mauro fonseca mfons...@pbh.gov.br escreveu: Se alguém mais tiver uma dica, seria grato. Terei que migrar este ambiente em breve, mas além tempo que será tomado, este erro está complicando a migração. Obrigado, Creio que até o momento seu comando continua sendo: pg_dump bd_banco1 --disable-triggers -p 5430 -b -v -Fc | pg_restore --disable-triggers -d bd_banco2 -j 12 1ok 2erro Aconselho você a comer pelas bordas, cercar o frango, dividir para conquistar. Tecnicamente falando acho que voce poderia fazer o seguinte: Primeiro: Crie um dump! Isso mesmo... crie um arquivo de dump em *formato custom*, vejo que voce está redirecionando a saida e fazendo este dump vai te economizar tempo caso precisa repetir os seus testes bem como vai permitir uma restauração parcial; Segundo, faça uma restauração parcial! Então use pg_restore --list e pg_restore --use-list . Voce pode comecar com a estrutura, depois com os dados de *algumas tabelas selecionadas*. Sim! Restaure em um momento algumas tabelas, se der certo, selecione mais outras para restaurar, e mais outras, e mais outras ate que todas estejam restauradas, por fim restaure demais objetos como FKs e INDEXes por exemplo. Você pode obter mais informações em [1], [2]. Fiz um PGCast sobre isto em [3], ele pode ser útil. Cheguei a dar uma olhada em suas configurações mas não conheço seu ambiente o suficiente para opinar algo específico, mas apenas como sugestão costumo usar múltiplos de 8K para valores que referenciam memória como shared_buffers, work_mem e effective_cache_size. [1] http://www.postgresql.org/docs/current/interactive/app-pgdump.html#PG-DUMP-OPTIONS [2] http://www.postgresql.org/docs/current/interactive/app-pgrestore.html#APP-PGRESTORE-OPTIONS [3] http://pt.pgcasts.com/post/10661515346/5-coisas-que-voce-deveria-saber-sobre-dump-e []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ 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] Migracao de versao - erro no pgrestore
Euler, É que as informações principais, ficaram no primeiro post. Mas veja, a servidora tem 128Gb de Ram e 32Nucleos . O restore é porta a porta: pg_dump bd_banco1 --disable-triggers -p 5430 -b -v -Fc | pg_restore --disable-triggers -d bd_banco2 -j 12 1ok 2erro Em 7 de outubro de 2011 10:38, Euler Taveira de Oliveira eu...@timbira.comescreveu: On 05-10-2011 13:51, mauro fonseca wrote: pg_restore: [arquivador personalizado] não pôde reabrir entrada padrão ão foi possível alocar memória Você não mostrou o comando do pg_restore mas ele não irá funcionar se você combinar dados da entrada padrâo com restauração paralela. Quanto ao erro de alocação de memória, provavelmente a sua máquina não possui quantidade suficiente ou o seu usuário não pode utilizá-la (vide ulimit) -- monitore a utilização (por exemplo com dstat ou vmstat) para descobrir o quanto está sendo pedido. Verifique também se o OOM não está terminando o processo do pg_restore (vide dmesg). -- Euler Taveira de Oliveira - 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Migracao de versao - erro no pgrestore
Se alguém mais tiver uma dica, seria grato. Terei que migrar este ambiente em breve, mas além tempo que será tomado, este erro está complicando a migração. Obrigado, Em 5 de outubro de 2011 13:51, mauro fonseca mfons...@pbh.gov.br escreveu: Infelizmente nao deu. O retorno: pg_restore: [arquivador personalizado] não pôde reabrir entrada padrão ão foi possível alocar memória Continuo pedindo ajuda..Se alguem tiver alguma ideia. Obrigado. Em 5 de outubro de 2011 10:13, mauro fonseca mfons...@pbh.gov.brescreveu: Flávio, Fiz os seguintes ajustes no limits.conf : postgres soft nofile 4096 postgres soft nproc 4096 postgres hard nofile 63536 postgres hard nproc 6353 Apos isso, coloquei novamente o pg_restore e ja passou bastante tempo em relacao a queda anterior. Vou aguardar para ver se nao dah mais erros e posto o resultado. Agradeco muito a sua ajuda e prontidao. Abracao. Em 5 de outubro de 2011 09:35, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: 2011/10/5 mauro fonseca mfons...@pbh.gov.br: Pessoal, Estou colando o meu ulimit -a ( a partir do usuario postgres ) core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Note que não é o limite do usuário postgres, necessariamente, que está te dando esse erro. O erro é do pg_restore e ele é uma aplicação de usuário. Já vi esse tipo de erro quando o pg_restore estava trabalhando com arquivo no modo custom, é na hora de descompactar certos blocos de dados. Tente, na mesma sessão: ulimit -d unlimited ulimit -l unlimited pg_restore... E deve ir. Caso receba um erro nos comandos ulimit acima, modifique seu arquivo /etc/security/limits.conf para desbloquear esses limites. Se ainda não funcionar, qual é a saída do comando abaixo? /sbin/sysctl kernel.shmmax []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
Re: [pgbr-geral] Migracao de versao - erro no pgrestore
Pessoal, Estou colando o meu ulimit -a ( a partir do usuario postgres ) core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Em 4 de outubro de 2011 18:29, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Em 4 de outubro de 2011 18:11, Dickson S. Guedes lis...@guedesoft.net escreveu: Em 4 de outubro de 2011 17:36, mauro fonseca mfons...@pbh.gov.br escreveu: Não achei o aplicativo limits no s.o, apesar disso existe o conf dele, no /etc/security/limits e ele estah todo comentado. O utilitário é `ulimit`, use: ulimit -a Ih! Falha nossa!!! (c) Jô Soares, 198X Valeu Guedes! []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
Re: [pgbr-geral] Migracao de versao - erro no pgrestore
Flávio, Fiz os seguintes ajustes no limits.conf : postgres soft nofile 4096 postgres soft nproc 4096 postgres hard nofile 63536 postgres hard nproc 6353 Apos isso, coloquei novamente o pg_restore e ja passou bastante tempo em relacao a queda anterior. Vou aguardar para ver se nao dah mais erros e posto o resultado. Agradeco muito a sua ajuda e prontidao. Abracao. Em 5 de outubro de 2011 09:35, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: 2011/10/5 mauro fonseca mfons...@pbh.gov.br: Pessoal, Estou colando o meu ulimit -a ( a partir do usuario postgres ) core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Note que não é o limite do usuário postgres, necessariamente, que está te dando esse erro. O erro é do pg_restore e ele é uma aplicação de usuário. Já vi esse tipo de erro quando o pg_restore estava trabalhando com arquivo no modo custom, é na hora de descompactar certos blocos de dados. Tente, na mesma sessão: ulimit -d unlimited ulimit -l unlimited pg_restore... E deve ir. Caso receba um erro nos comandos ulimit acima, modifique seu arquivo /etc/security/limits.conf para desbloquear esses limites. Se ainda não funcionar, qual é a saída do comando abaixo? /sbin/sysctl kernel.shmmax []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
Re: [pgbr-geral] Migracao de versao - erro no pgrestore
Infelizmente nao deu. O retorno: pg_restore: [arquivador personalizado] não pôde reabrir entrada padrão ão foi possível alocar memória Continuo pedindo ajuda..Se alguem tiver alguma ideia. Obrigado. Em 5 de outubro de 2011 10:13, mauro fonseca mfons...@pbh.gov.br escreveu: Flávio, Fiz os seguintes ajustes no limits.conf : postgres soft nofile 4096 postgres soft nproc 4096 postgres hard nofile 63536 postgres hard nproc 6353 Apos isso, coloquei novamente o pg_restore e ja passou bastante tempo em relacao a queda anterior. Vou aguardar para ver se nao dah mais erros e posto o resultado. Agradeco muito a sua ajuda e prontidao. Abracao. Em 5 de outubro de 2011 09:35, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: 2011/10/5 mauro fonseca mfons...@pbh.gov.br: Pessoal, Estou colando o meu ulimit -a ( a partir do usuario postgres ) core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Note que não é o limite do usuário postgres, necessariamente, que está te dando esse erro. O erro é do pg_restore e ele é uma aplicação de usuário. Já vi esse tipo de erro quando o pg_restore estava trabalhando com arquivo no modo custom, é na hora de descompactar certos blocos de dados. Tente, na mesma sessão: ulimit -d unlimited ulimit -l unlimited pg_restore... E deve ir. Caso receba um erro nos comandos ulimit acima, modifique seu arquivo /etc/security/limits.conf para desbloquear esses limites. Se ainda não funcionar, qual é a saída do comando abaixo? /sbin/sysctl kernel.shmmax []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] Migracao de versao - erro no pgrestore
Amigos, Estou fazendo a migracao entre as versoes 8.4 e 9.04 do postgres, utilizando a mesma servidora. Instalei na servidora, as 2 versoes do banco e fiz o seguinte dump/restore . pg_dump bd_banco1 --disable-triggers -p 5430 -b -v -Fc | pg_restore --disable-triggers -d bd_banco2 -j 12 1ok 2erro Ocorre, que apos determinado tempo (mais ou menos 2 horas ) um erro eh gerado: pg_restore: [arquivador] não pôde criar processo filho: Não foi possível alocar memória A servidora tem a seguinte configuracao: 128 Gb de Ram 32 nucleos A base original tem 233 Gb em HD. A configuracao do postgres 8.4: shared_buffers = 2GB wal_buffers = 8MB checkpoint_completion_target = 0.9 effective_cache_size = 13GB work_mem = 112MB maintenance_work_mem = 1GB checkpoint_segments = 16 A configuracao do postgres 9.x shared_buffers = 18GB # min 128kB work_mem = 448MB# min 64kB maintenance_work_mem = 1GB # min 1MB checkpoint_segments = 16 checkpoint_timeout = 300s effective_cache_size = 52GB wal_buffers = 8MB fsync = off O sysctl kernel.shmmax = 67732090880 kernel.shmall = 16536155 vm.overcommit_memory = 2 kernel.core_uses_pid = 1 Se alguem puder ajudar ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Migracao de versao - erro no pgrestore
Flavio, primeiro obrigado por responder. O Kernel eh 2.32-5-amd64 . O S.O eh debian. Não achei o aplicativo limits no s.o, apesar disso existe o conf dele, no /etc/security/limits e ele estah todo comentado. Alguma dica ? Obrigado. Em 4 de outubro de 2011 13:59, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Em 4 de outubro de 2011 11:26, mauro fonseca mfons...@pbh.gov.br escreveu: Amigos, Estou fazendo a migracao entre as versoes 8.4 e 9.04 do postgres, utilizando a mesma servidora. Instalei na servidora, as 2 versoes do banco e fiz o seguinte dump/restore . pg_dump bd_banco1 --disable-triggers -p 5430 -b -v -Fc | pg_restore --disable-triggers -d bd_banco2 -j 12 1ok 2erro Ocorre, que apos determinado tempo (mais ou menos 2 horas ) um erro eh gerado: pg_restore: [arquivador] não pôde criar processo filho: Não foi possível alocar memória A servidora tem a seguinte configuracao: 128 Gb de Ram 32 nucleos A base original tem 233 Gb em HD. A configuracao do postgres 8.4: shared_buffers = 2GB wal_buffers = 8MB checkpoint_completion_target = 0.9 effective_cache_size = 13GB work_mem = 112MB maintenance_work_mem = 1GB checkpoint_segments = 16 A configuracao do postgres 9.x shared_buffers = 18GB # min 128kB work_mem = 448MB# min 64kB maintenance_work_mem = 1GB # min 1MB checkpoint_segments = 16 checkpoint_timeout = 300s effective_cache_size = 52GB wal_buffers = 8MB fsync = off O sysctl kernel.shmmax = 67732090880 kernel.shmall = 16536155 vm.overcommit_memory = 2 kernel.core_uses_pid = 1 Se alguem puder ajudar ? Verifique o arquivo /etc/security/limits.conf Verifique o comando, no usuário que roda o PostgreSQL e no usuário que roda o pg_restore: limits -a Qual a distro/versão do kernel (uname -a)? []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
Re: [pgbr-geral] Digest pgbr-geral, volume 31, assunto 37
Emerson, Se você a parte do rsync e tentar executá-lo na mão, de dentro do diretório data do postgres, assim: rsync -a pg_xlog/00010001 10.1.3.119: /home/postgres/replication/00010001 Notará que o erro também ocorrerá. Nesse caso, você deverá criar uma chave publica entre as servidoras. Faça assim: su - postgres enter para entrar como usuário postgres ssh-keygen enter até voltar para o prompt cd .ssh ( para entrar no diretorio onde a chave foi criada) ssh-copy-id 10.1.3.119 ( Para que ela seja enviada a servidora slave ) Testando: ssh 10.1.3.119 se ele entrar na servidora 10.1.3.119 sem pedir senha, provavelmente o rsync irá funcionar, volte para a master e verifique se o sincronismo está ocorrendo. Att. Mauro. Em 8 de julho de 2011 14:11, Emerson Martins emersonmarti...@gmail.comescreveu: Euler conseguir startar o banco revisei meu postgresql.conf e pg_hba.conf.O problema era que o banco não estava startando..dizia que estava porém nos processos não aparecia. Segue o log do servidor slave. FATAL: archive command failed with exit code 255 DETAIL: The failed archive command was: rsync -a pg_xlog/00010001 10.1.3.119: /home/postgres/replication/00010001 LOG: archiver process (PID 29322) exited with exit code 1 Emerson Martins Message: 1 Date: Thu, 07 Jul 2011 15:34:49 -0300 From: Euler Taveira de Oliveira eu...@timbira.com Subject: Re: [pgbr-geral] Replicação Master/Slave Postgres 9.0.4 Debian 6 - Probelmas To: pgbr-geral@listas.postgresql.org.br Message-ID: 4e15fc49.1090...@timbira.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Em 07-07-2011 14:51, Emerson Martins escreveu: host replication all 0.0.0.0/0trust Eu não aconselho fazer isso. Informe um usuário (ao invés de all) e uma máquina (ao invés de 0.0.0.0/0). 2.1 backup da pasta data do master e extrai no diretorio data do slave; E o pg_stop_backup() foi feito? Porém quando dou um grep nos processos não estar no ar o servidor. E o que diz o log? -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Message: 2 Date: Thu, 7 Jul 2011 16:45:51 -0300 From: Beto Lima betol...@gmail.com Subject: [pgbr-geral] mesclar dados To: pgbr-geral@listas.postgresql.org.br Message-ID: can+tixakmkxjwzejgflpatdrsabbncm6_iht4y28oa1ayab...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 pessoal tenho a seguinte situação: tenho uma base com alguns esquemas e tabelas + constraints pra manter integridade dos dados. Acontece que tive que parar o servidor e colocar o banco em outro. de ontem pra hoje a base recebeu novos registros e agora preciso pegar estes dados e jogar na base que eu tinha la no servidor parado. Como eu poderia fazer isso? Com pgadmin daria? valeu -- Message: 3 Date: Thu, 7 Jul 2011 17:45:33 -0300 From: Osvaldo Kussama osvaldo.kuss...@gmail.com Subject: Re: [pgbr-geral] mesclar dados To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Message-ID: cadgbbqjvdsoxfol+fo-g967ata0itx_y+bshty2zcdgq-ud...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Em 7 de julho de 2011 16:45, Beto Lima betol...@gmail.com escreveu: pessoal tenho a seguinte situação: tenho uma base com alguns esquemas e tabelas + constraints pra manter integridade dos dados. Acontece que tive que parar o servidor e colocar o banco em outro. de ontem pra hoje a base recebeu novos registros e agora preciso pegar estes dados e jogar na base que eu tinha la no servidor parado. Como eu poderia fazer isso? Com pgadmin daria? Por que você não utiliza o mesmo procedimento só que no sentido inverso? Creio que seria a solução mais simples. Osvaldo -- Message: 4 Date: Thu, 7 Jul 2011 17:52:25 -0300 From: Beto Lima betol...@gmail.com Subject: Re: [pgbr-geral] mesclar dados To: pgbr-geral@listas.postgresql.org.br Message-ID: can+tixa6oswj0e37a2p-ueer8uywwznvmn0v3i0f-ek6rvy...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 porque o meu servidor é um cloud e o outro é uma hospedagem nornal. então la acabo perdendo todas as roles + default privilegios + grants de tabelas e owner. -- ___ 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 31, assunto 37 *** ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Heartbeat
Boa tarde, Alguém sabe informar onde foi parar ou qual é o substituto do heartbeat-2-gui no debian squeeze. No lenny eu o acho sem problemas, no squeeze eu não o acho de forma alguma. Obrigado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] pgpool ii 3.0
Amigos, Caso alguém possa ajudar, Tenho o seguinte ambiente: . 2 servidoras postgres 9.0.3 , as quais chamarei de banco1 e banco2, replicando hot_standby e funcionando perfeitamente. . Apenas para teste, a primeira servidora trabalha na porta 5450 e a segunda na porta 5451 . . Os dois equipamentos são iguais. . Na primeira servidora, instalei o pgpool ii 3.0, ouvindo a porta e administrando na 9898 . . no pgpool.conf, coloquei os seguintes backends backend_hostname0 = '10.0.28.77' - banco1 backend_port0 = 5450 backend_weight0 = 1 backend_hostname1 = '10.0.30.24' - banco2 backend_port1 = 5451 backend_weight1 = 3 O meu problema é o seguinte: Apesar do pgpool estar funcionando perfeitamente na primeira maquina, ele não faz o balanceamento para a segunda máquina. Todos os selects sempre vão para a primeira máquina. Obs : load_balance_mode = true. Obrigado, Mauro. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pgpool ii 3.0
Flávio, Obrigado por responder. Consegui funcionar. Ativei a opção master_slave_mode = true, fiz um pgbench e os selects foram distribuídos. Obrigado e um abraço. Em 28 de junho de 2011 11:19, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Apesar do pgpool estar funcionando perfeitamente na primeira maquina, ele não faz o balanceamento para a segunda máquina. Todos os selects sempre vão para a primeira máquina. Obs : load_balance_mode = true. 3 coisas podem estar acontecendo: 1) os pesos são muito diferentes (1 e 3 na sua configuração) e o pgpool vai tender a mandar tudo pro nó que ele está considerando mais poderoso. Já tentou colocar pesos iguais? 2) seus SELECT estão sempre dentro de transações. O pgpool só é capaz de distribuir SELECT isolado. 3) outras configurações que não temos aqui. Passe todas as configurações não default pra sabermos se há mais algo que possa estar influenciando. []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] Backup
Amigos,
Estou com algumas duvidas ligadas ao backup postgres. Quem puder me
ajudar, serei grato.
Tenho 2 servidoras de banco, sincronizadas, versao 8.4, warm-standby .
A noite, inicializo o backup na servidora master, da seguinte forma.
select pg_start_backup('backup');
rm /diretorio_dos_archives/0*
tar -czvf dados.tar.gz /diretorio_de_dados
select pg_stop_backup();
Para esse caso, tenho algumas duvidas.
Primeira:
O tar reclama que alguns arquivos estao sendo gravados durante a
compactacao. veja:
tar: /postgres-bd_bhiss/var/lib/postgresql/8.4/main/base/1253378/2683.2:
file changed as we read it
Isso é normal ?
Segunda:
Como os archives sao copiados para um diretorio da 2a.maquina, slave ,
ela, apos recuperar os dados nas bases, os elimina.
O problema:
Quando fui efetuar um teste de restauracao em uma servidora de teste,
nao tinha os archives para o recovery.conf e ela passou a reclamar.
veja
cp: missing destination file operand after `/arquivos/0004.history'
Try `cp --help' for more information.
cp: missing destination file operand after
`/arquivos/0004057A0088'
Só consegui iniciar o postgres, utilizando o pg_resetxlog. Mesmo que
eu quisesse recuperar os dados, apenas do momento do backup, fiquei
sem saber se os dados seriam confiaveis
Terceira:
Notei que em outra servidora, apos os comandos de backup:
select pg_start_backup('backup');
rm /diretorio_dos_archives/0*
tar -czvf dados.tar.gz /diretorio_de_dados
Nesse ponto, aqui, outros archives passaram a ser gerados. Deveria ?
Nao deveria ser apos o stop do backup ?
select pg_stop_backup();
Obrigado,
Mauro.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Backup WAL PostgreSQL
Deduzo que voce esteja querendo ativar o archive archive_mode = on archive_command = 'cp %p /diretorio_onde_vc_queira_os_archives/%f' Mauro. 2011/6/1 Antonio Cesar cgcesarsoa...@gmail.com Pessoal estou tentando fazer um Backup WAL e retorna este erro alguem pode me ajudar? ERROR: WAL archiving is not active HINT: archive_mode must be enabled at server start. ___ 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] Duvida - Backup
Obrigado, Flávio.
Na verdade, o postgres permite a restauração mesmo sem o recovery.conf, a
diferença é que os dados restaurados serão apenas os do horário do backup.
O meu problema foi solucionado observando as mensagens no postmaster.log ,
já que não eram geradas no diretório de log.
Um dos problemas, era que o banco original estava com o locale em en_US e na
maquina de restauração era pt_BR. Configurei o locale e esta etapa passou.
Outro problema, foi que a maquina de dados era de 64 bits e a de restauração
de 32 bits. O postgres não restaura nessas condições.
Deixo mais uma dúvida. Se alguem puder me ajudar, eu agradeço .
Quando o backup estava sendo gerado via tar.. , o comando estava assim:
(Simplificando)
select pg_start_backup('teste');
tar -czvf arquivo.tar.gz /pg_data/
select pg_stop_backup();
O tar registrou que alguns arquivos estavam sendo alterados no momento do
tar. Isso é um problema ?
Obrigado,
Mauro.
Em 30 de maio de 2011 18:04, Flavio Henrique Araque Gurgel fha...@gmail.com
escreveu:
tar -xzvf meubackup.tar.gz (conforme diretorio postgres.conf )
criei o pg_xlog e archive_status dentro do pg_data.
Ele não start e nem cria qualquer tipo de log, ou seja, não acontece
nada.
Obrigado.
Você criou um recovery.conf?
Onde está o diretório com o archive?
O que saiu no log?
[]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
Re: [pgbr-geral] Duvida - Backup
Flávio,
Pelo que entendi, então o checkpoint_segments deverá estar com um valor
proporcional a um dia de backup . É isso ?
Como deveria ser o funcionamento para o caso de replicação ? A própria
servidora que recebe a replicação elimina os archives.
Mais uma vez, obrigado.
Mauro.
Em 31 de maio de 2011 11:45, Flavio Henrique Araque Gurgel fha...@gmail.com
escreveu:
Na verdade, o postgres permite a restauração mesmo sem o recovery.conf, a
diferença é que os dados restaurados serão apenas os do horário do
backup.
Não, isso não é verdade. Veja mais abaixo.
O meu problema foi solucionado observando as mensagens no postmaster.log
,
já que não eram geradas no diretório de log.
Um dos problemas, era que o banco original estava com o locale em en_US e
na
maquina de restauração era pt_BR. Configurei o locale e esta etapa
passou.
Ok.
Outro problema, foi que a maquina de dados era de 64 bits e a de
restauração
de 32 bits. O postgres não restaura nessas condições.
Correto.
Deixo mais uma dúvida. Se alguem puder me ajudar, eu agradeço .
Quando o backup estava sendo gerado via tar.. , o comando estava assim:
(Simplificando)
select pg_start_backup('teste');
tar -czvf arquivo.tar.gz /pg_data/
select pg_stop_backup();
O tar registrou que alguns arquivos estavam sendo alterados no momento do
tar. Isso é um problema ?
Não é um problema _se_ e _somente se_ você guardar o archive e
utilizar um recovery.conf na restauração. É justamente pra isso que
eles servem.
Se você retornar de um backup feito a quente sem o recovery.conf o
PostgreSQL não tem como saber em que local está seu archive e qual é o
checkpoint que finalizou imediatamente antes de seu backup começar.
Portanto, ele não ajustará as páginas que foram modificadas durante
seu backup.
Portanto, seu backup restaurado da forma como falou pode não estar
íntegro. Você pode ter problemas de integridade referencial,
inclusive.
[]s
Flavio.
___
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] Duvida - Backup
Amigos,
Estou testando a restauração de backups, mas não porquê, o postgres não
inicializa.
O meu ambiente é:
debian
postgres 8.4 (instalado via apt-get)
O backup foi feito da seguinte forma:
psql
select pg_start_backup('teste');
No prompt:
tar -czvf meubackup.tar.gz /var/lib/postgres/8.4/main --exclude=pg_xlog
psql
select pg_stop_backup();
Na nova servidora, copiei os dados dos confs da maquina original para a do
teste de backup
scp maquinaX:/etc/postgres/8.4/main /etc/postgres/8.4/main (nao existia um
main na maquina original)
tar -xzvf meubackup.tar.gz (conforme diretorio postgres.conf )
criei o pg_xlog e archive_status dentro do pg_data.
Ele não start e nem cria qualquer tipo de log, ou seja, não acontece nada.
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] Pgpool ii 3 + postgres 9
Você diz instalar um mais de um pgpool na mesma máquina ? Pela configuração de uma só instalação eu não consegui uma forma de ouvir mais de uma porta. Como você sugere ? Em 23 de março de 2011 23:40, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Que tal rodar mais de uma instância do pgpool? Em 23 de março de 2011 17:15, mauro fonseca mfons...@pbh.gov.br escreveu: Emerson, O porém, é que eu preciso de mais de uma porta de entrada no pgpool , pois os backend´s seriam clusters distintos e com serviços distintos. O pgpool não teria como indentificar o que viria pela porta 5433 e que iria para o cluster1 ou para o cluster2. Exemplo: pgpool 5433 - cluster1 (porta5434 e porta5435) pgpool 5440 - cluster2 (porta5441 e porta5442) De qualquer forma, obrigado. Em 23 de março de 2011 16:45, Emerson Hermann emersonherm...@gmail.com escreveu: Olá Mauro, Já tentou alterar os parametros system_db_hostname = 'localhost' system_db_port = 5433 e backend_hostname0 = 'servidor1' backend_port0 = 5434 backend_hostname1 = 'servidor2' backend_port1 = 5435 no pgpool.conf Espero ter ajudado. Emerson Hermann Em 23 de março de 2011 09:17, mauro fonseca mfons...@pbh.gov.br escreveu: Companheiros, Tenho a seguinte situação: 2 servidora postgres 9 , sincronizadas, hotstandby . Nelas estão serão instalados o pgpool e na primeira (será sincronizado para a segunda ), 3 clusters utilizando as portas 5433 ,5434 e 5435 , com serviços totalmente diferente. Criei cluster para aproveitar a capacidade do equipamento e facilitar a manutenção com independência para cada um deles.. O Problema. O pgpool trabalha recebendo em determinada porta, no caso 5432 e distribuindo os selects entre os 2 equipamentos. Até aí tudo bem. O fato é que o pgpool recebe em apenas 1 porta e distribui para os 2 equipamentos. Mas eu tenho 3 clusters com serviços diferentes. Teria como o pgpool trabalhar recebendo, por exemplo na 5432 e distribuindo para a 5532 nos 2 equipamentos, recebendo na 5533 e distribuindo para a 5533, recebendo na 5434 e distribuindo para a 5534 nos 2 equipamentos. Obrigado por qualquer ajuda. ___ 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 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 mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Pgpool ii 3 + postgres 9
Companheiros, Tenho a seguinte situação: 2 servidora postgres 9 , sincronizadas, hotstandby . Nelas estão serão instalados o pgpool e na primeira (será sincronizado para a segunda ), 3 clusters utilizando as portas 5433 ,5434 e 5435 , com serviços totalmente diferente. Criei cluster para aproveitar a capacidade do equipamento e facilitar a manutenção com independência para cada um deles.. O Problema. O pgpool trabalha recebendo em determinada porta, no caso 5432 e distribuindo os selects entre os 2 equipamentos. Até aí tudo bem. O fato é que o pgpool recebe em apenas 1 porta e distribui para os 2 equipamentos. Mas eu tenho 3 clusters com serviços diferentes. Teria como o pgpool trabalhar recebendo, por exemplo na 5432 e distribuindo para a 5532 nos 2 equipamentos, recebendo na 5533 e distribuindo para a 5533, recebendo na 5434 e distribuindo para a 5534 nos 2 equipamentos. Obrigado por qualquer ajuda. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Pgpool ii 3 + postgres 9
Emerson, O porém, é que eu preciso de mais de uma porta de entrada no pgpool , pois os backend´s seriam clusters distintos e com serviços distintos. O pgpool não teria como indentificar o que viria pela porta 5433 e que iria para o cluster1 ou para o cluster2. Exemplo: pgpool 5433 - cluster1 (porta5434 e porta5435) pgpool 5440 - cluster2 (porta5441 e porta5442) De qualquer forma, obrigado. Em 23 de março de 2011 16:45, Emerson Hermann emersonherm...@gmail.comescreveu: Olá Mauro, Já tentou alterar os parametros system_db_hostname = 'localhost' system_db_port = 5433 e backend_hostname0 = 'servidor1' backend_port0 = 5434 backend_hostname1 = 'servidor2' backend_port1 = 5435 no pgpool.conf Espero ter ajudado. Emerson Hermann Em 23 de março de 2011 09:17, mauro fonseca mfons...@pbh.gov.br escreveu: Companheiros, Tenho a seguinte situação: 2 servidora postgres 9 , sincronizadas, hotstandby . Nelas estão serão instalados o pgpool e na primeira (será sincronizado para a segunda ), 3 clusters utilizando as portas 5433 ,5434 e 5435 , com serviços totalmente diferente. Criei cluster para aproveitar a capacidade do equipamento e facilitar a manutenção com independência para cada um deles.. O Problema. O pgpool trabalha recebendo em determinada porta, no caso 5432 e distribuindo os selects entre os 2 equipamentos. Até aí tudo bem. O fato é que o pgpool recebe em apenas 1 porta e distribui para os 2 equipamentos. Mas eu tenho 3 clusters com serviços diferentes. Teria como o pgpool trabalhar recebendo, por exemplo na 5432 e distribuindo para a 5532 nos 2 equipamentos, recebendo na 5533 e distribuindo para a 5533, recebendo na 5434 e distribuindo para a 5534 nos 2 equipamentos. Obrigado por qualquer ajuda. ___ 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 mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] postgresql.conf databases distintos
Como sugeriu nosso amigo Fábio, você pode criar um outro cluster na mesma servidora. Nele você pode definir toda uma configuração para cada cluster que criar, tais como log, archive, liberar mais recursos e até mesmo restauração, independentes. Cada serviço terá sua própria porta. Trabalhamos com cluster aqui na empresa e acho muito mais fácil gerenciar o ambiente. O interessante é que você poderá trabalhar com versões diferentes do postgres na mesma máquina. Para criar o cluster: pg_cluster versão nomeDoCluster Ex. pg_cluster 8.4 faturamento pg_cluster 9.0 contabilidade Acredito que você está trabalhando com linux e para ver as outras opções de cluster , digite pg_ e a tecla tab . Em 10 de novembro de 2010 13:35, Tiago Valério tiagosvale...@gmail.comescreveu: Boa tarde, pessoal Tenho a seguinte duvida: Com dois databases existe a possibilidade de ter dois postgresql.conf.Um para cada database?Ou necessariamente teria que fazer outra instalação do postgres? Obrigado ___ 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] Unattended
Deduzindo que você utiliza linux. Após a instalação automatizada, vá ao diretório /etc/postgresql/9.0/main , dentro desse diretório você encontrará os arquivos de configuração do postgres. No caso da porta, o arquivo é o postgresql.conf , altere as linhas abaixo, colocando a porta que você desejar, veja: listen_addresses = '*' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to 'localhost', '*' = all # (change requires restart) port = 5432 Salve e saia do arquivo. Edite também no mesmo diretório, o arquivo pg_hba.conf e nele inclua os ip´s das máquinas cliente que terão acesso ao servidor, veja: # IPv4 local connections: hostall all 127.0.0.1/32md5 hostall all 10.0.10.1/32md5 hostall all 10.0.10.2/32md5 Após isso, reinicialize o postgres e altere a senha do usúario postgres . Para isso, dê um: # su - postgres psql -p portaQueVoceDefiniu enter no prompt do postgres que se abrirá, altere a senha do postgres postgres=# alter USER postgres ENCRYPTED PASSWORD 'senhaQueVoceDesejar'; Espero ter ajudado. Em 11 de novembro de 2010 16:11, Cleber Marques clebe...@gmail.comescreveu: Obrigado pela resposta Fabio, Na verdade eu consigo fazer toda a instalação automatizada, mas num tem um parâmetro para setar a porta. A grande questão é, não uso PostgreSQL, eu não trabalho com banco de dados, estou implementando uma tecnologia que distribui aplicações de forma automatizada. Neste cliente existe uma aplicação feita pela empresa que usa o PostgreSQL como banco, logo para eu distribuir esta aplicação tenho que distribuir também o PostgreSQL. Na minha humilde opinião, a aplicação que não é bem feita e a estrutura utilizada, de banco local não foi nada bem planejada. Porém, minha tarefa é distribuir isso, e não mudar J, se eu pudesse, isso não seria feito desta forma, com certeza hehe. Agora, já que o requisito do cliente é este, o que eu estou procurando é uma forma de automatizar isso J, a instalação é feita em Windows Client. Brigadão, *From:* pgbr-geral-boun...@listas.postgresql.org.br [mailto: pgbr-geral-boun...@listas.postgresql.org.br] *On Behalf Of *Fábio Telles Rodriguez *Sent:* quinta-feira, 11 de novembro de 2010 16:05 *To:* Comunidade PostgreSQL Brasileira *Subject:* Re: [pgbr-geral] Unattended Com um pouco de shell script tudo é possível... Em windows, bem aí eu não sei. Mas a questão, que já foi discutida aqui varias vezes é: Se você quer uma instalação automatizada, é porquê não tem um DBA ou equipe especializada para fazê-lo. Se você procura um banco de dados que rode sem a necessidade de manutenção, melhor utizar outro SGDB. Eu sugiro algo como SQLite. Não é um SGDB, é uma biblioteca que cria um banco com suporte a SQL. TXT puro, XML ou Berkeley BD podem ser alternativas mais interessantes para você. Se você precisa do poder de um SGDB como o PostgreSQL, você precisa de uma equipe especializada para instalar e manter o banco de dados. Você precisa fazer tuning, precisa cuidar do backup, precisa fazer vacuum, reindex, etc. Ou seja, pense bem por onde você está caminhando... []s Fábio Telles 2010/11/11 Cleber Marques clebe...@gmail.com Boa tarde pessoal, Sou novo na lista e queria saber se alguém pode me ajudar com a instalação não assistida do Postgresql 9.0.1, preciso instalar sem a interação, forçando a porta para 5433, e criando a senha de super usuário. Isso é possível? Obrigado ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.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] Pgadmin acessar pela rede
Beto, O seu ip é 192.168.1.171 ou 192.68.1.171 como você citou abaixo. Deve estar errado a informação. Em 9 de outubro de 2010 12:01, Beto Lima betol...@gmail.com escreveu: o meu ip tb está na mesma rede. ele é 192.68.1.71 ___ 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] Pgadmin acessar pela rede
Beto, Tudo leva crer que seu pg_hba.conf está com algum problema ou tem algum firewall bloqueando o acesso desta maquina remota. faça um backup do seu pg_hba.conf e no original substitua as linhas similares pelas abaixo: # local is for Unix domain socket connections only local all all ident # IPv4 local connections: hostall all 127.0.0.1/32 md5 hostall all 192.168.1.71/32 md5 Isso é só para testarmos. Faça um reload no seu postgres e tente novamente. Att. Mauro. Em 13 de outubro de 2010 12:03, Beto Lima betol...@gmail.com escreveu: desculpa errei na digitação, o ip é 192.168.1.71 ___ 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] Pgadmin acessar pela rede
Experimente colocar o ip da maquina de origem do acesso ( ou é localhost mesmo ? ), tipo # IPv4 local connections: hostall all 10.0.26.50/32 http://127.0.0.1/32 trust Você alterou a senha do postgres para o acesso ? A porta do postgres é a 5432 ou está utilizando outra ? 2010/10/8 Beto Lima betol...@gmail.com Pessoal tive que instalar do zero o 8.4 num servidor aqui e quero acessar pela rede com pgadmin. antes tava funcionando, mas tive que formatar e instalar tudo de novo e agora não consigo mais acesso. ja deixei o listen_address como * no postgres.conf meu pg_hba.conf está assim: # Database administrative login by UNIX sockets host all all 0.0.0.0 0.0.0.0 trust # TYPE DATABASEUSERCIDR-ADDRESS METHOD # local is for Unix domain socket connections only local all all trust # IPv4 local connections: hostall all 127.0.0.1/32 trust #hostall all 0.0.0.0/0 trust # IPv6 local connections: hostall all ::1/128 trust hostall all0.0.0.0/0 trust Alguma luz? grato ___ 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] Erro na Gravação
Tá me parecendo falha na rede. Pelo que parece em alguns momentos o cliente não consegue chegar ao servidor. Em 8 de outubro de 2010 11:20, Alexandre Dall' Agnese alexandre.agn...@gmail.com escreveu: Bom Dia Pessoal! Sou novato na lista e em Postgres. Tenho uma aplicação online em vários pontos de acesso. Para cada empresa crio um banco de dados diferente e uma role, sendo que para tal libero acesso para 3 micros diferentes. EX: banco: loja usuario:loja1 senha:loja1. Para 3 ou 4 maquinas da loja1 eu libero a conexão com esses dados. Acontece que de 1 mes para cá esta dando erro direto e as loja estap reclamando. De 15 a 20 minutos de trabalho, no sistemas dá o seguinte erro Conexão Negada fala em postmaster e tb em timed out. no log do banco dá EOF, erro ao receber dados do cliente e pacote de inicialização incompleto. Alguem poderia dar uma luz Aguardo... e agradeço desde ja a compreensão. Ats. Alexandre ___ 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] Streming Replication
Nos meus testes, meu standby está configurado assim: wal_level = hot_standby hot_standby = on E está funcionando redondo, pelo menos em relação ao sincronismo e ao select. Inicialmente eu tive esta mensagem também, mas parei os 2 servidores, fiz um backup do main no primário, removi o main no secundário e extraí nele o backup feito. Iniciei o secundário e depois o master. Aproveitando a resposta e faço a pergunta. Como se dará a distribuição dos selects, ou seja, ora o select é no primário , ora é no secundário. Abraço. Mauro. Em 8 de outubro de 2010 14:34, gilmarli...@agrovale.com.br escreveu: Entendi Mateus. Aqui comecei a fazer um testes, porem não entendi o porque o servidor standby, esta gerando a seguinte mensagem: FATAL: database system identifier differs between the primary and standby DETALHE: The primary's identifier is 5525672265941739454, the standby's identifier is 5525673958158856113. FATAL: database system identifier differs between the primary and standby DETALHE: The primary's identifier is 5525672265941739454, the standby's identifier is 5525673958158856113. FATAL: database system identifier differs between the primary and standby DETALHE: The primary's identifier is 5525672265941739454, the standby's identifier is 5525673958158856113. O postgres.conf do servidor master esta desta forma abaixo: wal_level = hot_standby # minimal, archive, or hot_standby max_wal_senders = 3 wal_sender_delay = 200ms wal_keep_segments = 20 O Servidor slalve possui o arquivo recovery.conf dentro do data. standby_mode = 'true' primary_conninfo = 'host=192.168.1.52 port=5573' trigger_file = '/tmp/arquivo_gatilho.psql' Obs. tentei alterar o arquivo postgres.conf do serivdor slave o parametro, hot_standby = on, porem ele reclamou, então retirei o parametro. Talvez você tenha ideia do que pode ser. Em 8 de outubro de 2010 17:45, gilmarli...@agrovale.com.br escreveu: Obrigado novamente pela sua pasciencia e disponibilidade. Encontrei um material da propria dextra no link abaixo, http://www.slideshare.net/dextra/dextra-novidades-postgresql-90 No slite numero 24 mostra um exemplo da integração do hot_standby e streeming replication, penso que e isto que vc informou que e interessante a fazer. Neste manterial e mostrado no arquivo recovery.conf uma linha trigger_file = '/tmp/arquivo_gatilho.psql' porem não vi o conteudo dela, e esta triguer que pega o uso os logs em streeming e insere no standby? Não. Este é apenas um arquivo de gatilho, o qual o servidor slave verifica constantemente pela sua existência. O arquivo pode ser vazio e ao ser criado, indica que o servidor slave deve se transformar em master e sair do modo read-only (hot standby) para aceitar também alterações. Este arquivo pode ser criado tanto para replicação Warm Standby quanto Hot Standby. A diferença para outras versões é que a 9.0 conta com um parâmetro específico (trigger_file) no recovery.conf para definir o arquivo. Em 8 de outubro de 2010 16:20, gilmarli...@agrovale.com.br escreveu: Agradeço sua tenção, Porem só para esclarecer mais um pouco. Então para que o servidor standby aceitar consultas, tenho que enviar o logs para o mesmo? Não. O Hot Standby permite que você execute consultas no slave, independente se a atualização estiver ocorrendo via Streaming Replication ou arquivamento de xlogs. Não e possivel fazer o standby pegar as requisições via streaming replication e inseri-la na base do mesmo? É possível sim, e é o mais interessante de se fazer. Atualizar a base constantemente com Streaming Replication e deixá-la em read-only com Hot Standby. Att. -- Matheus Ricardo Espanhol --- Dextra Sistemas http://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 mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Matheus Ricardo Espanhol --- Dextra Sistemas http://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 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] Pgadmin acessar pela rede
Tente dar um telnet a partir do prompt da sua máquina. telnet 192.168.1.5 5432 e mostre o que aconteceu. Disponibilize o seu log e o pg_hba.conf para que possamos entender melhor o erro. Em 8 de outubro de 2010 16:00, Beto Lima betol...@gmail.com escreveu: ja coloquei meu ip tb e não foi, 192.168.1.65 Você alterou a senha do postgres para o acesso ? sim coloquei posgres A porta do postgres é a 5432 ou está utilizando outra ? é 5432 e estou usando outro usuario pra conexao: user beto e senha beto pelo phppgadmin vai na boa, mas pelo pgadmin não... só diz conexão falhou ___ 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] Pgadmin acessar pela rede
Beto, O Seu xp está também na rede 192ou tem uma rota para ela ? Se não, é isso. Você está tentando alcançar uma rede da qual você não faz parte. Se o seu xp estiver em uma rede interna, qual é o ip ? no prompt do windows dê um ipconfig /all e você o verá. 2010/10/8 Beto Lima betol...@gmail.com pg_hba.conf sobre o telnet chamei assim: telnet 192.168.1.65 5432 e não abriu nada uso xp aqui e o server é ubuntu. onde posso pegar esse log? # DO NOT DISABLE! # If you change this first entry you will need to make sure that the # database # super user can access the database using some other method. # Noninteractive # access to all databases is required during automatic maintenance # (custom daily cronjobs, replication, and similar tasks). # # Database administrative login by UNIX sockets host all all 0.0.0.0 0.0.0.0 trust # TYPE DATABASEUSERCIDR-ADDRESS METHOD # local is for Unix domain socket connections only local all all trust # IPv4 local connections: hostall all 127.0.0.1/32 trust hostall all 192.168.1.0255.255.255.0trust # IPv6 local connections: hostall all ::1/128 trust hostall all0.0.0.0/0 trust ___ 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
