On Tue, Feb 19, 2019 at 1:37 PM Stephen Frost <sfrost@snowman.net> wrote:
Greetings,
* Martín Fernández (fmartin91@gmail.com) wrote: > Thanks for information! I've refactor our migration scripts to follow the suggestions.
Please don't top-post on these mailing lists.
> One extra question that popped up. As long as we don't start the standby (after running rsync), we can always `rm -f $PGDATA_10` and promote the standby if necessary for failover right ? We also need to `mv` pg_control.old to pg_control in the old data directory.
Not sure which standby we're talking about here, but in general, yes, as long as you haven't actually started the system after the pg_upgrade/rsync, you should be able to blow away the new cluster that pg_upgrade/rsync created and start the old cluster back up and promote it (if necessary) and use it.
Note that you should *not* need to do anything with pg_control, I have no idea what you're referring to there, but the old cluster should have the pg_control file and all the catalog tables in place from before the pg_upgrade/rsync (those aren't touched during the pg_upgrade/rsync process) and you would just need to start up the old binaries pointing at the old PG data directory and everything should just work.
I did some successful tests yesterday around this scenario. That standby in this context is that one that received the rsync from the master but was never started. The old data directory stays intact except for the fact that globa/pg_control was renmaed with a .old
I have found the documentation on pg_ugprade that states this:
` If you ran pg_upgrade without --link or did not start the new server, the old cluster was not modified except that, if linking started, a .old suffix was appended to
$PGDATA/global/pg_control. To reuse the old cluster, possibly remove the .old suffix from $PGDATA/global/pg_control; you can then restart the old cluster.`
