Re: Backup throttling

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Antonin Houska <antonin(dot)houska(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, Andres Freund <andres(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Backup throttling
Date: 2013-08-26 12:15:49
Message-ID: 521B46F5.5050606@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/26/2013 12:50 PM, Antonin Houska wrote:
> On 08/22/2013 03:33 PM, Craig Ringer wrote:
>> On 08/22/2013 01:39 PM, PostgreSQL - Hans-Jürgen Schönig wrote:
>>
>>> what would be a reasonable scenario where limiting streaming would make sense? i cannot think of any to be honest.
>> I tend to agree. If anything we're likely to want the reverse - the
>> ability to throttle WAL *generation* on the master so streaming can keep up.
> (I assume you mean WAL *sending* rather than *generation*.)
I think he meant *generation*, that is making sure that no more
than X amount of WAL is generated in Y amount of time, thereby
making sure that you can stream less WAL without falling behind.
> I don't think we want to throttle WAL sending/receiving at all. The WAL
> senders should always keep up with the amount of WAL generated. If the
> rate of WAL sending is restricted, then the pg_basebackup (or another
> client application) might never catch up.
Yes, and this is exactly why restricting *generation* is needed.
> Also, IMO, pg_basebackup starts at the current WAL segment. Thus the
> unthrottled WAL transfer shouldn't cause significant additional load,
> such as reading many old WAL segments from the master's disk.
The possible extra load happens if the *network* not because of disk.
Think of replication over - possibly slow - WAN.

Cheers

--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tarvi Pillessaar 2013-08-26 12:18:34 Re: Detail part for still waiting for lock log message
Previous Message Antonin Houska 2013-08-26 10:50:48 Re: Backup throttling