RE: Replication and HDR
OK, here's my .02... I am currently responsible for four HDR-pairs of servers -- three production pairs and one development pair. All servers are HP boxes, but I'm sure that most of this will apply to AIX, too. For each production server-pair, one server is in Sacramento, CA, and the other is in Phoenix, AZ. Let me try to answer each question below... > -----Original Message----- > From: gresmi@yahoo.com [mailto:gresmi@yahoo.com] > Sent: Tuesday, November 30, 1999 6:38 PM > To: informix-list@iiug.org > Subject: Replication and HDR > > > We are looking at implementing replication between 2 of our servers, a > primary in Ft. Lauderdale and the secondary in L.A., possibly using > Informix's High Availability Data Replication (HDR) tool. > > Our questions are these: > 1. The Informix manuals state that the hardware and OS must > be identical > for the primary and secondary server. How much flexibility is there > on this? The Ft. Lauderdale machine is an IBM RS/6000 J30 and the L.A. > machine is an IBM RS/6000 F30. Our Ft. Lauderdale machine > has 4 CPU's and the L.A. machine has 1. We have AIX 4.3.2 > running on our > primary machine in Ft. Lauderdale and AIX 4.3.1 running on > the secondary machine in L.A. Our Ft. Lauderdale machine has 512MB of > memory and the L.A. machine has 256MB. It's been recommended that we > sync the AIX versions, but I haven't gotten a definitive answer on the > hardware. Do any of these situations require changes? It's not a great > undertaking to upgrade the L.A. machine to 4.3.2. I don't think ANY of our primary/secondary servers are EXACTLY alike! I know for a fact that there are differences in memory size, physical disk layout -- even the hardware models are slightly different. But I do know that the OS version and the IDS version have to be identical on each box. Other than those, the critical thing seems to be the logical database dbspace/chunk disk layout. Logical logs must be same number/size, and I believe that physical log must be identical also. Memory parameters, such as buffers, SHMVIRTSIZE, etc., don't seem to be as critical. Of course, all of your DR... parameters in the ONCONFIG files must be identical on each side, or you will run into problems. > > 2. We've found some comments on the web regarding the Informix version > to use for replication. Most of those of a positive nature recommend > using v7.31uc4, or at least v7.31uc3. We're leaning toward > syncing them > at v7.31uc4, charmed with the notion that the latest should be the > greatest. That recommendation is primarily in regard to Enterprise Replication (aka CDR), which is an entirely different beast from HDR. ER is really just coming into maturity and stability with the 7.31 version -- HDR has been "stable" for quite some time now. Check with Tech Support for any outstanding HDR bugs that may apply to your environment, and which releases they are fixed in. > > 3. Can HDR be implemented using buffered logging instead of unbuffered > logging? The production databases on both these machines currently use > buffered logging? Are there disadvantages to doing that? Buffered logging works just fine -- that's what we use, primarily for performance reasons. Again, the unbuffered logging recommendation is aimed mainly at ER. The only real disadvantage to buffered logging is a slightly higher risk of data loss (server crashes with commit(s) still in buffer ==> loss of that data). But this is regardless of whether you are using HDR or not. > > 4. If we're configuring for a primary/secondary scenario with the > secondary to serve as a hot backup, what would be the preferred method > of transfer? Asynchronous or synchronous? We use asynch, because we don't want to risk having a transaction wait until the data gets replicated to the secondary. And with your even greater distance between primary and secondary, I would HIGHLY recommend staying away from synchronous. Unless, of course, your users are not that concerned about response time. In general, data gets replicated quite fast -- It's just the occasional network hiccup that could hold up activity on the primary (if you use synchronous). Also, I'll go ahead and mention here that we do NOT use automatic failover. Our home-grown applications are not yet smart enough to automatically switch to the secondary server if the first one is unavailable. HDR will not automatically re-route sessions from one server to another -- it simply switches the "modes" of the instances on the two servers. > > 5. Also, the dbspaces, logical logs, physical log, and config > files are > virtually the same, needing only some minor tweeking to sync them up. Looks like you're almost ready to go! :-) > > Does HDR sound like a decent solution for our requirements? We need a > hot backup server that can stand in and handle production processes in > the case of failure of the primary server in Ft. Lauderdale, with the > least amount of impact to the primary production system. No writes are > to take place on the secondary, unless the primary were to fail. The > machines can already talk to each other through the network. Sounds to me like HDR is a good fit. I will mention one thing, though. You said that your primary has 4 cpu's and the secondary has 1. If you have to switch all of your application work over from a 4-cpu machine to a 1-cpu machine, maybe for an extended period -- will that 1-cpu box have enough horsepower to handle the load? Same question in regard to physical memory. I don't think that the cpu / memory differences will prevent HDR from working, but you might want to take a look at the potential after-switchover scenario. > > Thanks Much, > Greg You're welcome! HTH Paul Mosser > > > Sent via Deja.com http://www.deja.com/ > Before you buy. >