Re: pg_upgrade and rsync
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade and rsync |
Дата | |
Msg-id | 20150220144508.GA20442@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade and rsync (David Steele <david@pgmasters.net>) |
Ответы |
Re: pg_upgrade and rsync
|
Список | pgsql-hackers |
On Thu, Feb 19, 2015 at 09:35:02PM -0500, David Steele wrote: > On 2/19/15 11:57 AM, Bruce Momjian wrote: > > On Wed, Jan 28, 2015 at 09:26:11PM -0800, Josh Berkus wrote: > >> > >> 3. Check that the replica is not very lagged. If it is, wait for > >> traffic to die down and for it to catch up. > > > > Now that 9.4.1 is released, I would like to get this doc patch applied > > --- it will close the often-requested feature of how to pg_upgrade slave > > clusters. > > > > I wasn't happy with Josh's specification above that the "replica is not > > very lagged", so I added a bullet point to check the pg_controldata > > output to verify that the primary and standby servers are synchronized. > > > > Yes, this adds even more complication to the pg_upgrade instructions, > > but it is really more of the same complexity. pg_upgrade really needs > > an install-aware and OS-aware tool on top of it to automate much of > > this. > > #3 bothered me as well because it was not specific enough. I like what > you've added to clarify the procedure. Good. It took me a while to understand why they have to be in sync --- because we are using rsync in size-only-comparison mode, if they are not in sync we might update some files whose sizes changed, but not others, and the old slave would be broken. The new slave is going to get all new files or hard links for user files, so it would be fine, but we should be able to fall back to the old slaves, and having them in sync allows that. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: