Re: LISTEN/NOTIFY for lightweight replication

Поиск
Список
Период
Сортировка
От Ted Shab
Тема Re: LISTEN/NOTIFY for lightweight replication
Дата
Msg-id 20041013153204.10561.qmail@web41014.mail.yahoo.com
обсуждение исходный текст
Ответ на Re: LISTEN/NOTIFY for lightweight replication  (Richard Huxton <dev@archonet.com>)
Ответы Re: LISTEN/NOTIFY for lightweight replication  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Re: LISTEN/NOTIFY for lightweight replication  (Richard Huxton <dev@archonet.com>)
Список pgsql-general
Richard,

Thanks for the response.

I'll look into both the dblink and iirc.

Do you know of any extended examples of either?

--Ted
--- Richard Huxton <dev@archonet.com> wrote:

> Ted Shab wrote:
> > Hi,
> >
> > I'm trying to come up with a relatively simple
> > multi-master replication solution.  This is for
> > multiple databases that need to be discreet, and
> > change relatively infrequently (10-30 updates an
> > hour), and almost never update each others data
> (less
> > than once a day).
> >
> > The TCL-based replication project for multi-master
> is
> > troublesome to configure and seems to really
> impact
> > performance.  It can be assumed that the
> master-slave
> > setup will not work for me, nor do we want to
> purchase
> > a commercial soluton, nor can we run this all from
> one
> > central database.
>
> > e.  If there is a field level conflict, raise an
> > exception (TBD).
>
> Exception handling and failure recovery are what
> makes for all the work
> in replication.
>
> I don't think a pure listen/notify setup will be
> enough because iirc the
> system doesn't guarantee delivery of multiple
> notifications if >1 are
> queued.
>
> Have you looked into the possibility of using dblink
> to handle updates
> of each others' data? That would mean your problem
> reverting to one of
> single-master replication.
>
> --
>    Richard Huxton
>    Archonet Ltd
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose
> an index scan if your
>       joining column's datatypes do not match
>




_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

В списке pgsql-general по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Recovering data from corrupted table. Urgent Help!!
Следующее
От: Tom Lane
Дата:
Сообщение: Re: could not access status of transaction 4244329