Re: minimizing downtime when upgrading

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: minimizing downtime when upgrading
Date: 2006-06-16 17:47:58
Message-ID: 20060616134758.8bf6067d.wmoran@collaborativefusion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In response to snacktime <snacktime(at)gmail(dot)com>:

> On 6/16/06, Richard Huxton <dev(at)archonet(dot)com> wrote:
>
> > The other option would be to run replication, e.g. slony to migrate from
> > one version to another. I've done it and it works fine, but it will mean
> > slony adding its own tables to each database. I'd still do it one
> > merchant at a time, but that should reduce your downtime to seconds.
>
> I'll have to take another look at slony, it's been a while. Our
> database structure is a bit non standard. Being a payment gateway, we
> are required to have a separation of data between merchants, which
> means not mixing data from different merchants in the same table.
> So what we do is every user has their own schema, with their own set
> of tables. Yes I know that's not considered the best practice design
> wise, but separate databases would have caused even more issues, and
> as it turns out there are some advantages to the separate schema
> approach that we never thought of. Last time I looked at slony you
> have to configure it for each individual table you want replicated.
> We have around 50,000 tables, and more are added on a daily basis.

We've got a script here that takes a pg_dump and automatically generates
a slony config that adds all tables and sequences. I've got to check with
the Powers That Be, but i suspect we'll be opening up the code.

Does this duplicate any work that anyone else is doing?

--
Bill Moran
Collaborative Fusion Inc.

****************************************************************
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************

In response to

Browse pgsql-general by date

  From Date Subject
Next Message LLC 2006-06-16 17:57:40 How to install PL/perlU (perl untrusted)
Previous Message Bruno Wolff III 2006-06-16 17:30:15 Re: table has many to many relationship with itself - how