Why warm-standby doesn't work using file-based log shipping method?

From: sunpeng <bluevaley(at)gmail(dot)com>
To: PostgreSQL general <pgsql-general(at)postgresql(dot)org>
Subject: Why warm-standby doesn't work using file-based log shipping method?
Date: 2012-02-21 10:09:00
Message-ID: CAOYKhLp6fSN2v3mx1K6OwTtOH--jXzzTBv3hmsS_p2CoPw18Dw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I try to setup warm-standby using file-based log shipping method:
Master: 5432 port
Standby:6432 port at same machine
Master's :

- wal_level = archive
- archive_mode = on
- archive_command = 'cp %p /home/postgres/archive/%f'

Standby's restore_command = 'cp /home/postgres/archive/%f %p'

1. Firstly do a base backup for Standby ( successfuly )
[postgres(at)localhost ~]$ /home/postgres/db/standby/pgsql/bin/postmaster -D
/home/postgres/db/standby/pgsql/data --port=6432
LOG: database system was interrupted; last known up at 2012-02-21 17:24:33
CST
LOG: starting archive recovery
LOG: restored log file "000000010000000000000006" from archive
LOG: redo starts at 0/6000070
LOG: consistent recovery state reached at 0/7000000
cp: cannot stat `/home/postgres/archive/000000010000000000000007': No such
file or directory
LOG: could not open file "pg_xlog/000000010000000000000007" (log file 0,
segment 7): No such file or directory
LOG: redo done at 0/6000094
LOG: restored log file "000000010000000000000006" from archive
cp: cannot stat `/home/postgres/archive/00000002.history': No such file or
directory
LOG: selected new timeline ID: 2
cp: cannot stat `/home/postgres/archive/00000001.history': No such file or
directory
LOG: archive recovery complete
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
2. Then, let standby running as warm-standby mode with the following
parameters in recovery.conf to enable it continously track the Master
server:

- standby_mode = on
- restore_command = 'cp /home/postgres/archive/%f %p'

[postgres(at)localhost ~]$ /home/postgres/db/standby/pgsql/bin/postmaster -D
/home/postgres/db/standby/pgsql/data --port=6432
LOG: database system was shut down at 2012-02-21 17:29:38 CST
cp: cannot stat `/home/postgres/archive/00000003.history': No such file or
directory
cp: cannot stat `/home/postgres/archive/00000002.history': No such file or
directory
LOG: entering standby mode
cp: cannot stat `/home/postgres/archive/000000020000000000000007': No such
file or directory
WARNING: WAL was generated with wal_level=minimal, data may be missing
HINT: This happens if you temporarily set wal_level=minimal without taking
a new base backup.
LOG: consistent recovery state reached at 0/700013C
LOG: record with zero length at 0/700013C
cp: cannot stat `/home/postgres/archive/000000020000000000000007': No such
file or directory
cp: cannot stat `/home/postgres/archive/00000003.history': No such file or
directory
cp: cannot stat `/home/postgres/archive/000000020000000000000007': No such
file or directory
cp: cannot stat `/home/postgres/archive/000000020000000000000007': No such
file or directory
cp: cannot stat `/home/postgres/archive/00000003.history': No such file or
directory
cp: cannot stat `/home/postgres/archive/000000020000000000000007': No such
file or directory
cp: cannot stat `/home/postgres/archive/000000020000000000000007': No such
file or directory

3. Then let us do some DML queries on Master, for example, I insert new
tuples(large number, 1000000) to a table.
4. Theoreticaly new tuples could also be visible on Standby server some
time later, yet after I promote the Standby to check, it reveals nothing
has been down.

My question is:
1. Are there anything I have missed ?
2. I still can't understand why Standby(when running as standby mode)
always try to find `/home/postgres/archive/000000020000000000000007' file,
yet Master only copy the following files to archive directory:
[postgres(at)localhost archive]$ cd /home/postgres/archive
[postgres(at)localhost archive]$ ls
000000010000000000000004
000000010000000000000005
000000010000000000000006
000000010000000000000006.00000020.backup
000000010000000000000007
000000010000000000000008
000000010000000000000009
obviously there is no 000000020000000000000007.

Thanks!

Responses

Browse pgsql-general by date

  From Date Subject
Next Message George Tsinarakis 2012-02-21 10:46:57 Questionnaire on motivation analysis of open source and open content
Previous Message Vojtěch Rylko 2012-02-21 08:13:53 Re: How to split up phone numbers?