Re: Synchronous replication, reading WAL for sending - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Synchronous replication, reading WAL for sending
Date
Msg-id 3f0b79eb0812240020r1b66ed2cjcaf0428fee6f59f3@mail.gmail.com
Whole thread Raw
In response to Re: Synchronous replication, reading WAL for sending  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Responses Re: Synchronous replication, reading WAL for sending  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Re: Synchronous replication, reading WAL for sending  (Mark Mielke <mark@mark.mielke.cc>)
List pgsql-hackers
Hi,

On Wed, Dec 24, 2008 at 2:34 PM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> On Tue, Dec 23, 2008 at 9:12 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> As the patch stands, whenever XLOG segment is switched in XLogInsert, we
>> wait for the segment to be sent to the standby server. That's not good.
>> Particularly in asynchronous mode, you'd expect the standby to not have any
>> significant ill effect on the master. But in case of a flaky network
>> connection, or a busy or dead standby, it can take a long time for the
>> standby to respond, or the primary to give up. During that time, all WAL
>> insertions on the primary are blocked. (How long is the default TCP timeout
>> again?)
>>
>> Another point is that in the future, we really shouldn't require setting up
>> archiving and file-based log shipping using external scripts, when all you
>> want is replication. It should be enough to restore a base backup on the
>> standby, and point it to the IP address of the primary, and have it catch
>> up. This is very important, IMHO. It's quite a lot of work to set up
>> archiving and log-file shipping, for no obvious reason. It's really only
>> needed at the moment because we're building this feature from spare parts.
>>
>
> I had similar suggestions when I first wrote the high level design doc.
> From the wiki page:
>
> - WALSender reads from WAL buffers and/or WAL files and sends the
> buffers to WALReceiver. In phase one, we may assume that WALSender can
> only read from WAL buffers and WAL files in pg_xlog directory. Later
> on, this can be improved so that WALSender can temporarily restore
> archived files and read from that too.

You mean that only walsender performs xlog streaming and copying
from pg_xlog serially? I think that this would degrade the performance.
And, I'm worried about the situation that the speed to generate xlog
on the primary is higher than that to copy them to the standby. We
might not be able to start xlog streaming forever.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: about truncate
Next
From: "Pavan Deolasee"
Date:
Subject: Re: Synchronous replication, reading WAL for sending