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.klaver@xxxxxxxxxxx] > Sent: Wednesday, October 26, 2016 7:50 PM > To: Michael Paquier <michael.paquier@xxxxxxxxx>; Joanna Xu <Joanna.Xu@xxxxxxxxxx> > Cc: pgsql-general@xxxxxxxxxxxxxx > Subject: Re: 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.Xu@xxxxxxxxxx> 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.klaver@xxxxxxxxxxx > > 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
