Re: question about replication slots
От | Michael Paquier |
---|---|
Тема | Re: question about replication slots |
Дата | |
Msg-id | CAB7nPqQNJ6gLKwBb42DTo2JWca7zYatSNf_Dw1WKoVWkyg+zOg@mail.gmail.com обсуждение исходный текст |
Ответ на | question about replication slots (Andreas Kretschmer <andreas@a-kretschmer.de>) |
Ответы |
Re: question about replication slots
|
Список | pgsql-general |
On Sat, Dec 5, 2015 at 2:35 AM, Andreas Kretschmer <andreas@a-kretschmer.de> wrote: > imagine a streaming replication using physical replication slots. And sometime a > fail over. All okay. I take a basebackup and rebuild the old master as slave. > > Is there a risk that the new slave contains active replication slots but no > listener on it? Yes. This would retain WAL on the standby indefinitely if you are not careful. > What have i to consider? You had better remove the contents of pg_replslot/ in the backup taken. Even if you include them, there are high chances that those will be useless at the end. So, quoting the docs (http://www.postgresql.org/docs/devel/static/continuous-archiving.html): It is often a good idea to also omit from the backup dump the files within the cluster's 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 files on the standby, and possibly bloat on the master if hot standby feedback is enabled, because the clients that are using those replication slots will still be connecting to and updating the slots on the master, not the standby. Even if the backup is only intended for use in creating a new master, copying the replication slots isn't expected to be particularly useful, since the contents of those slots will likely be badly out of date by the time the new master comes on line. -- Michael
В списке pgsql-general по дате отправления: