Fujii Masao wrote:
> On Fri, Sep 12, 2008 at 12:17 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> 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
