Re: switching replication from standard asynch to slots

From: Vladimir Borodin <root(at)simply(dot)name>
To: Mike Broers <mbroers(at)gmail(dot)com>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: switching replication from standard asynch to slots
Date: 2016-12-12 06:41:36
Message-ID: EA68DEB3-2807-4180-9B6C-3C7DF19C56EF@simply.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hi.

> 9 дек. 2016 г., в 22:48, Mike Broers <mbroers(at)gmail(dot)com> написал(а):
>
> I have a few production environments that use vanilla streaming replication. (9.5 and 9.6)
>
> I'm curious if I can create the replication slot on the primary host, shutdown postgres on the secondary replica, update the recovery.conf to include the primary_slot_name, and restart postgres on the replica to effectively 'switch' over to use the slot for streaming without repriming with a fresh pg_basebackup.
>
> Also curious if I get into a pickle because of limits in pgsql_xlog disk space if I can just shut down the replica, remove the slot information, and do whatever cleanup is required on the primary and restart the replica with the slot information removed from the recovery.conf and go back to vanilla streaming replication without repriming.
>
> Anyone do this kind of slot/streaming switcheroo?

Yep, we have used both of described scenarios, they work. Note that in the second case you would probably need a valid restore_command in recovery.conf.

>
> Mike
>
>

--
May the force be with you…
https://simply.name

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Ram DBA 2016-12-12 23:35:56 Frequent errors in postgresql.log
Previous Message Michael Paquier 2016-12-12 02:23:03 Re: [GENERAL] Re: Would like to below scenario is possible for getting page/block corruption