minimizing downtime when upgrading - Mailing list pgsql-general

From snacktime
Subject minimizing downtime when upgrading
Date
Msg-id 1f060c4c0606152208r3567d85q5f4b19ffcad8ce44@mail.gmail.com
Whole thread Raw
Responses Re: minimizing downtime when upgrading  (Richard Huxton <dev@archonet.com>)
Re: minimizing downtime when upgrading  (Kenneth Downs <ken@secdat.com>)
Re: minimizing downtime when upgrading  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-general
Anyone have any tips for minimizing downtime when upgrading?  So far
we have done upgrades during scheduled downtimes.  Now we are getting
to the point where the time required for a standard dump/restore is
just too long.  What have others done when downtime is critical?  The
only solution we have been able to come up with is to migrate the data
on a per user basis to a new database server.  Each user is a
merchant, and the data in the database is order data.  Migrating one
merchant at a time will keep the downtime per merchant limited to just
the time it takes to migrate the data for that merchant, which is
acceptable.

Any other ideas?

pgsql-general by date:

Previous
From: Chander Ganesan
Date:
Subject: Re: Omitting tablespace creation from pg_dumpall...
Next
From: Wayne Conrad
Date:
Subject: Re: table has a many to many relationship with itself ... ?