[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:
Re: [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! Porque o arquivo está incompleto. 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. Seu servidor slave cortou o dump. Isso acontece quando a configuração hot_standby_feedback está desligada e o servidor master está com muitas modificações, após uma passagem de vacuum as tuplas necessárias ao slave são limpas no master e replicadas, o slave cancela as consultas, inclusive o COPY do dump. Ligar hot_standby_feedback deve resolver seu problema, ou faça sempre os dumps no master que não sofre disso. Obviamente os servidores MASTER e SLAVE são idênticos, o servidor de homologação é bem inferior aos outros (tanto em memória como processamento). Isso não é um problema no seu caso. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao restaurar backup (pg_dump) realizado em um servidor replicado
2014-07-24 11:20 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Seu servidor slave cortou o dump. Isso acontece quando a configuração hot_standby_feedback está desligada e o servidor master está com muitas modificações, após uma passagem de vacuum as tuplas necessárias ao slave são limpas no master e replicadas, o slave cancela as consultas, inclusive o COPY do dump. Ligar hot_standby_feedback deve resolver seu problema, ou faça sempre os dumps no master que não sofre disso. Algo que muita gente não faz é verificar o código de retorno do pg_dump ao executar um backup. Se o que o Gurgel comentou ocorreu (também creio que seja isso), o pg_dump apresentou um erro que provavelmente o OP ignorou. DICA: Gerem logs de seus scripts, verifiquem por códigos de retorno e se for redirecionar as saídas para um arquivo, lembre-se que há a saída padrão (stdout) e saída de erro (stderr). Por exemplo (no Linux ao menos) para redirecionar a saída do dump você pode fazer: $ pg_dump ... 2 erros.log Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao restaurar backup (pg_dump) realizado em um servidor replicado
On 24-07-2014 12:20, Matheus de Oliveira wrote: 2014-07-24 11:20 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Seu servidor slave cortou o dump. Isso acontece quando a configuração hot_standby_feedback está desligada e o servidor master está com muitas modificações, após uma passagem de vacuum as tuplas necessárias ao slave são limpas no master e replicadas, o slave cancela as consultas, inclusive o COPY do dump. Ligar hot_standby_feedback deve resolver seu problema, ou faça sempre os dumps no master que não sofre disso. Algo que muita gente não faz é verificar o código de retorno do pg_dump ao executar um backup. Se o que o Gurgel comentou ocorreu (também creio que seja isso), o pg_dump apresentou um erro que provavelmente o OP ignorou. DICA: Gerem logs de seus scripts, verifiquem por códigos de retorno e se for redirecionar as saídas para um arquivo, lembre-se que há a saída padrão (stdout) e saída de erro (stderr). Por exemplo (no Linux ao menos) para redirecionar a saída do dump você pode fazer: $ pg_dump ... 2 erros.log +1 E só pra ficar registrado algumas referencias: http://tldp.org/LDP/abs/html/exit-status.html http://www.linuxcommand.org/wss0150.php http://www.cyberciti.biz/faq/shell-how-to-determine-the-exit-status-of-linux-and-unix-command/ Att, -- Fabrízio de Royes Mello 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
Re: [pgbr-geral] Erro ao restaurar backup (pg_dump) realizado em um servidor replicado
On 24-07-2014 12:47, Fabrízio de Royes Mello wrote: On 24-07-2014 12:20, Matheus de Oliveira wrote: 2014-07-24 11:20 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Seu servidor slave cortou o dump. Isso acontece quando a configuração hot_standby_feedback está desligada e o servidor master está com muitas modificações, após uma passagem de vacuum as tuplas necessárias ao slave são limpas no master e replicadas, o slave cancela as consultas, inclusive o COPY do dump. Ligar hot_standby_feedback deve resolver seu problema, ou faça sempre os dumps no master que não sofre disso. Algo que muita gente não faz é verificar o código de retorno do pg_dump ao executar um backup. Se o que o Gurgel comentou ocorreu (também creio que seja isso), o pg_dump apresentou um erro que provavelmente o OP ignorou. DICA: Gerem logs de seus scripts, verifiquem por códigos de retorno e se for redirecionar as saídas para um arquivo, lembre-se que há a saída padrão (stdout) e saída de erro (stderr). Por exemplo (no Linux ao menos) para redirecionar a saída do dump você pode fazer: $ pg_dump ... 2 erros.log +1 E só pra ficar registrado algumas referencias: http://tldp.org/LDP/abs/html/exit-status.html http://www.linuxcommand.org/wss0150.php http://www.cyberciti.biz/faq/shell-how-to-determine-the-exit-status-of-linux-and-unix-command/ Desculpem, mas não poderia deixar de passar também uma referencia tupiniquim: http://aurelio.net/shell/canivete/ Att, -- Fabrízio de Royes Mello 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] Funções para inclusão e alteração
Estou fazendo funções armazenadas para inclusão, alteração, exclusão de dados nas tabelas. Qual seria a melhor prática? Criar essas funções ou deixar a cargo da aplicação lidar com as queries? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Case com Zebedee
Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel entre o server e o client e toda informação que trafega neste tunel é compactada, deixando assim a comunicação entre cliente/servidor mais rápida. A versão atual é de 2005 mesmo, mas está muito estável. Creio que por isso não tenha atualizações recentes. Obs.: Zebedee não funciona apenas com PostgreSQL. Ele funciona com qualquer aplicativo que utilize portas TCP para se comunicar. Att., Renato Ricci Em 23 de julho de 2014 16:02, Alessandro Lima grandegoia...@gmail.com escreveu: Jean, estive dando uma olhada no Zebedee, parece que a última atualização dele foi em 2005, é isto mesmo? Atenciosamente, Alessandro Lima email grandegoia...@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] Case com Zebedee
Em 24-07-2014 19:02, Renato Ricci escreveu: Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel entre o server e o client e toda informação que trafega neste tunel é compactada, deixando assim a comunicação entre cliente/servidor mais rápida. Uma pergunta de leigo: qual a diferença, em termos de performance, entre uma ferramenta deste segmento e um túnel VPN sobre UDP compactado, como por exemplo, o OpenVPN? Att, -- +--+ | Daniel Cordeiro de Morais Neto | Diretor de TI - Portal de Cotações e-Compras | Sócio-diretor ADM Soluções em Informática LTDA | daniel.cordeiro(at)cotacoesecompras.com.br | dmoraisn(at)gmail.com | www.cotacoesecompras.com.br | Fone: (083)8724-4440 | Gentoo User | http://twitter.com/dmoraisn +--+ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Case com Zebedee
On 24-07-2014 20:25, Daniel Cordeiro wrote: Em 24-07-2014 19:02, Renato Ricci escreveu: Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel entre o server e o client e toda informação que trafega neste tunel é compactada, deixando assim a comunicação entre cliente/servidor mais rápida. Uma pergunta de leigo: qual a diferença, em termos de performance, entre uma ferramenta deste segmento e um túnel VPN sobre UDP compactado, como por exemplo, o OpenVPN? Eu estava escrevendo um email com a mesma dúvida. Att, -- Fabrízio de Royes Mello 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
Re: [pgbr-geral] Funções para inclusão e alteração
Em 24 de julho de 2014 17:47, Matheus Saraiva matheus.sara...@gmail.com escreveu: Estou fazendo funções armazenadas para inclusão, alteração, exclusão de dados nas tabelas. Qual seria a melhor prática? Criar essas funções ou deixar a cargo da aplicação lidar com as queries? Há alguns anos, isso seria motivo para muita discussão, não sei se hoje continua assim, mas eu prefiro deixar as regras de negócios no banco de dados, porque assim, a regra será a mesma, independentemente de onde venha o comando (aplicação ou pelo pgadmin). Essa forma também ajuda na questão de não se preocupar com a linguagem de programação, pois a regra a mesma. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Case com Zebedee
2014-07-23 15:11 GMT-03:00 Jean - GeControl j...@gecontrolsistemas.com.br: Pessoal, apenas compartilhando com a lista: estou acessando o banco de dados Postgresql através da internet, através de um link dedicado de 2Mbps do lado host e client. Pra melhorar o desempenho, coloquei o Zebedee pra fazer o tunneling, com compactação de pacotes. Percebi que a melhor no Fetch das consultas ficou na casa dos 65%, em média. Visivelmente, no manuseio do sistema ERP, o ganho foi considerável. Espero que o case sirva pra outros usuários. *Jean Domingues* *Sócio-Proprietário* *Gecontrol Consultoria e Sistemas.* o postgres com ssl também faz compactação. o stunnel também faz o mesmo serviço do zbd. Itamar Reis Peixoto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] banco e aplicação no mesmo servidor
Tenho vários clientes que possuem o postgres e a aplicação java web no mesmo servidor, acredito que tenho melhor desempenho por não gerar tráfego na rede e por aproveitar ociosidade da cpu. Mas gostaria da experiência de vocês se esta é uma boa prática, ou o banco em um servidor independente teria melhor desempenho. Atenciosamente, Alessandro Lima email grandegoia...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] banco e aplicação no mesmo servidor
Em 24 de julho de 2014 23:31, Alessandro Lima grandegoia...@gmail.com escreveu: Tenho vários clientes que possuem o postgres e a aplicação java web no mesmo servidor, acredito que tenho melhor desempenho por não gerar tráfego na rede e por aproveitar ociosidade da cpu. Mas gostaria da experiência de vocês se esta é uma boa prática, ou o banco em um servidor independente teria melhor desempenho. Uma coisa é você ter uma carreta (teu servidor) para carregar um saco de cimento (tua aplicação + postgres), outra coisa é você ter um carrinho de mão (novamente teu servidor) para carregar 50 sacos de cimento (novamente tua aplicação + postgres). Resumindo, cada caso é um caso, tudo depende. Depende de verba, etc... Já vi casos de sucesso, onde aplicação (php) e postgres estavam no mesmo servidor, e também já vi casos de insucesso, onde a solução foi separar ambos. Você tem que avaliar também o quanto sua aplicação e o postgres irão consumir de recursos do servidor, se o consumo for baixo, não vejo problemas em ter ambos no mesmo servidor. Avalie também estratégias de backups e replicação. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
