Restoring a Full Cluster on a Different Architecture (32 x 64)
От | Rodrigo Hjort |
---|---|
Тема | Restoring a Full Cluster on a Different Architecture (32 x 64) |
Дата | |
Msg-id | 731083980603130956l369a4082s@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Restoring a Full Cluster on a Different Architecture (32 x 64)
("Jonah H. Harris" <jonah.harris@gmail.com>)
Re: Restoring a Full Cluster on a Different Architecture (32 x 64) (Martijn van Oosterhout <kleptog@svana.org>) Re: Restoring a Full Cluster on a Different Architecture (32 x 64) (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
Dear PostgreSQL Hackers,<br /><br />We got a PG 8.1 on a Debian 64 bits, which does a full backup (PITR) daily.<br />Thenwe installed a Debian 32 bits (actually, it's on VMWare) and wanted to restore the previous PG cluster on it. <br />Asthere are a lot of indexes, specially GiST, "pg_dump" and "pg_restore" are not viable - will take a lot of time!<br /><br/>Well, the fact is that we've got the message below on "postmaster" start attempt: <br /><br />"WARNING: CalculatedCRC checksum does not match value stored in file.<br /> Either the file is corrupt, or it has a different layoutthan this program<br /> is expecting. The results below are untrustworthy."<br /><br />As the architecture on bothLinuxes are different (32 and 64 bits), I think "PGDATA/global/pg_control" might contains 64 bit data such that the 32bits binary won't recognize or even mispell it. Am I right? <br /><br />What could be done in order to fix it? Is thereany kind of application to translate it or the only solution was to "pg_dumpall" and "pg_restore" the cluster?<br /><br/><br />********************************************************************************************** <br /><br />postgres@pga1:/tmp/lala/global$uname -a<br />Linux pga1 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux<br /><br/>postgres@pga1:/tmp/lala/global$ pg_controldata /var/lib/postgresql/8.1/main/<br />WARNING: Calculated CRC checksumdoes not match value stored in file. <br />Either the file is corrupt, or it has a different layout than this program<br/>is expecting. The results below are untrustworthy.<br /><br />pg_control version number: 812<br />Catalogversion number: 200510211 <br />Database system identifier: 4883914971069546458<br />Databasecluster state: in production<br />pg_control last modified: Wed 31 Dec 1969 09:00:00PM BRT<br />Current log file ID: 1142136269 <br />Next log file segment: 0<br />Latestcheckpoint location: 1/30<br />Prior checkpoint location: 1/2F71B630<br />Latest checkpoint'sREDO location: 1/2F71B5E0<br />Latest checkpoint's UNDO location: 1/2F71B630 <br />Latest checkpoint'sTimeLineID: 0<br />Latest checkpoint's NextXID: 0<br />Latest checkpoint's NextOID: 1<br/>Latest checkpoint's NextMultiXactId: 36239847<br />Latest checkpoint's NextMultiOffset: 1819439 <br />Time of latestcheckpoint: Wed 31 Dec 1969 09:00:11 PM BRT<br />Maximum data alignment: 25<br />Databaseblock size: 0<br />Blocks per segment of large relation: 8<br />Bytes per WAL segment: 0 <br />Maximum length of identifiers: 0<br />Maximum columns in an index: 1093850759<br/>Date/time type storage: 64-bit integers<br />Maximum length of locale name: 131072<br/>LC_COLLATE:<br />LC_CTYPE: <br /><br />**********************************************************************************************<br/><br />pgsql01:~# uname-a<br />Linux pgsql01 2.6.8-11-em64t-p4-smp #1 SMP Mon Oct 3 00:07:51 CEST 2005 x86_64 GNU/Linux <br /><br />pgsql01:~#/usr/lib/postgresql/8.1/bin/pg_controldata /pg/data/<br />pg_control version number: 812<br />Catalogversion number: 200510211<br />Database system identifier: 4883914971069546458 <br />Databasecluster state: in production<br />pg_control last modified: Mon Mar 13 14:19:42 2006<br/>Current log file ID: 1<br />Next log file segment: 51<br />Latest checkpoint location: 1/3289F8E0 <br />Prior checkpoint location: 1/32827710<br />Latest checkpoint's REDO location: 1/3289F8E0<br />Latest checkpoint's UNDO location: 0/0<br />Latest checkpoint's TimeLineID: 1<br />Latestcheckpoint's NextXID: 37253588 <br />Latest checkpoint's NextOID: 1819439<br />Latest checkpoint'sNextMultiXactId: 11<br />Latest checkpoint's NextMultiOffset: 25<br />Time of latest checkpoint: Mon Mar 13 14:19:42 2006<br />Maximum data alignment: 8 <br />Database block size: 8192<br />Blocks per segment of large relation: 131072<br />Bytes per WAL segment: 16777216<br/>Maximum length of identifiers: 64<br />Maximum columns in an index: 32 <br />Date/time typestorage: 64-bit integers<br />Maximum length of locale name: 128<br />LC_COLLATE: pt_BR<br />LC_CTYPE: pt_BR<br /><br />**********************************************************************************************<br /><br />Regards,<br /><br/>Rodrigo Hjort<br />GTI - Projeto PostgreSQL<br />CELEPAR - Cia de Informática do Paraná<br /><a href="http://www.pr.gov.br">http://www.pr.gov.br</a><br/><br />
В списке pgsql-hackers по дате отправления:
Следующее
От: "Jonah H. Harris"Дата:
Сообщение: Re: Restoring a Full Cluster on a Different Architecture (32 x 64)