Warm Standby Weirdness
| От | Sam Nelson |
|---|---|
| Тема | Warm Standby Weirdness |
| Дата | |
| Msg-id | AANLkTikJHsZfOKYrJxSyC4i2OGtXFm320nJtEXbc1Ufk@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: Warm Standby Weirdness
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| Список | pgsql-general |
Let me preface this by saying that I've set up warm standby instances quite a few times. I think I sort of hopefully know what I'm doing. pg_start_backup('stuff'), tar data directory, pg_stop_backup(), copy data directory to warm standby server, extract in data directory, etc.
We have two CentOS 5 boxes that we're trying to set up as a master -> warm standby. Both have postgres 8.4.4 installed from source. The master's postgres instance has been there for a while (a couple of months or something).
I am very, very sorry if I'm missing something really simple, but I just can't seem to figure out what I'm doing wrong. Here's the process I'm following:
==master==
$ psql
postgres=# select pg_start_backup('<today's date>')
postgres=# \q
$ cd /path/to/data/directory
$ tar cvzf data.tar.gz *
$ scp data.tar.gz <server>:~/
==warm standby==
$ cd /path/to/data/directory
$ tar xvf ~/data.tar.gz
<create recovery.conf file with restore_command line and modify postgresql.conf to disable wal archiving>
$ pg_ctl -D /path/to/data/directory start
Here's the output after trying to start the backup instance with pg_ctl (ignoring the line about postmaster.pid already existing):
server starting
FATAL: incorrect checksum in control file
Here's the output from pg_controldata:
$ pg_controldata `pwd`
WARNING: Calculated CRC checksum does not match value stored in file.
Either the file is corrupt, or it has a different layout than this program
is expecting. The results below are untrustworthy.
pg_control version number: 843
Catalog version number: 200904091
Database system identifier: 5473004134245625319
Database cluster state: in production
pg_control last modified: Wed 31 Dec 1969 05:00:00 PM MST
Latest checkpoint location: B000020/0
Prior checkpoint location: A000020/0
Latest checkpoint's REDO location: B000020/1
Latest checkpoint's TimeLineID: 0
Latest checkpoint's NextXID: 57905/32791
Latest checkpoint's NextOID: 1
Latest checkpoint's NextMultiXactId: 0
Latest checkpoint's NextMultiOffset: 1282256808
Time of latest checkpoint: Wed 31 Dec 1969 05:00:00 PM MST
Minimum recovery ending location: 0/4
Maximum data alignment: 0
Database block size: 8192
Blocks per segment of large relation: 16777216
WAL block size: 64
Bytes per WAL segment: 32
Maximum length of identifiers: 2000
Maximum columns in an index: 257
Maximum size of a TOAST chunk: 513657607
Date/time type storage: floating-point numbers
Float4 argument passing: by reference
Float8 argument passing: by reference
Those timestamps are at the unix epoch - Jan 1 1970 ... what in the spinning marble?!
Yeah. I'm confused, my boss is confused... We're currently running a yum -y update on those boxes, but we'd still like to know what's going on, even if a full update fixes everything. Any clues?
В списке pgsql-general по дате отправления: