On Fri, Jul 27, 2012 at 9:57 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Jul 27, 2012 at 9:53 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> You might want to look at the hackers list thread I started about the
>> same topic a week before your post:
>>
>> http://archives.postgresql.org/pgsql-hackers/2012-07/msg00416.php
>>
>> Basically, you can only use mtime/size if you are replaying WAL.
>
> I'll check that out in a bit; but hot standby includes replaying WAL,
> right? That's what we're doing - full live replication with
> possibility to "pg_ctl promote" a slave straight up to master.
Hi, thanks for that link. Just got a chance to read through the thread.
In this post[1] the script executes "checkpoint" before
"pg_start_backup" - is that important? According to the docs[2]:
"There is an optional second parameter of type boolean. If true, it
specifies executing pg_start_backup as quickly as possible. This
forces an immediate checkpoint which will cause a spike in I/O
operations, slowing any concurrently executing queries."
Is "checkpoint; select pg_start_backup('foo');" the same as "select
pg_start_backup('foo',true);"? And what are the consequences of not
calling for a checkpoint that way? My understanding of the docs is
that the pg_start_backup call will hang until a checkpoint happens
organically, ie delaying the backup rather than other clients, but I'm
not really sure and haven't a sample database big or busy enough to
test this on.
Other than that, I think our current setup is fine. I have a script
that, every time a computer attempts to join the cluster, redoes the
"start backup, rsync, stop backup" sequence. I'm depending on (and
assuming) the correct transfer of the last bit of log via the
replication link, as soon as the new slave starts up - presumably
this'll all be provided from wal_keep_segments.
Again, thanks for the pointer! A good read.
ChrisA
[1] http://archives.postgresql.org/pgsql-hackers/2012-07/msg00417.php
[2] http://www.postgresql.org/docs/9.1/static/functions-admin.html
