On 27/08/2009 18:11, Martin Pihlak wrote:
There are actually no "real" data changes being made on your master
for some reason. So every time archive_timeout is reached a log full
of no changes is shipped to your slave and applied - and no checkpoint
times are changed for reasons I mentioned above.
thanks, but we have not set archive_timeout, and we have a lot of real
data changes.
That's why i don't understand why checkpoint never happen on the slave.
What about the other values in pg_controldata output, do they change at
all? If they remain constant, maybe the logs are just not applied. Also,
are there any "restored log file xxx from archive" entries in postgres
log?
No, i don't see any change in pg_controldata, but :
there is messages in logfile :
2009-08-28 10:02:51,129 26717 INFO 00000001000003F700000088: Found
2009-08-28 10:02:51,169 26717 INFO {count: 1}
2009-08-28 10:02:51 CEST [18439]: [1862-1] user=,db= LOG: restored log
file "00000001000003F700000088" from archive
postgres@bdd2:/data/postgresql/8.3/main$ grep "restored log file"
/var/log/postgresql/postgresql-2009-08-28.log | wc -l
164
And I can see that the cluster is updated inside the directory px_xlog
and base, at least.
So we can think it's working, but, when i restart the slave cluster, it
process again all the WAL since the last checkpoint ( for nothing, I
think ), so, when we'll need this slave, it will take a lot of time,
more and more, and this point worried me a bit.
--
Sébastien Lardière
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
