Midrange Dynamics Speeds Table Updates In Db2 Mirror Clusters
August 5, 2019 Alex Woodie
With the launch of Db2 Mirror with IBM i 7.4 in June, IBM heralded the age of continuous availability on the midrange platform, bringing IBM i up to par with Windows and Linux platforms. However, while the new software keeps production data in perfect synch, it’s not so great at keeping up with changes to underlying database tables. That’s an area that Midrange Dynamics is addressing with its change management software.
With Db2 Mirror, IBM has essentially extended a single-server database implementation into a clustered database with two active nodes. As soon as a piece of data is created, updated, or deleted on one node, that CRUD action is instantly duplicated on the second node via a high-speed Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCE) link.
The speed and reliability of Db2 Mirror make it a great data platform for building continuously available applications, particularly for companies that can’t afford any downtime, planned or otherwise. Db2 Mirror doesn’t provide protections against disasters, as we’ve previously covered, but it does boost the reliability of IBM i services within a single data center environment, and that is important.
Besides the lack of DR capabilities, there’s another aspect of Db2 Mirror that users should be aware of. According to Michael Morgan, the managing director and head architect of Midrange Dynamics, it can take many minutes or hours for Db2 Mirror to fully propagate changes to database tables. In some cases, with large databases, it can potentially take over a day.
Db2 Mirror turns two IBM i systems into a true active-active database cluster.
“Db2 Mirror takes care of availability for static tables. Tables are defined and rows are getting inserted, updated, and deleted. Db2 mirror takes care of that,” Morgan told IT Jungle at the POWERUp conference in May. “What it doesn’t take care of are changes to tables . . . you will have minutes to hours to days of downtime of doing that without a tool that takes care of that, that makes those changes while the applications are live on both active nodes.”
It is not uncommon for IBM i programmers to change database tables, such as by adding a new column to a table. After changes occur, other changes may be needed to be made to the database, such as updating indexes, views, and any joins, to reflect the new shape of the database.
When these changes are made to a production database that’s being replicated with Db2 Mirror, the database will institute a lock on the part of the database that’s been changed. Those locks can last from a few minutes to days, Morgan says. “It’s not designed to deal with changes to tables,” he says. “It’s just designed to deal with changes to records within tables.”
Morgan says a Midrange Dynamics tool called MDRapid can dramatically lessen the length of those locks.
As a component of the Midrange Dynamics Change Management System (MDCMS), MDRapid essentially creates a staging library where the database changes are mapped out ahead of time. Any updates made to the current version of the database are journaled and synced with the new version of the database that’s held in the staged library. When the customer has a spare moment for downtime, he can apply the database changes to one cluster, which then replicates it to the other.
“It’s not 100 percent continuous availability,” Morgan concedes. “But instead of hours or days of downtime to deal with getting the lock and doing the copy it’s a few seconds of downtime, because all of that is happening ahead of time, including the building of any indexes and views and so on. When our product gets the lock, it’s simply a ‘move object’ command. Whichever node they’re doing that on, then the move object is replicated on the other node.”
MDRapid speeds database updates by mapping the updates offline in a temporary library before going live.
Morgan said one of his clients runs IBM i servers that process credit card transactions on a 24/7 basis. The client, which was not running Db2 Mirror, has a maximum downtime window of 2 minutes for maintenance. However, to propagate database changes, they discovered (via trial and error on a couple of test machines) that it would take them 17 hours.
“When they brought in MDRapid, it took that down from 17 hours to just a couple of seconds,” Morgan says.
MDRapid is a component of MDCMS, which was just updated with version 8.2. With Db2 Mirror now available with IBM i 7.4, the company is looking to broaden the use of MDRapid. “It solves something that IBM wanted to solve but they didn’t’ solve themselves as far as the changes to the database,” Morgan says
The company also added a new API generation feature with MDCMS 8.2. According to Morgan, the product will automatically create a REST API from IBM i code that’s managed in the product, thereby enabling customers to get their code out fast.
“Customers can either point it to an open API spec or Swagger spec, or they can just say, it’s based on this database table collection, and MDCMS generates the RPG code,” he said. “They instantly have a REST API that can run through the Apache server, so it’s very fast. There’s no Java overhead.”
The simplicity of this approach will appeal to IBM i shops that don’t have the time to learn more complex skills. “They don’t really have to understand what REST is because we take care of the whole framework around it with token authentication and everything else, and dealing with the Apache services,” he said. “All they have to understand is how to write the RPG code.”
Midrange Dynamics is headquartered in Switzerland and has U.S. offices in Houston, Texas, and Peterborough, New Hampshire. The company has hundreds of customers around the world, including some IBM i software vendors, who utilize MDCMS for its code distribution capabilities, which Midrange Dynamics considers a specialty.
RELATED STORIES
Does Db2 Mirror Kill The Market for Third Party HA?
IBM i Database Capabilities Highlight Midrange Dynamics’ Development Activity
