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 по дате отправления:

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Re: [PERFORM] Hanging queries on dual CPU windows
Следующее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: Restoring a Full Cluster on a Different Architecture (32 x 64)