[pgbr-geral] Res: Res: Re: Postgres x GBuster ou Sistemas Bancos
> Infelizmente acabou de parar o postgres novamente,,, única coisa que consta > no log desde hoje de madrugada é isso: > > > > 2016-04-13 14:02:14 BRT WARNING: worker took too long to start; canceled > 2016-04-13 14:03:19 BRT WARNING: worker took too long to start; canceled > 2016-04-13 14:04:21 BRT WARNING: worker took too long to start; canceled > 2016-04-13 14:05:23 BRT WARNING: worker took too long to start; canceled > 2016-04-13 14:06:25 BRT WARNING: worker took too long to start; canceled > 2016-04-13 14:07:27 BRT WARNING: worker took too long to start; canceled > > A última tentativa foi configurar o postgresql.conf conforme o link indicado > neste email... não resolveu > Eu utilizo fora do diretório padrão da instalação, conforme sugestão anterior e mesmo assim o problema ocorre. Como vc esta com problemas em produção, sugiro que escreva para outra lista [1] e/ou pesquise na lista internacional [2] se ainda não fez... [1] - http://www.postgresql.org/list/ [2] - http://www.postgresql.org/search/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Re: Res: Re: Res: Re: Postgres x GBuster ou SistemasBancos
Apenas para registrar o fato, também estamos com esse problema, em menor escala mas vem acontecendo... São máquinas com Windows 10 64bits, com PostgreSQL 9.2.3, em 2 máquinas que apresentam essa situação, diferente do amigo, não possuem instalados qualquer aplicativo de banco (GBuster, etc). Nesses nossos casos o serviço simplesmente para... mas o PostgreSQL ainda esta on, no entanto não aceita mais conexões... Como são máquinas de desenvolvedores e nosso sistema ainda não esta homologado para Windows 10 acabamos deixando de lado esse problema > Primeiro que o equipamento tem de ser decente, não descente. Se ele desce, é > por causa do MS Windows talvez, mas isso não vem ao caso. O Gurgel já pediu > informações sobre carga. Também acho que o problema esta relacionado com o SO Windows, pode ser permissões no diretório pgdata, mas não identifiquei essa situação nos nossos casos... Ou então algo relacionado ao gerenciamento de usuários... Att. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] REF: Instalação Silenciosa com Apache.
> Preciso configurar a instalação silenciosa do PostgreSQL 9.3, já > habilitando o Apache. > Alguém pode dar uma dica do comando? Windows: postgresql-9.x.x.x-windows-xyy.exe --unattendedmodeui minimal --mode unattended --superaccount useracc --serviceaccount useracc --servicepassword passwd --superpassword suppasswd --locale C --datadir "c:\pgsql\" --debuglevel 2 Linux: yum/apt-get/zypper ou compilar... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] could not send data to client: Conexão fechada pela outra ponta
Pessoal, estou com uma situação que não consigo identificar a origem do problema. O cliente reclama que o sistema perde conexão com o banco de dados sem motivo aparente, não é possível simular o problema (nem eu nem ele conseguimos reproduzir no momento que queremos), acontece muitas vezes em intervalo de minutos, outras vezes passam-se horas até um erro ocorrer... Apenas algumas estações apresentam o problema. O erro no log do PostgreSQL é: could not send data to client: Conexão fechada pela outra ponta. Verifiquei nos fontes do PostgreSQL que esse erro é disparado de dentro da pqcomm (src/backend/libpq/), nele está a mensagem could not send data to client:, não entendi de onde vem o restante da mensagem: Conexão fechada pela outra ponta. Não estou conseguindo identificar a origem do problema, acredito que seja algo relacionado a rede do cliente. Alguém pode me auxiliar a entender a origem do problema? PostgreSQL 9.2.8 SO: OpenSuse 13.2 ERP escrito em Delphi utilizando drivers de conexão Devart. Solicitem se precisar de mais informações... Erro reportado no PostgreSQL: 2015-10-30 11:05:56 BRST; remote_host: 192.168.3.1(64285); pid: 14647; cmd_tag: idle; sql_state: 08006; sess_id: 56329d3d.3937; sess_start_tms: 2015-10-29 20:27:09 BRST; trans_id: 0 LOG: could not send data to client: Conexão fechada pela outra ponta ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] could not send data to client: Conexão fechada pela outra ponta
Obrigado pelas respostas... > Você tem log de erros na aplicação? Tenho log sim, os componentes (Delphi) me retornam essa mensagem: Error on data writing to the connection: Foi forçado o cancelamento de uma conexão existente pelo host remoto. Socket Error Code: 10054($2746). > Sim pode ser um firewall no "meio do caminho" encerrando a conexao, pode ser > firewall na maquina do cliente. Uma coisa eh certa, a conexao foi perdida de > forma inexperada mesmo, nao foi o Postgres que encerrou a conexao, mas nada > impede de a sua aplicacao ou algo entre ela e o servidor ter provocado isto. > As vezes, em redes "mais antigas" ate mesmo colisão de pacotes. Não eh > descartado. Acredito mais na hipótese de que algo entre aplicação de banco tenha derrubado a conexão, firewall, antivírus, talvez IPV6 (pesquisando vi posts em java+postgresql falando nesse assunto) ou algo assim. Pois não são todas as máquinas que perdem a conexão, de 20 estações umas 3,4 apresentam esse problema. > O problema é intermitente, mas existe algum marco (data) do início deste > problema? Não consigo definir um inicio, a aplicação é modificada constantemente... nessas maquinas que apresentam erros não existe um programa que "force" o erro, muitas vezes apenas o fato da aplicação estar aberta, parada ocasiona a queda na conexão, como em outros momentos acontece erro ao efetuar login > Caso exista, e não tenha ocorrido alterações na aplicação, creio que já > ocorra o descarte da mesma como causa do problema, ou mesmo um > encaminhamento direto à alguma alteração que tenha sido realizada na mesma. > Já houve tentativa de diagnóstico de algum problema de rede, perda/colisão > de pacotes e etc.? Perda de pacotes foi monitorado, não perde nada e o tempo é normal se tratando de rede interna. Como falei anteriormente, acredito que seja entre a aplicação e o banco pois caso fosse a aplicação todas as estações estariam com o mesmo problema, todos os clientes também estariam reportando esse erro. Obrigado a todos pela atenção, vou verificar algo relacionado a rede ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] testar latencia AWS
> Douglas, analise todo o processo e tente reduzir a quantidade de requisições > que a aplicação faz ao banco de dados, com isso você conseguirá reduzir o > tempo total do processo. Não sei se é o caso, mas ele falou em ERP, nesse caso duvido que tenha um ponto apenas que precisara ser melhorado... Acredito que seja inviável adaptar o software para que atenda de forma razoável O problema é o Delphi, seus componentes e drivers, não são otimizados para se trabalhar com uma base remota. Se você esta utilizando Datasnap sugiro que coloque seu Srv de Aplicação o mais próximo do banco de dados possível (use protocolo TCP). Conheço apenas um caso em que uma determinada empresa que utiliza Delphi + Datasnap + PostgreSQL migrou para AWS com sucesso (até onde sei...). ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Trigger bloqueando (ExclusiveLock) operações
> Essa é uma limitação conhecida (até a 9.2). A partir do 9.3, isso foi > resolvido com uma nova sintaxe que bloqueia transações se, e somente se, a > chave for alterada (colunas que não participam da FK não mais bloqueiam > transações -- como é o seu caso). Portanto, atualize para versão 9.3 ou > superior que não haverá o bloqueio para este caso. Perfeito Euler! Minutos antes de ler a sua resposta fiz alguns testes e cheguei a essa conclusão. Também já tinha lido na documentação sobre esse bloqueio mas os meus testes não me mostravam isso. Eu estava usando nos testes um disable trigger all que desativa inclusive a validação da FK, por isso passavam e me fizeram acreditar que o problema estava relacionado ao uso da trigger, engano meu, é realmente relacionado a FK No radmap do PostgreSQL consta que a liberação da versão 9.5 é pra agora, 4° trimestre. Tens alguma informação em relação a data de liberação? Vale a pena já trabalhar para homologar a versão 9.5 ou é muito cedo (em virtude de bugs que poderão surgir no lançamento da versão)? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Tabela com bloqueio (lock)
Pessoal, estou com uma tabela que aparentemente está com um Lock mas não consigo encontrar quem fez isso. Em virtude do lock a tabela está indisponível, não responde mais a selects, inserts, deletes ou updates. O que posso fazer para voltar essa tabela? Como identificar que transação travou ela (isso se foi uma transação)? Aproveito para perguntar qual o nível de isolamento vocês costumam utilizar? Ambiente: PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, compiled by gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773], 64-bit SO OpenSuse 12.2 Abaixo o retorno do analyze: INFO: vacuuming public.tb_clientes INFO: scanned index clientes_001 to remove 50 row versions DETAIL: CPU 0.10s/0.37u sec elapsed 0.52 sec. INFO: scanned index clientes_002 to remove 50 row versions DETAIL: CPU 0.08s/0.36u sec elapsed 0.45 sec. INFO: tb_clientes: removed 50 row versions in 33 pages DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index clientes_001 now contains 8287018 row versions in 41091 pages DETAIL: 50 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index clientes_002 now contains 8287018 row versions in 31911 pages DETAIL: 50 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: tb_clientes: found 303 removable, 10430 nonremovable row versions in 127 out of 93475 pages DETAIL: 18 dead row versions cannot be removed yet. There were 6 unused item pointers. 0 pages are entirely empty. CPU 0.19s/0.74u sec elapsed 0.99 sec. INFO: analyzing public.tb_clientes INFO: tb_clientes: scanned 3 of 93475 pages, containing 2659810 live rows and 4 dead rows; 3 rows in sample, 8286201 estimated total rows VACUUM ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Dúvida relacionada ao consumo de memória do PostgreSQL
Pessoal, tenho um servidor com as configurações abaixo. Servidor (VIRTUALIZADO): - SO Linux (OpenSuse 12.2 – 64bits) - Processador 8 núcleos - Memória 60GB - Storage (não lembro especificações) - Dedicado PostgreSQL - 9.2 64bits compilado - Database com 290GB - 200 conexões - Replicação nativa configurada +---+ |Parâmetro | Sugestão (pgTune) | Valor Aplicado| +---+ | shared_buffers |3840MB |5120MB | | effective_cache_size |15GB |18GB | | work_mem |16MB |448MB | | maintenance_work_mem |2GB |3GB | | checkpoint_completion_target|0.5 |0.5 | | wal_buffers |16MB |-1 | | default_statistics_target|100 |500 | ++ Aplicação: - Desktop - ERP Se executar um free –m total used free sharedbuffers cached Mem: 6052160087 433 0 13 46807 -/+ buffers/cache: 13266 47254 Swap: 2053570 1483 Se verificar apenas a memória utilizada pelo PostgreSQL: 9.6GB (http://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/) Me corrijam se eu estiver errado, analisando as últimas duas informações vejo que os processos do PostgreSQL (200 threads) consomem 9.6GB com processamento, ou seja, meu servidor está com aprox.. 50GB “livre”, que utiliza para cache, como visto no “free –m”! Minha analise está correta? Para melhorar a performance, tem alguma coisa que possa ser feita? Abaixo um proinfo Memory: TotalUsed Free Shared Buffers Cached Mem: 6197404061567592406448 0 10072 48506024 Swap: 2103292 563704 1539588 Bootup: Thu May 22 00:05:22 2014Load average: 2.61 1.99 1.84 5/501 22576 user : 84d 15:05:28.06 12.4% page in :33149899492 disk 1: 6202296r15522309w nice : 1:20:20.65 0.0% page out:14719711635 disk 2: 587484665r247231808w system: 7d 2:29:26.12 1.0% page act: 4226920920 IOwait: 17d 18:15:53.63 2.6% page dea: 3930344022 hw irq: 0:02:56.40 0.0% page flt:61829458181 sw irq: 22:24:06.70 0.1% swap in :4557108 idle : 563d 11932:715834:42949682.63 83.0% swap out:6771894 uptime: 84d 17:08:01.85 context :19138602798 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro ao restaurar backup (pg_dump) realizado em um servidor replicado
Preciso novamente da ajuda de vocês! Possuo um ambiente com PostgreSQL 9.2 (PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, compiled by gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773], 64-bit) e OpenSuse 12.2 com replicação nativa configurada. Fiz um backup da base no servidor SLAVE usando pg_dump (pg_dump database -b -Fc -f backup.bak) e levei para outro servidor (de homologação) com a mesma versão do PostgreSQL e SO. Quando tento restaurar a base de dados (pg_restore -d database -Fc backup.bak) no servidor de homologação tenho uma saída de erro: “pg_restore: [custom archiver] unexpected end of file pg_restore: [archiver] worker process failed: exit code 1” E a restauração não é concluída! O log do PostgreSQL tem a seguinte informação: 2014-07-22 16:21:49 BRT ERROR: unexpected message type 0x58 during COPY from stdin 2014-07-22 16:21:49 BRT CONTEXT: COPY tabela1, line 10692748: 44543606.0 249628.039792063.0 4 41 1 0 1 0 0 \N 1 38.85 38.85 1 2014-07-22 16:21:49 BRT STATEMENT: COPY tabela1 (cmp1, cmp2, cmp3, cmp4, cmp5, cmp6, cmp7, cmp8, cmp9, cmp10, cmp11, cmp12, cmp13, cmp14, cmp15, cmp16, cmp17, cmp18, cmp18, cmp19, cmp20, cmp21, cmp22, cmp23, cmp24, cmp25, cmp26, cmp27, cmp28, cmp29, cmp30, cmp31, cmp32, cmp33, cmp34, cmp35, cmp36) FROM stdin; 2014-07-22 16:21:50 BRT LOG: could not send data to client: Pipe quebrado 2014-07-22 16:21:50 BRT STATEMENT: COPY tabela1 (cmp1, cmp2, cmp3, cmp4, cmp5, cmp6, cmp7, cmp8, cmp9, cmp10, cmp11, cmp12, cmp13, cmp14, cmp15, cmp16, cmp17, cmp18, cmp18, cmp19, cmp20, cmp21, cmp22, cmp23, cmp24, cmp25, cmp26, cmp27, cmp28, cmp29, cmp30, cmp31, cmp32, cmp33, cmp34, cmp35, cmp36) FROM stdin; Entretanto, se o backup é feito no servidor MASTER a restauração no servidor de homologação é concluída com sucesso. O pg_controldata tem as seguintes informações: srv-master:~ # pg_controldata pg_control version number:922 Catalog version number: 201204301 Database system identifier: 5866782369715847035 Database cluster state: in production pg_control last modified: Thu 24 Jul 2014 09:20:48 AM BRT Latest checkpoint location: F39/AA0D00C0 Prior checkpoint location:F39/9C5DA148 Latest checkpoint's REDO location:F39/A39C37F0 Latest checkpoint's TimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0/256831503 Latest checkpoint's NextOID: 7796298 Latest checkpoint's NextMultiXactId: 201472 Latest checkpoint's NextMultiOffset: 483528 Latest checkpoint's oldestXID:150001583 Latest checkpoint's oldestXID's DB: 12593 Latest checkpoint's oldestActiveXID: 256831500 Time of latest checkpoint:Thu 24 Jul 2014 09:18:43 AM BRT Minimum recovery ending location: 0/0 Backup start location:0/0 Backup end location: 0/0 End-of-backup record required:no Current wal_level setting:hot_standby Current max_connections setting: 280 Current max_prepared_xacts setting: 10 Current max_locks_per_xact setting: 64 Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 WAL block size: 8192 Bytes per WAL segment:16777216 Maximum length of identifiers:64 Maximum columns in an index: 32 Maximum size of a TOAST chunk:1996 Date/time type storage: 64-bit integers Float4 argument passing: by value Float8 argument passing: by value srv-slave:~ # pg_controldata pg_control version number:922 Catalog version number: 201204301 Database system identifier: 5866782369715847035 Database cluster state: in archive recovery pg_control last modified: Thu 24 Jul 2014 09:17:34 AM BRT Latest checkpoint location: F39/9C5DA148 Prior checkpoint location:F39/982EC280 Latest checkpoint's REDO location:F39/997C2908 Latest checkpoint's TimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0/256831503 Latest checkpoint's NextOID: 7796298 Latest checkpoint's NextMultiXactId: 201470 Latest checkpoint's NextMultiOffset: 483524 Latest checkpoint's oldestXID:150001583 Latest checkpoint's oldestXID's DB: 12593 Latest checkpoint's oldestActiveXID: 256826091 Time of latest checkpoint:Thu 24 Jul 2014 09:13:43 AM BRT Minimum recovery ending location: F39/B816D438 Backup start location:0/0 Backup end location: 0/0 End-of-backup record required:no Current wal_level setting:hot_standby Current max_connections setting: 280 Current max_prepared_xacts setting:
[pgbr-geral] Falha Streaming Replication + Vacuum
Espero ter ajudado.. Vlw galera obrigado pela ajuda... Tanto restore_command quanto wal_keep_segments funcionam perfeitamente cada um com suas vantagens ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Falha Streaming Replication + Vacuum
Amigos, estou com um problema em uma replicação PostgreSQL 9.2.3 (OpenSuse 12.2) usando Streaming Replication. O problema ocorre ao executar uma rotina de vacuum (de forma manual) e os servidores perdem o sincronismo. Log do srv Slave: 2013-12-08 04:14:39 BRST [10615]: [2-1] user=,db= FATAL: could not receive data from WAL stream: FATAL: requested WAL segment 000104BC0039 has already been removed Log srv Master: 2013-12-08 03:55:15 BRST FATAL: requested WAL segment 000104BC0039 has already been removed Pesquisando na lista encontrei algumas informações bem úteis para o meu caso (http://listas.postgresql.org.br/pipermail/pgbr-geral/2011-May/024674.html) - sugere-se o incremento do parâmetro wal_keep_segments. Atualmente tenho as seguintes configurações para WAL: wal_level = hot_standby max_wal_senders = 1 wal_keep_segments = 60 checkpoint_segments = 60 checkpoint_timeout = 5min Dúvidas: 1) Aumentando o valor de wal_keep_segments devo aumentar também checkpoint_segments ou não tem nada a ver? 2) Apesar do Euler ter respondido na outra thread como estimar o valor para wal_keep_segments, ainda assim fiquei na dúvida. Posso utilizar como parâmetro minha maior tabela? (48GB) para definir o valor de wal_keep_segments? wal_keep_segments = 49152MB/16MB? Isso seria suficiente para que minha rotina de vacuum concluísse sem comprometer a replicação? -- Eurides V. Baptistella E-mail: eurides.baptiste...@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] Falha Streaming Replication + Vacuum
Para não ter esse problema o ideal é arquivar os logs de transação por pelo menos 1 dia e definir restore_command no recovery.conf. Assim, você nunca precisará refazer o servidor réplica ou ser pego de surpresa porque um REINDEX ou VACUUM consumiu todo wal_keep_segments definido previamente. Certo Euler, mas neste caso eu teria que abandonar a replicação por Streaming? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Coletar estatísticas (volume de inserts, deletes, updates) PostgreSQL
Amigos, estou precisando recuperar uma informação do PostgreSQL: - Percentual de inserts que ocorreram entre dois períodos (T1, T2) em um determinado database. Existe a view pg_stat_database que possui informações sobre o volume de inserts, updates, deletes que ocorreram em um database (select tup_inserted from pg_stat_database where datname=’meu_database’), mas eu preciso de um percentual. Qual foi a porcentagem de inserções que tive em determinado database entre uma coleta e outra. Isso é possível? De que forma? Obs.: - PostgreSQL 9.2 - Não pretendo trabalhar com tabelas auxiliares (temporárias) para obter a estatística. *-- Eurides V. Baptistella **E-mail:* eurides.baptiste...@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] Coletar estatísticas (volume de inserts, deletes, updates) PostgreSQL
Obrigado pelas respostas! Outra técnica é reiniciando as estatísticas: SELECT pg_stat_reset(); Preciso esclarecer outro detalhe, estou coletando as informações e utilizando no Zabbix, não posso zerar as estatísticas. te aconselho usar outras ferramentas para auxiliar como o PGObserver[1] ou o pgBadger[2] Como falei anteriormente, as informações serão utilizadas no Zabbix. E sim, o pgBadger apresenta essas informações, mas ele faz a coleta em cima de logs Pode rodar o reset sem dó. Não posso, tenho outros gráficos no Zabbix com a evolução das inserções, updates, deletes ... *-- Eurides V. Baptistella **E-mail:* eurides.baptiste...@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] Coletar estatísticas (volume de inserts, deletes, updates) PostgreSQL
Então, parece que a única solução é coletando os dados mesmo, de tempo em tempo, e salvando num local a parte. De qualquer forma, como você disse usa o Zabbix, não basta fazer isso por ele? Configure-o para coletar essas informações, em seguida é só filtrar os períodos. Então Matheus, estou seguindo essa linha, vou tentar utilizar um tipo de dado calculado para chegar a essa porcentagem. Obrigado pelas respostas *-- Eurides V. Baptistella **E-mail:* eurides.baptiste...@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] Streaming Replication com PITR no Servidor Slave
Desculpe pessoal mas não estou mais recebendo os e-mails da lista, o último que recebi foi no dia 08/06/2013, vou tentar consertar isso... Quanto as informações, obrigado pelas respostas, apenas uma dúvida: Considerando utilizar o pg_basebackup no servidor Slave, eu não consigo realizar backups incrementais correto? nesse caso o pg_basebackup seria uma espécie de dump mesmo? *-- Eurides V. Baptistella **E-mail:* eurides.baptiste...@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] Streaming Replication com PITR no Servidor Slave
Olá pessoal, estou tendo dificuldades em configurar um servidor Slave para
fazer backup incremental (PITR).
Para replicação utilizo a nativa do PostgreSQL (Streaming Replication).
A versão do PostgreSQL 9.2.3 compilada: PostgreSQL 9.2.3 on
x86_64-unknown-linux-gnu, compiled by gcc (SUSE Linux) 4.7.1 20120723
[gcc-4_7-branch revision 189773], 64-bit
A replicação está funcionando ok, sem problemas.
O backup não está rolando, o Slave gera arquivos na pasta pg_xlog.
Quando executo o comando start_backup retorna um erro:
dados=# select pg_start_backup('replication', true);
ERROR: recovery is in progress
HINT: WAL control functions cannot be executed during recovery.
E para pg_is_in_recovery():
dados=# select pg_is_in_recovery();
pg_is_in_recovery
---
t
Minhas config no server Slave são:
Para backup PITR
archive_mode = on
wal_level = archive # já tentei hot_standby
archive_command = 'cp %p /srv/map/pg_arclog/%f '
E para a replicação:
hot_standby = on
Se eu entendi certo, o archive_command é executado apenas quando eu executo
um backup com pg_start_backup(), nesse momento é utilizando o parâmetro
archive_command! Estou certo?
Se esse for o caminho, então estou com alguma configuração errada pois o
pg_start_backup não roda no servidor slave.
Alguma ideia?
*--
Eurides V. Baptistella
**E-mail:* eurides.baptiste...@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] Migração do Postgres 8.2 para 9.2 - Problemas com Casts e Operadores
E ai pessoal, beleza? Nos últimos dias estive empenhado realizando a migração de nossas aplicações que utilizavam o PostgreSQL 8.2.x para a versão recente 9.2.x. Upgrade bem grande... Bom, tive vários problemas, mas praticamente todos relacionados a cast ou com operadores (varchar = numeric) (numeric like varchar) ... coisas do gênero. Resolvi os problemas criando meus próprios casts e operadores, no entretanto não acho essa seja a melhor solução, mas é a menos custosa pois são várias funcions e triggers. Gostaria de saber a opinião de vocês quanto a isso. - Já realizaram uma migração parecida? - Tiveram problemas com cast e operadores? - Como resolveram os problemas? Valeu, obrigado pela colaboração... *-- Eurides V. Baptistella **E-mail:* eurides.baptiste...@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] Migração do Postgres 8.2 para 9.2 - Problemas com Casts e Operadores
Legal Fabrízio! Realmente temos um ambiente parecido. Aplicação legada, +1050 tabelas, +1050 functions, +500 triggers É difícil refatorar uma aplicação grande e legada em pouco tempo, sem contar os valores financeiros investidos em tantas horas de refatoração... Praticamente elencamos os mesmos passos nessa migração, (o item 9 no meu caso se chama Correr pro abraço rsrs). O item 7 não havia avaliado dessa forma, mas vou verificar a possibilidade de deixar um monitoramento nos logs e assim ter uma resposta mais rápida. Se não for pedir de mais, vc tem uma lista dos cast e operators que teve que criar? claro que isso varia de aplicação pra aplicação, mas interessante a nível de comparações Agradeço sua colaboração Fabrízio. *-- Eurides V. Baptistella **E-mail:* eurides.baptiste...@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] Processo do PostgreSQL sendo derrubado
Nenhuma mensagem de kill é logado em /var/log/messages Na minha ignorância pergunto! Digamos que o Killer esta matando o processo, porque ele mataria apenas as conexões do postgresql e não mata o processo principal (postmaster) do PostgreSQL? Se ele estaria matando o postmaster eu teria que subir o postgresql novamente, mas não é isso que acontece, o processo principal continua ligado, aceitando as novas conexões. Porque essa sobrecarga apenas é constatada quando os dois SGBDs estão com uma carga de processamento alta? e porque as conexões do PostgreSQL são as escolhidas para o kill? Porque o kill não é disparado se eu executar apenas as consultas em PostgreSQL? em teoria a carga do processo do postgresql é a mesma com ou sem concorrência com o Firebird, o que aciona o killer é o processo e não o conjunto de processo, estou certo ? Quanto as configurações de memória do PostgreSQL acredito que não estão afetando pois consigo simular o problema com 1 conexão em Firebird e 1 em PostgreSQL (as configurações deveriam estar totalmente erradas para conseguir consumir 50GB de memória do servidor)! Não existem outros serviços a não ser os 2 SGBDs, e como falei, a memoria não é o problema neste caso. Digamos que eu não esteja observando direito os logs. Além do /var/log/***(messages) do SO, serverlog e postgresql-2012x.log do PostgreSQL, onde mais eu posso verificar se existe mensagens de erro sendo logadas? *-- Eurides V. Baptistella*** ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problemas com postmaster.pid
Pessoal, peço auxilio com um problema que tive. Hoje um servidor com banco Postgres parou e não subia mais, a mensagem que dava ao tentar iniciar era “pg_ctl: PID file /usr/local/pgsql/data/postmaster.pid does not exist Server running?”. Procurando em alguns logs do banco, identifiquei que em determinado momento o serviço foi parado, automaticamente o postmaster.pid foi excluído mas restou alguma coisa que manteve o serviço como registrado, a partir dai não eu não conseguia mais subir o banco. Após alguns testes, executei o comando pg_ctl -D directory status e encontrei o problema, então com pg_ctl -D directory start consegui com que o banco subisse novamente. Mas a pergunta é porque o banco baixou e não conseguiu mais subir? O que fez com que apenas parte dos arquivos que identificam que o banco esteja rodando (postmaster.pid) fossem excluídos (pois quando o banco é parado esses arquivos são excluídos automaticamente)? Alguém tem essas informações? O que acredito é que no momento de parar (/etc/init.d/postgres stop) o banco tinha conexões em transação ou algo do tipo, e em virtude disso não conseguiu parar completamente! O que acham ?? Att. *--* Eurides V. Baptistella ***E-mail:* eurides.baptiste...@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] Problemas com postmaster.pid
Então, não deveria mesmo existir, mas deve ter ficado outros arquivos “presos” fazendo com o Postgres ficasse em “meio termo”. A versão do Postgres que utilizamos é a 8.2.4 e neste caso o SO é OpenSuse 11.3(64) Existe uma rotina de backup que o cliente agendou para as 01h, ela da um stop no banco, aguarda alguns segundos e inicializa ele novamente. Iniciei a analise verificando os logs do backup e percebi que quando ele parou o banco não conseguiu mais subir, consequentemente gerando backups zerados... etc... etc. Então para confirmar que após as 01h o banco não operou mais eu conferi os logs (pg_clog e serverlog). Além disso verifiquei os processos abertos para postmaster, eles não existiam. O problema exatamente não identifiquei, apenas com a informação de erro do postmaster.pid e que o mesmo não conseguia subir, tentei a alternativa de start, foi o que resolveu meu problema (mas não sei o que ocasionou, só sei que funcionou), gostaria muito de saber o que ocasionou, o que aconteceu foi que o postmaster não estava instanciado, mas pode haver vários motivos para isso. O comando /etc/init.d/postgresql stop utiliza como parâmetro –s –m fast, neste caso não espera os clientes desconectarem e desfaz as transações abertas, com isso acredito que ele deveria ter contornado o fato de possivelmente existirem transações abertas. O que vocês acham? * Pessoal, peço auxilio com um problema que tive.* * * * Hoje um servidor com banco Postgres parou e não subia mais, a mensagem* * que dava ao tentar iniciar era “pg_ctl: PID file* * /usr/local/pgsql/data/postmaster.pid does not exist Server running?”.* Engraçado. Esse arquivo não deveria *mesmo* existir ao iniciar o PostgreSQL. Esse arquivo existe quando o PostgreSQL está rodando. Qual é a versão do PostgreSQL e qual seu S.O. e versão? * Procurando em alguns logs do banco, identifiquei que em determinado* * momento o serviço foi parado, automaticamente o postmaster.pid foi* * excluído mas restou alguma coisa que manteve o serviço como registrado,* * a partir dai não eu não conseguia mais subir o banco.* Tem certeza que não ficou nenhum dos processos? Como você verificou que o PostgreSQL parou mesmo? * Após alguns testes, executei o comando pg_ctl -D directory status e* * encontrei o problema, então com pg_ctl -D directory start consegui com* * que o banco subisse novamente.* E qual foi o problema que você encontrou? Você não contou. * Mas a pergunta é porque o banco baixou e não conseguiu mais subir? O que* * fez com que apenas parte dos arquivos que identificam que o banco esteja* * rodando (postmaster.pid) fossem excluídos (pois quando o banco é parado* * esses arquivos são excluídos automaticamente)? Alguém tem essas informações?* É necessário saber as versões como pedi acima. O postmaster.pid deve ser removido sim ao parar o banco. * O que acredito é que no momento de parar (/etc/init.d/postgres stop) o* * banco tinha conexões em transação ou algo do tipo, e em virtude disso* * não conseguiu parar completamente! O que acham ??* Veja os modos de parar o PostgreSQL em [1] (pra versão 9.1). Seu script em /etc/init.d/postgres está fazendo a coisa certa? Por exemplo, no modo immediate o PostgreSQL simplesmente... morre! E ficam coisas pra trás e a resolver na próxima inicialização. E sim, é possível que algum processo tenha ficado funcionando dependendo do tipo de parada que você fez (smart ou fast) e, por isso, a inicialização não funcionou, pra proteger seus dados enquando outro processo ainda está trabalhando. -- *Eurides V. Baptistella **E-mail:* eurides.baptiste...@gmail.com *Fone:* +55 (49) 9125-6572 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Fwd: OFF- Ferramenta controle de Schemas Banco de Dados
Galera, preciso de um help de vcs. A empresa que trabalho oferece atualmente ao cliente duas opções para banco de dados, Postgres e Firebird. Internamente trabalhamos desenvolvendo procedures/triggers etc (praticamente 80% das regras de negocio se concentram no Banco de Dados) em Firebird e uma ferramenta nossa converte essas procedures de Firebird para Postgres. Depois são versionados os .sql (Firebird) e .pgs (Postgres) no SNV. Quando enviamos atualizações aos clientes, é necessário enviar as alterações de banco, para isso uma base compilada (base zerada) é enviada juntamente com a atualização e uma outra ferramenta de atualização se encarrega de realizar o Merge da base zerada enviada com a base quente do cliente. Explicado como trabalhamos vou falar do que preciso: Estou procurando uma ferramenta que possibilite armazenar (de alguma forma, estive analisando algumas que utilizam XML, outras trabalham com ORM) a estrutura de um banco de dados, possibilite realizar diff de versões, e se possível que faça a mágica de converter as procedures de um banco para outro, pois logo estaremos fornecendo a possibilidade do cliente trabalhar com Oracle, logo seriam 3x o numero de arquivos relacionados a uma procedure somente por exemplo. Então gostaria de saber de vcs se conhecem empresas que fornecem produtos com suporte a mais de um banco de dados, e como essas empresas controlam a mudança no banco. Ps.: estive analisando uma ferramenta chamada liquibase, ela supre algumas necessidades mas a magica da conversão das procedures ela não faz, e isso é importante para mim. *-- Eurides V. Baptistella **E-mail:* eurides.baptiste...@gmail.com *Fone:* +55 (49) 9125-6572 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
