Timeline switch after rsync of *offline* pgdata?

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Timeline switch after rsync of *offline* pgdata?
Date: 2012-03-08 07:46:20
Message-ID: 20120308074620.GA2942@depesz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,
I have a script, that does, daily:
pg_ctl -D /data1 -s -m fast stop # data1 is working, rw database
pg_ctl -D /data2 -s -m fast stop # data2 is SR slave for another database
rsync -a --delete /data2/ /data1/
rm -rf /data1/pg_log/*

\print -u1 "$(date '+%Y-%m-%d %T %Z'): Pg_controldata for /data2:"
/usr/pgsql-9.0/bin/pg_controldata "/data2"

\print -u1 "$(date '+%Y-%m-%d %T %Z'): Pg_controldata for /data1:"
/usr/pgsql-9.0/bin/pg_controldata "/data1"

as you can see, it is full rsync of offline pgs.

But the pg_controldata outputs are puzzling:

2012-03-08 06:18:58 GMT: Pg_controldata for /data2:
pg_control version number: 903
Catalog version number: 201008051
Database system identifier: 5554952960675921391
Database cluster state: shut down in recovery
pg_control last modified: Thu Mar 8 05:35:02 2012
Latest checkpoint location: CEA/29C835C0
Prior checkpoint location: CE9/FBE2C010
Latest checkpoint's REDO location: CEA/1F0028D0
Latest checkpoint's TimeLineID: 2
Latest checkpoint's NextXID: 0/759254939
Latest checkpoint's NextOID: 1817085
Latest checkpoint's NextMultiXactId: 10319293
Latest checkpoint's NextMultiOffset: 29852536
Latest checkpoint's oldestXID: 654
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 759252601
Time of latest checkpoint: Thu Mar 8 05:31:09 2012
Minimum recovery ending location: CEA/30032028
Backup start location: 0/0
Current wal_level setting: hot_standby
Current max_connections setting: 1024
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

2012-03-08 06:18:58 GMT: /data1:
pg_control version number: 903
Catalog version number: 201008051
Database system identifier: 5554952960675921391
Database cluster state: shut down
pg_control last modified: Thu Mar 8 05:35:02 2012
Latest checkpoint location: CEA/A0000020
Prior checkpoint location: CEA/9F000020
Latest checkpoint's REDO location: CEA/A0000020
Latest checkpoint's TimeLineID: 3
Latest checkpoint's NextXID: 0/757048930
Latest checkpoint's NextOID: 1819890
Latest checkpoint's NextMultiXactId: 10282145
Latest checkpoint's NextMultiOffset: 29736818
Latest checkpoint's oldestXID: 654
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Time of latest checkpoint: Thu Mar 8 05:35:02 2012
Minimum recovery ending location: 0/0
Backup start location: 0/0
Current wal_level setting: minimal
Current max_connections setting: 1024
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

The important thing is that pg in data1 incremented timeline.

Pg is 9.0.6, on CentOS 5.5.

Stop of pg's is happening via a init.d script, which does the lines
shown above, and the initscript ends with "OK"

Best regards,

depesz

--
The best thing about modern society is how easy it is to avoid contact with it.
http://depesz.com/

Browse pgsql-general by date

  From Date Subject
Next Message Stuart Bishop 2012-03-08 07:54:12 Re: A 154 GB table swelled to 527 GB on the Slony slave. How to compact it?
Previous Message François Beausoleil 2012-03-08 05:36:37 replay_location meaning in pg_stat_replication