Re: Backup throttling
Hannu Krosing <hannu@2ndquadrant.com>
From: Hannu Krosing <hannu@2ndQuadrant.com>
To: Antonin Houska <antonin.houska@gmail.com>
Cc: Craig Ringer <craig@2ndquadrant.com>, PostgreSQL - Hans-Jürgen Schönig <postgres@cybertec.at>, Andres Freund <andres@2ndquadrant.com>, Boszormenyi Zoltan <zb@cybertec.at>, pgsql-hackers@postgresql.org
Date: 2013-08-26T12:15:49Z
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Ü