Data Rep Update-Anywhere
Posted in 1999
Topics: Stored Procedures & SPL, Versions, Editions & End-of-Life
2 x Dell quad P3 500Mhz NT Servers running NT 4, IDS 7.31 We are planning to replicate our two servers using peer to peer (update anywhere) replication. The reason for this is fairly simple but lengthy to describe. Enough to say that the two servers are going to be configured exactly the same. The input stream of transactions is going to be split before it gets to either of the databse servers so that the workload is going to be split accross the 2 servers. (odd transaction numbers on one server, even on the other). Once the transactions are committed on one machine they are to be replicated on the other machine. Now, I have been reading the manual regarding considerations that have to be taken when designing the database for update-anywhere replication but am a little confused (specifically regarding the additional serial columns that have to be present in the tables, due to the conflict-detection and conflict-resolution rules that will apply. If there is anyone out there who has successfully implemented such a replication strategy, or someone who knows what I'm talking about, I would be very pleased to hear from you. TIA Sean :-) Sent via Deja.com http://www.deja.com/ Before you buy.
The most common approch to conflict resolution is by time. The rule being that the "lastest update to the row wins". The two shadow columns contain the CDRID of the instance that the last update was done and the time (i.e. time() ) that the update was done. They are not serial columns. By having these two columns, we are able to determine wheither the row being replicated is actually the last update done on that row. If it is, then we apply it. If it is not, then we reject it. These are shadow columns. They do not exist in syscolumns and are not retrieved by a "select *" from the table. It is good that you are using 7.31 to do this. FYI - the TC4 interim release is to be released this Friday. It contains a couple of patches for some memory leaks as well as provides full support for Hierarchial Routing. You might want to consider it. chilliinc6230@my-deja.com wrote: > 2 x Dell quad P3 500Mhz NT Servers running NT 4, IDS 7.31 > > We are planning to replicate our two servers using peer to peer (update > anywhere) replication. The reason for this is fairly simple but lengthy > to describe. Enough to say that the two servers are going to be > configured exactly the same. > > The input stream of transactions is going to be split before it gets to > either of the databse servers so that the workload is going to be split > accross the 2 servers. (odd transaction numbers on one server, even on > the other). > > Once the transactions are committed on one machine they are to be > replicated on the other machine. > > Now, I have been reading the manual regarding considerations that have > to be taken when designing the database for update-anywhere replication > but am a little confused (specifically regarding the additional serial > columns that have to be present in the tables, due to the > conflict-detection and conflict-resolution rules that will apply. > > If there is anyone out there who has successfully implemented such a > replication strategy, or someone who knows what I'm talking about, I > would be very pleased to hear from you. > > TIA > > Sean > :-) > > Sent via Deja.com http://www.deja.com/ > Before you buy.