Re: BUG #11603: replication, pg_basebackup and high load
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #11603: replication, pg_basebackup and high load |
Дата | |
Msg-id | 5436BF37.2010307@vmware.com обсуждение исходный текст |
Ответ на | Re: BUG #11603: replication, pg_basebackup and high load (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: BUG #11603: replication, pg_basebackup and high load
|
Список | pgsql-bugs |
On 10/09/2014 07:54 PM, Andres Freund wrote: > On 2014-10-08 13:19:27 +0000, mdglange@gmail.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
В списке pgsql-bugs по дате отправления: