Re: Info Req: Informix online replication services

> > Informix On Line Replication Services > > I am considering using Informix On Line Replication Services in an application > where we would have a number of geographically seperated offices that will > feed transactions into 12 regional servers. Each regional server is expected to > have a maximum load of +/- 5,000 transactions per day. > The regional servers will in turn, feed their transactions up to > an enterprise server. > > I also would want changes made to records at the enterprise server level to be > automatically replicated back to the offices where they were origionally > entered. > > All responses / comments / recommendations are greatly appreciated. > Thanks in advance. > JR JR, A number of pints here. Points, I mean points! 1. Informix Replication Services today exists only in V6.0. It is limited to a hot standby capability in that it is able to replay the Informix log files produced at the main site against a duplicate database at a replication site. No transactions are allowed at the replication site which can only be used in a read only fashion. A more extensive replication server is not expected until V8 or even V9. 2. It seems clear from your description that the replication will occur in the background rather than as part of the transaction. This is reasonable as attempting to keep more than 3-6 servers involved in a single transaction using I-Star is pretty well doomed to failure. Not that this is I-Star's problem particularly. Just that keeping all the combs links, machines, software, etc online becomes a major issue as any lost node stops the whole system. 3. Given (2) you need to consider the integrity failures that may result in your scheme. Consider the following scenarios. A) a) Transaction entered to regional server. b) This transaction is then replicated that night to the enterprise server. c) Following day updates are made at both the regional and enterprise servers to the records involved in the transaction. d) That night the enterprise server will try and update the regional server and vice versa. Who has the correct copy? In other words which system is treated as the "Database of Record"? How do you ensure that the replication service makes sure that the data is reset correctly at the replicated sites? How do you report that a transaction entered has been rejected in favour of another transaction? B) a) Regional server enters a delete transaction. b) Delete is replicated to Enterprise server but is rejected based on a business rule check. How to set the regional server back to it's original values? How to report the failure of the transaction? C) a) Regional centre goes down with complete loss of data. b) For any number of reasons local backups cannot recover the system to the correct position in the replication cycle. How is the regional server to be completely refreshed from the Enterprise Server? How would a new Regional centre be brought on line taking ownership for data from various other regional centres? When you get into scenarios where more than one regional centre can update the same data the problems go up exponentially. By careful design of the database and transactions to be applied, many of these problems can be removed or at least reduced. A very close check must be kept on who is allowed to update what, where and when for the design to work. Also the replication service itself must be reliable so as to make sure that regional sites do not get to far out of sync with the centre. 4) Two simplifying options exist. a) Transactions can only be applied through the centre and replicate down. The regional centres are used for reporting and query only. Probably not very useful to you. As it happens this is what I am currently developing. Database of record is centralised. b) Transactions can only be entered at the region to data owned by the region. Replication flows up to enterprise server and out to other regional servers but if data is not owned by a region it is read only. Enterprise server is entirely read only for reports and queries. If other regions or the centre need to update then they must remotely connect to the correct regional server. Database of record is distributed. The option of only allowing one region and the centre to update a peice of data exists. This removes the complexity from multiple regional updates but still requires a refresh system to clean up and report on transaction clashes between the region and the centre. 5) Alternative products: The only product, that I'm aware of, that provides a full replication service for an Informix database is a product from Germany. Contact is: oliver@infix.de Oliver Okrongli infix Software-Systems GmbH Tel +49 531 238090 Rebenring 33 Fax +49 531 2380935 38108 Braunschweig F.R.Germany The last time I spoke to them they were still translating documentation into English and had no US reference sites. From our discussions the package appeared pretty functional but who knows until you try it out! Support would also be an issue. 6) What are we doing: Currently we have decided to develop our own service as our application design allows us to record transactions at the client to database server interface. These recorded transactions can then be replayed against a remote database server interface to update a regional database. Hope this helps? Cheers - Jim My opinions are my own. They may vary with time but they remain MINE! ---------------------------------------------------------------------- Name: Jim Gordon Company: DHL Systems Inc, Burlingame, CA, USA ----------------------------------------------------------------------