[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
