Re: Remove Standby (SLAVE) from Primary (MASTER) - Postgres9.1

On 10/27/16 10:12 AM, Joanna Xu wrote:
> We need to keep the data as it is so remving data fold is not feasible.
> If I run "pg_ctl promote" on the slave to make it fail over, this will break the replication and then clean up the configuration related to replication. Any feedback?

Just to [hopefully] clear up some of the confusion..

Somewhere I saw you mention 9.1 . Since you're using 9.1, you won't
have any replication slots in use, if you were using replication slots,
then the master server could started to queue up WAL files waiting for
that node to come back. This could cause you to run out of disk space.
If you were using a replication slot, you would need to (after
promotion) connect to the master and drop it:
- SELECT * FROM pg_replication_slots;
- SELECT pg_drop_replication_slot(slot_name);

https://www.postgresql.org/docs/9.4/static/functions-admin.html#FUNCTIONS-REPLICATION
https://www.postgresql.org/docs/9.4/static/catalog-pg-replication-slots.html

Again, since you're on 9.1, this doesn't matter, BUT, it's important to
keep in mind for the future.

If you are using pure streaming replication, there is nothing that needs
'clean-up' on the master. Doing a promote will indeed do what you want
to accomplish (NB: See below if you are also archiving your WAL).

That being said, many setups of streaming will also include WAL
(pg_xlog) archiving (check the archive_mode and archive_command in your
postgresql.conf on the master). If you have configured archiving,
chances are, you will have some sort of cleanup job on the slave that
deals with old archived logs. You would either

A. Want to stop archiving (for the node you are promoting)
B. Ensure that cleanup is still taking place

These steps are not done for you when you promote a slave, it's
something that you need to deal with yourself.

There is one other thing to keep in mind. If you are promoting a
database, it's going to become read-write. I would make sure to either
erect a firewall around the promoted slave or edit your pg_hba.conf file
to reject traffic from your applications. If, for some reason your
application were to connect, you could end up with a split-brain
scenario which would mean that some of your data is in the old master
and some is in the newly promoted slave. This can be very, very
dangerous. As long as you exercise care, you will be fine, it's just an
important point that I've seen haunt people in the past.
> Thanks,
> Joanna
>
> -----Original Message-----
> From: Adrian Klaver [mailto:adrian(dot)klaver(at)aklaver(dot)com]
> Sent: Wednesday, October 26, 2016 7:50 PM
> To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>; Joanna Xu <Joanna(dot)Xu(at)amdocs(dot)com>
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Remove Standby (SLAVE) from Primary (MASTER) - Postgres9.1
>
> On 10/26/2016 04:43 PM, Michael Paquier wrote:
>> On Wed, Oct 26, 2016 at 11:18 PM, Joanna Xu <Joanna(dot)Xu(at)amdocs(dot)com> wrote:
>>> I’ve been looking for a procedure (step by step) on how to remove
>>> Standby
>>> (SLAVE) from Primary (MASTER) for Postgres9.1 in google and the
>>> archived postings, but no luck.
>> Standby and master servers are two separate Postgres instances. So if
>> you would like to remove a standby from a cluster. You just need to
>> basically stop it, then remove its data folder. And you are done.
>> There is no complicated science here.
> Not sure that is what OP wants. From the original post:
>
> " ...
> 2. After the standby is removed from the primary, both of nodes
> are in standalone configuration. "
>
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>
> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

--
Scott Mead
Sr. Architect
OpenSCG