From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Gideon <gideondebian(at)isogo(dot)co(dot)za> |
Cc: | List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Database Mirroring Solution |
Date: | 2006-11-10 11:56:49 |
Message-ID: | 45546901.5020500@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Gideon wrote:
> Thanks for the quick reply.
No problem, but don't forget to cc: the list.
> We basicaly need to run a database servers in 2 different
> towns. Now there will be update's and selects and both need
> to be in sync with each other. Aswell as if / when database in
> town 1 goes down ... we need to be able to switch to the database
> in town 2 for emergency purposes. We cannot use just one master
> as the connectivity between the two towns isn't fast enough for
> the amount of users that will be viewing data through the connection.
>
> (The fastest affordable connection here for this purpose is round about
> 256k.)
A slow link is going to cause problems with most replication solutions
anyway. Well, there are two options that I can think of:
Option 1:
Run Slony replicating from town1 to town2.
Run PgPool connection pooling at town2 and route any update queries to
town1.
Cope with the delay on updates propagating.
Option 2:
Use table partitioning to split e.g. customers by town.
Use slony to replicate customers_town1 to town2 and customers_town2 to
town1.
Users can't update data "owned" by the other town - enforce this with
suitable GRANT/REVOKE.
Either of those any use?
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2006-11-10 11:58:46 | Re: ECPG and multiple threads |
Previous Message | Enrico | 2006-11-10 11:48:16 | Re: Database Mirroring Solution |