Re: Using pg_upgrade on log-shipping standby servers
От | Bruce Momjian |
---|---|
Тема | Re: Using pg_upgrade on log-shipping standby servers |
Дата | |
Msg-id | 20120720171111.GA7060@momjian.us обсуждение исходный текст |
Ответ на | Re: Using pg_upgrade on log-shipping standby servers (Aidan Van Dyk <aidan@highrise.ca>) |
Ответы |
Re: Using pg_upgrade on log-shipping standby servers
|
Список | pgsql-hackers |
On Fri, Jul 20, 2012 at 12:39:12PM -0400, Aidan Van Dyk wrote: > If you're wanting to automatically do some upgrades wouldn't an easier route be: > > 1) run pg_upgrade, up to the point where it actually start's > copying/linking in old cluster data files, and stop the new > postmaster. > 2) Take a "base backup" style copy (tar, rsync, $FAVOURITE) of the new > cluster (small, since without data files) > 3) Have pg_upgrade leave a log of exactly which old cluster data files > go where in the new cluster > > That way, anybody, any script, etc who wants to make a new "standby" > from and old one only needs the pg_upgrade base backup (which should > be small, no data, just catalog stuff), and the log of which old files > to move where. > > The only pre-condition is that the standby's "old pg" *APPLIED* WAL up > to the exact same point as the master's "old pg". In that case the > standby's old cluster data files should same enough (maybe hint bits > off?) to be used. I am not sure what a base backup is buying us here --- base backup is designed to create a backup while the server is running, and it is down at that point. I think what you are suggesting is to make a data dir copy while just the schema is in place. That is possible, but it opens up all kinds of possible failure cases because pg_upgrade operations have to be done in a specific order --- it feels very fragile. I think the commands to run after pg_upgrade --link completes on both primary and standby might be as easy as: cd /u/pg/pgsql.old/datafind . -links 1 -exec cp {} /u/pgsql/data \; Why would we want anything more complicated than this? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: