Re: Database Mirroring Solution - Mailing list pgsql-general

From Gideon
Subject Re: Database Mirroring Solution
Date
Msg-id 45546B71.4040101@isogo.co.za
Whole thread Raw
In response to Re: Database Mirroring Solution  (Richard Huxton <dev@archonet.com>)
Responses Re: Database Mirroring Solution
List pgsql-general
Richard Huxton wrote:
> 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 1 Seems like a possibility I do some more research into this...
Thanks a lot.

> 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.
>
Option 2: Doesnt quite seem like a possibility as users in both towns
must be
able to work on the same records and update the same information.
> Either of those any use?

Thanks for the advice. I will keep it in mind. I also just wanted to
make sure
that I havent missed something or some solution that is already out there to
cater for my needs.

pgsql-general by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: ECPG and multiple threads
Next
From: Markus Schiltknecht
Date:
Subject: SSL Certificate Check