On Wed, Oct 13, 2010 at 3:43 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 13.10.2010 08:21, Fujii Masao wrote:
>>
>> On Sat, Oct 9, 2010 at 4:31 AM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>
>>> It shouldn't be too hard to fix. Walsender needs to be able to read WAL
>>> from
>>> preceding timelines, like recovery does, and walreceiver needs to write
>>> the
>>> incoming WAL to the right file.
>>
>> And walsender seems to need to transfer the current timeline history to
>> the standby. Otherwise, the standby cannot recover the WAL file with new
>> timeline. And the standby might need to create the timeline history file
>> in order to recover the WAL file with new timeline even after it's
>> restarted.
>
> Yes, true, you need that too.
>
> It might be good to divide this work into two phases, teaching archive
> recovery to notice new timelines appearing in the archive first, and doing
> the walsender/walreceiver changes after that.
OK. In detail,
1. After failover, when the standby connects to new master, walsender transfers the current timeline history in the
handshakeprocessing.
2. If the timeline history in the master is inconsistent with that in
the standby, walreceiver terminates the replication connection.
3. Walreceiver creates the timeline history file.
4. Walreceiver signals the change of timeline history to startup process and makes it read the timeline history file.
Afterthis, startup process tries to recover the WAL files with even new timeline ID.
5. After the handshake, walsender sends the WAL from preceding timelines, like recovery does, and walreceiver writes
theincoming WAL to the right file.
Am I missing something?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
