From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, <mdglange(at)gmail(dot)com> |
Cc: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #11603: replication, pg_basebackup and high load |
Date: | 2014-10-09 17:00:39 |
Message-ID: | 5436BF37.2010307@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 10/09/2014 07:54 PM, Andres Freund wrote:
> On 2014-10-08 13:19:27 +0000, mdglange(at)gmail(dot)com wrote:
>> The test I did involved the following: a master database with two slaves. On
>> the master two replication slots have been configured as per the
>> documentation. One slave active before I put some "heavy" load (the
>> environment is scaled such, that inserting a few gigabytes of insert
>> statements is a heavy load. This is on purpose)
>
> Replication slots currently only reserve resources after they've been
> used the first time. I.e. when you create a physical replication slot it
> doesn't immediately reserve resources - a client needs to connect to it
> once, telling it from where on to reserve resources.
Oh, now I understand what Michiel was trying to do with the replication
slots. The idea is to prevent the master from recycling the segments
while the backup runs, by creating a replication slot before the backup.
> You can see the slot's reserved resources in the pg_replication_slots
> view.
>
> So, what you could do is to connect to the slots once, for a short time,
> using pg_receivexlog --slots. Or just use the -X stream method for
> pg_basebackup.
Hmm. Should we have an additional flag to "pg_basebackup -R" to create
and "reserve" a replication slot, too, all in one command? That would
be handy, although there's some potential of shooting your foot with
replication slots; if the backup is aborted for some reason, the slot
remains.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-10-09 17:10:49 | Re: BUG #11603: replication, pg_basebackup and high load |
Previous Message | Andres Freund | 2014-10-09 16:54:15 | Re: BUG #11603: replication, pg_basebackup and high load |