From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Lonni J Friedman <netllama(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade + streaming replication ? |
Date: | 2012-03-20 21:11:19 |
Message-ID: | 1332277879.806.3.camel@sussancws0025 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 2012-03-20 at 16:49 -0400, Bruce Momjian wrote:
> On Tue, Mar 20, 2012 at 02:58:20PM -0400, Bruce Momjian wrote:
> > On Tue, Mar 20, 2012 at 11:56:29AM -0700, Lonni J Friedman wrote:
> > > >> So how can you resume streaming without rebuilding the slaves?
> > > >
> > > > Oh, wow, I never thought of the fact that the system tables will be
> > > > different? I guess you could assume the pg_dump restore is going to
> > > > create things exactly the same on all the systems, but I never tested
> > > > that. Do the system id's have to match? That would be a problem
> > > > because you are initdb'ing on each server. OK, crazy idea, but I
> > > > wonder if you could initdb on the master, then copy that to the slaves,
> > > > then run pg_upgrade on each of them. Obviously this needs some testing.
This sounds promising. Fundamentally, the user data files aren't
changing, and if you can upgrade the master you can upgrade the slaves.
So there is no fundamental problem here, but there will be some careful
bookkeeping.
I think we need to look at this as a new feature that needs its own
testing and documentation.
It's important though, because as you point out downthread, rsync
doesn't really solve the problem (still takes time proportional to the
user data size).
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Chambers | 2012-03-20 21:17:17 | Re: pg-admin development snapshots |
Previous Message | Cody Cutrer | 2012-03-20 20:55:08 | Indexes on System Table |