Re: Synchronous replication, reading WAL for sending

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Synchronous replication, reading WAL for sending
Дата
Msg-id 3f0b79eb0812240020r1b66ed2cjcaf0428fee6f59f3@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Synchronous replication, reading WAL for sending  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: about truncate
Следующее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: Synchronous replication, reading WAL for sending