tag:blogger.com,1999:blog-826910957631479390.post5715894754250664595..comments2024-03-28T03:15:27.747-07:00Comments on Evol Monkey: An unusual upgradeEvol Monkeyhttp://www.blogger.com/profile/01346397854558520528noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-826910957631479390.post-34651704953367694382017-06-20T12:33:31.783-07:002017-06-20T12:33:31.783-07:00Hi,
Why don't you use slony un such situation...Hi,<br /><br />Why don't you use slony un such situation ? I have upgraded a few clusters using it with great success... You could have jump from 9.2 to 9.6 directly without the third cluster in the middle...ioguixhttps://www.blogger.com/profile/11482018828370971666noreply@blogger.comtag:blogger.com,1999:blog-826910957631479390.post-16921904633054340012017-06-10T12:42:10.726-07:002017-06-10T12:42:10.726-07:00This scenario was meant to simulate a migration of...This scenario was meant to simulate a migration of a live production database while having transactions running with minimal downtime. Minimal downtime being the key point here, I don't see how this is possible with pg_dump.<br />Evol Monkeyhttps://www.blogger.com/profile/01346397854558520528noreply@blogger.comtag:blogger.com,1999:blog-826910957631479390.post-780232532386910882017-06-10T11:03:03.470-07:002017-06-10T11:03:03.470-07:00Just curious why something like the below was not ...Just curious why something like the below was not an option:<br /><br />pg_dumpall(9.6/bin/) | psql -d pg06_db<br /><br />The procedure shown in the post seems to be the long way to get to the same place. Of course I may be missing something obvious.Adrian Klaverhttps://www.blogger.com/profile/09632095365606250299noreply@blogger.com