Fujii Masao wrote:
On Fri, Sep 12, 2008 at 12:17 AM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
Hmm. There's more problems than the TLI with that. For the original master
to catch up by replaying WAL from the new slave, without restoring from a
full backup, the original master must not write to disk *any* WAL that
hasn't made it to the slave yet. That is certainly not true for asynchronous
replication, but it also throws off the idea of flushing the WAL
concurrently to the local disk and to the slave in synchronous mode.
Yes.
If the master fails after writing WAL to disk and before sending it to
the slave,
at least latest WAL file would be inconsistent between both servers. So,
regardless of using a base backup, in a setup procedure, we need to delete
those inconsistent WAL files or overwrite them.
And if you're unlucky, the changes in the latest WAL file might already
have been flushed to data files as well.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
