If you’ve read anything I’ve written lately or heard me speak in a recent conference or customer event, it should be obvious that I’m quite fond of the IDS 11 release. It is chock full of technology, both new and improved, that has changed how IBM and the outside world perceives and thinks about IDS. In the dedication to the “flash” book IBM published with the IDS 11.10 release, [available here
], I wrote that I was never more proud to represent the work of the IDS development team and I meant every word. It is a phenomenal product.
Of all the technology in the release, the one that has most captured my attention and I have focused a lot of my time and effort it on is the High Availability cluster. I have written several IBM Proofs of Technology (PoT) exploring various aspects of all the IDS data replication technology but the H/A technology excites me the most. I just finished updating the latest and most comprehensive IDS H/A PoT and thought I’d share a little bit of what I found out working with a new feature added in the xC5 fixpack for IDS 11.50 -- delayed application of transactions on an RS secondary instance.
In a nut shell, delayed apply on an RS secondary is the ability to add protection against accidental or intentional SQL operations to the H/A cluster. You can read the IDS Administration manual and get all the technical details about what the parameters are and how to set them up. Here’s what I found in testing the technology that is NOT in the manuals. As an aside, the fourth point is the most interesting.
First, this functionality kind of breaks the rule that all the instances in an H/A cluster must be configured identically. Yes, IDS allows you to use different server names and some small variation to the number of CPU VPs and memory but we’ve always said everything else must be the same. Not so with this functionality. You only need to set the $ONCONFIG parameters governing delayed apply on the RS secondary(s) you want to hold transactions.
Second, while you obviously need to set the three parameters (DELAY_APPLY, STOP_APPLY, and LOG_STAGING_DIR) before starting the instance, what is NOT explained is there is a specific permission setting for LOG_STAGING_DIR. You are required to use 760 / informix:informix for the entire path. If you don’t, the instance will give you permission errors and not start the restore process.
Third, When you turn the delayed RS secondary on, it does NOT delay transactions during the initialization procedure. The RS secondary will fully synchronize transactions with the cluster primary that occurred after the backup image until the last completed checkpoint. When the last checkpoint is reached in the logical log records, the RS secondary will switch to delaying transactions.
Fourth, if the cluster is configured to support updatable secondary instances, a delayed apply RS secondary will be able to execute DML operations. What is interesting though is when applications executing on that secondary can use the changed data and how sessions are affected by executing a DML statement. In my testing, I opened several dbaccess sessions pointing to different instances in the cluster. I executed a simple insert into statement into an existing table on the delayed RS secondary. The statement indicated the row had been inserted successfully. I checked other instances in the cluster and found the data had been immediately replicated throughout the cluster. I opened a new dbaccess session on the delayed RS secondary and executed a “select *” on the table and found the row was NOT there. Hmmmm. I went back to the session that inserted the row and tried to select from the table but the select statement hung until the DELAY_APPLY seconds passed, then the statement returned with all the rows. I also re-executed the select in the other session and found that it now returned the new row. Most interesting. I kind of expected another session to not see the data until DELAY_APPLY time had passed but I was not expecting what happened in the session that made the change. I have not tried this using a programing language like 4GL or Java to see if the select behavior in the session but at this moment in time, it appears that executing DML statements for delayed RS secondary instance might not be the best idea.