Re: replication slots replicated to standbys?
От | Michael Paquier |
---|---|
Тема | Re: replication slots replicated to standbys? |
Дата | |
Msg-id | CAB7nPqQw_HbkLnt__OGXP2nu=G_8=H=myA3Y5NpV5B5qtnGY7g@mail.gmail.com обсуждение исходный текст |
Ответ на | replication slots replicated to standbys? (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: replication slots replicated to standbys?
|
Список | pgsql-hackers |
On Sat, Aug 20, 2016 at 1:39 PM, Bruce Momjian <bruce@momjian.us> wrote: > Someone reported that a replication slot that existed at the time a base > backup was done on the master was copied to the standby. Because they > didn't realize it, their WAL was not being recycled on the standby. > > Is that possible? Is it a known behavior? I don't see it documented. From backup.sgml: <para> It is often a good idea to also omit from the backup the files within the cluster's <filename>pg_replslot/</>directory, so that replication slots that exist on the master do not become part of the backup. Otherwise, the subsequent use of the backup to create a standby may result in indefinite retention of WAL fileson the standby, and possibly bloat on the master if hot standby feedback is enabled, because the clients that areusing those replication slots will still be connecting to and updating the slots on the master, not the standby. Evenif the backup is only intended for use in creating a new master, copying the replication slots isn't expected tobe particularly useful, since the contents of those slots will likely be badly out of date by the time the new mastercomes on line. </para> Note as well that pg_basebackup omits its content and creates an empty directory. -- Michael
В списке pgsql-hackers по дате отправления: