On Fri, Sep 12, 2008 at 12:17 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Fujii Masao wrote:
>>
>> I think that this case would often happen. So, we should establish a
>> certain
>> solution or procedure to the case where TLI of the master doesn't match
>> TLI of the slave. If we only allow the case where TLI of both servers is
>> the
>> same, the configuration after failover always needs to get the base backup
>> on the new master. It's unacceptable for many users. But, I think that
>> it's
>> the role of admin or external tools to copy history files to the slave
>> from
>> the master.
>
> 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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center