Skip site navigation (1) Skip section navigation (2)

Re: replication using WAL archives

From: Gaetano Mendola <mendola(at)bigfoot(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>,pgsql-admin(at)postgresql(dot)org, iain(at)mst(dot)co(dot)jp
Subject: Re: replication using WAL archives
Date: 2004-10-22 16:44:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Hash: SHA1

Simon Riggs wrote:
|>Gaetano Mendola wrote
|>Postgres can help this process, as suggested by Tom creating a
| pg_current_wal()
|>or even better having two new GUC parameters: archive_current_wal_command
| and
| OK, we can modify the archiver to do this as well as the archive-when-full
| functionality. I'd already agreed to do something similar for 8.1
| By default, archive_max_delay would be 10 seconds.
| By default, archive_current_wal_command is not set.
| If archive_current_wal_command is not set, the archiver will archive a file
| using archive_command only when the file is full.
| If archive_current_wal_command is set, the archiver would archive a file
| whichever of these occurs first...
| - it is full
| - the archive_max_delay timeout occurs (default: disabled)
| you can see I've renamed archive_current_wal_delay to reflect the fact
| that there is an interaction between the current mechanism (only when full)
| and this additional mechanism (no longer than X secs between log files).
| With that design, if the logs are being created quickly enough, then a
| partial log file is never created, only full ones.
| When an xlog file is archived because it is full, then it is sent to both
| archive_current_wal_command and archive_command (in that order). When the
| timeout occurs and we have a partial xlog file, it would only be sent to
| archive_current_wal_command. It may also be desirable to not use
| archive_command at all, only to use archive_current_wal_command. That's not
| currently possible because archive_command is the switch by which all of the
| archive functioanlity is enabled, so you can't actually turn this off.

It seems good to me, the script behind archive command can be a nop if someone
want use the archive_current_wal_command

| = - = - =
| Gaetano - skim-reading your script, how do you handle the situation when a
| new xlog file has been written within 10 seconds? That way the current file
| number will have jumped by 2, so when your script looks for the "Last wal"
| using head -1 it will find the N+2 and the intermediate file will never be
| copied. Looks like a problem to me...

Yes, the only window failure I seen ( but I don't know if it's possible )

~        log N created
	log N filled
	archive log N
	log N+1 created
	log N+1 filled
~        log N+2 created
~                   <---- the master die here before to archive the log N+1
~        archive log N+1

in this case as you underline tha last log archived is the N and the N+2
partial wal is added to archived wal collection and in the recovery fase
the recovery stop after processing the log N.

Is it possible that the postmaster create the N+2 file without finish to archive
the N+1 ? ( I suspect yes :-(  )

The only cure I see here is to look for not archived WAL ( if possible ).

|>I problem I discover during the tests is that if you shut down the spare
|>node and the restore_command is still waiting for a file then the postmaster
|>will never exit  :-(
| Hmm....Are you reporting this as a bug for 8.0? It's not on the bug list...

For me is a behave to avoid.

Gaetano Mendola

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird -


In response to


pgsql-admin by date

Next:From: Simon RiggsDate: 2004-10-22 17:29:10
Subject: Re: replication using WAL archives
Previous:From: Doug YDate: 2004-10-22 15:04:04
Subject: RPM vs. Compile benefits?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group