Re: pg_upgrade + streaming replication ? - Mailing list pgsql-general

From Jeff Davis
Subject Re: pg_upgrade + streaming replication ?
Date
Msg-id 1332277879.806.3.camel@sussancws0025
Whole thread Raw
In response to Re: pg_upgrade + streaming replication ?  (Bruce Momjian <bruce@momjian.us>)
List 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


pgsql-general by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: pg-admin development snapshots
Next
From: Andy Chambers
Date:
Subject: Re: pg-admin development snapshots