Обсуждение: AW: Big projet, please help

Поиск
Список
Период
Сортировка

AW: Big projet, please help

От
Zeugswetter Andreas SB
Дата:
> The only commercial replication system that I am familiar 
> with will go both
> ways, but not for the same table. ie.
> 
> DB1           DB2
> ===           ===
> Table1  --->  Table1
> Table2  <---  Table2

No. Informix has update everywhere replication in the standard IDS server.
Informix replication is configurable from sync to async repl (Laptops) with 
several options of behavior in the case of conflict (network outage ...) .

> But you could implement a kind of replication by using triggers on the
> tables to be replicated: write out the record key, and the operation
> performed (add, change,delete) to another table. Then have an 
> (hourly?)
> replication process that sends the changes to the replicated 
> database(s).
> Pretty low-tech, but probably quite reliable.

If you can, I would do the replication online in the trigger stored
procedure.
This of course implys an update everywhere or not at all. If connection
between
the two servers is lost no update is possible.

Andreas


Re: AW: Big projet, please help

От
Philip Warner
Дата:
At 11:58 8/06/00 +0200, Zeugswetter Andreas SB wrote:
>
>> The only commercial replication system that I am familiar 
>> with will go both
>> ways, but not for the same table. ie.
>> 
>
>No. Informix has update everywhere replication in the standard IDS server.
>Informix replication is configurable from sync to async repl (Laptops) with 
>several options of behavior in the case of conflict (network outage ...) .
>

That's interesting. Out of curiosity, what choices does it provide for the
following:

a) Two inserts on a (unique) primary key

b) Two inserts on a unique index (slightly different to (a))

c) Two updates to different fields in the same record

d) Two updates to the same field in the same record

e) Deletion of a record and update of the same record

>If connection between
>the two servers is lost no update is possible.

Unfortunately this restriction removes *one* of the motivations behind
replication. It might be better to implement a queue of pending updates in
another table, where the master database applies or rejects the updates
according to rules of the application. Needless to say, the mechanics could
get pretty ugly. Hence my curiosity about the answers to the above questions.




----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/