Обсуждение: Streaming replication

Поиск
Список
Период
Сортировка

Streaming replication

От
Tatsuo Ishii
Дата:
In the doc:

25.2.5. Streaming Replication
:
The standby connects to the primary, which streams WAL records to the
standby as they're generated, without waiting for the WAL file to be
filled.

This seems to claim that walsender sends WAL files which has not been
fsync'd yet. However, in walsender.c:
    /*     * Streaming the current timeline on a master.     *     * Attempt to send all data that's already been
writtenout and     * fsync'd to disk.  We cannot go further than what's been written out     * given the current
implementationof XLogRead().  And in any case     * it's unsafe to send WAL that is not securely down to disk on the
* master: if the master subsequently crashes and restarts, slaves     * must not have applied any WAL that gets lost on
themaster.     */
 
This one says walsender sends WAL records as long as there are
fsync'd.

Am I missing something?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



Re: Streaming replication

От
Mark Kirkwood
Дата:
On 31/03/15 12:45, Tatsuo Ishii wrote:
> In the doc:
> 
> 25.2.5. Streaming Replication
> :
> The standby connects to the primary, which streams WAL records to the
> standby as they're generated, without waiting for the WAL file to be
> filled.
> 
> This seems to claim that walsender sends WAL files which has not been
> fsync'd yet. However, in walsender.c:
> 
>         /*
>          * Streaming the current timeline on a master.
>          *
>          * Attempt to send all data that's already been written out and
>          * fsync'd to disk.  We cannot go further than what's been written out
>          * given the current implementation of XLogRead().  And in any case
>          * it's unsafe to send WAL that is not securely down to disk on the
>          * master: if the master subsequently crashes and restarts, slaves
>          * must not have applied any WAL that gets lost on the master.
>          */
>     
> This one says walsender sends WAL records as long as there are
> fsync'd.
> 
> Am I missing something?
> 
>

I think the docs are trying to say that streaming replication doesn't
wait for a (16MB) WAL *file* to be filled. but sends each (fsync'd) WAL
record. I had to reread it several times too :-)

Cheers

Mark




Re: Streaming replication

От
Tatsuo Ishii
Дата:
> On 31/03/15 12:45, Tatsuo Ishii wrote:
>> In the doc:
>> 
>> 25.2.5. Streaming Replication
>> :
>> The standby connects to the primary, which streams WAL records to the
>> standby as they're generated, without waiting for the WAL file to be
>> filled.
>> 
>> This seems to claim that walsender sends WAL files which has not been
>> fsync'd yet. However, in walsender.c:
>> 
>>         /*
>>          * Streaming the current timeline on a master.
>>          *
>>          * Attempt to send all data that's already been written out and
>>          * fsync'd to disk.  We cannot go further than what's been written out
>>          * given the current implementation of XLogRead().  And in any case
>>          * it's unsafe to send WAL that is not securely down to disk on the
>>          * master: if the master subsequently crashes and restarts, slaves
>>          * must not have applied any WAL that gets lost on the master.
>>          */
>>     
>> This one says walsender sends WAL records as long as there are
>> fsync'd.
>> 
>> Am I missing something?
>> 
>>
> 
> I think the docs are trying to say that streaming replication doesn't
> wait for a (16MB) WAL *file* to be filled. but sends each (fsync'd) WAL
> record. I had to reread it several times too :-)

Thanks for the explanation. That makes sense. The docs definitely has
a room for improvement.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



Re: Streaming replication

От
Greg Stark
Дата:
<p dir="ltr">The key word you're misunderstanding is "filled". It means it doesn't wait for the 16MB file to be
completelyfilled with records. I.e. what would happen in the file shipping form of replication.