An Explanation of IBM i 7.4 DB2 Mirror for i

On April 23rd, 2019, IBM announced the newest release of the operating system IBM i 7.4. The announcement contained hundreds of updates to the OS and licensed programs. 

One new licensed program, DB2 Mirror for i was also announced. It provides continuous availability for IBM i applications. “Continuous Availability” is a new term, which previously we had High Availability

  • How is Continuous Availability different than High Availability?
  • What are the software and hardware requirements for Db2 Mirror for i? 
  • Does DB2 Mirror for i replace all the Data Replication products? 
  • When should I consider using DB2 Mirror for i? 

For the answers to these questions, and more, keep reading.

DB2 Mirror for i allows two or more local servers, called a cluster, to “share” a database.  That means that the same database exists on more than one server and when an update occurs to the database on one server, the update is replicated to the copy of the database on the other servers, keeping them in sync.  Updates are bidirectional, all servers are active (called active-active).  With DB2 Mirror for i, when a server fails, there is no recovery time (RTO is zero) and no data loss (RPO is zero), and the application continues to run on the remaining servers.  Hence the term “Continuous Availability”.

What is the difference between Continuous Availability and High Availability? 

Continuous availability has no downtime or data loss when a server fails. The other server can continue to operate with its copy of the current database.  With High Availability, when a server fails, it will take some time, usually an hour or less, to prepare the other server to run the production workload.  High Availability is a WARM availability solution, while Continuous Availability is a HOT availability solution. 

Does DB2 Mirror for i replace all the Data Replication products? 

No.  Simply, data replication products provide both High Availability and Disaster Recovery.  DB2 Mirror for i does not provide Disaster Recovery

DB2 Mirror for i requires that both servers to be on a high-speed local network because database updates are performed synchronously in order to keep both copies of the database in sync.  If there is an event that affects both servers (loss of power for example), then both servers and the application will be down. With data replication products, database updates can be replicated asynchronously to servers in different locations.  A power outage in one location will not affect the other location and the application can continue to run on the second server.

What are the software requirements for DB2 Mirror for i? 

  • 5770-SS1, IBM i V7.4
  • 5770-SS1, option 48 – DB2 Mirror (new)
  • 5770-SS1, options: 3, 12, 26 (optional, chargeable), 30, 33, 34 (optional), 41 (chargeable)
  • 5770-JV1, IBM Developer Kit for Java, with options: 16 and 17
  • 5770-SC1, IBM Portable Utilities, with option: 1
  • 5770-DG1, IBM HTTP Server for i
  • 5770-DBM, DB2 Mirror for i

What are the hardware requirements for DB2 Mirror for i?

  • Power8 or Power9 servers that support IBM i
  • Network adapters that support RoCE – RDMA (Remote Direct Memory Access) over Converged Ethernet
  • Hardware Management Console (HMC)
  • Storage – IBM DS8000 or IBM Spectrum Virtualize

What does DB2 Mirror Replicate? 

DB2 Mirror uses five Network Redundancy Groups (NRGs) for:

  • DB2 Mirror Environment Manager
  • Database replication
  • System Object replication
  • IFS replication
  • Resynchronization

DB2 Mirror for i is for those applications that require continuous availability.  A few customers that I can think would be of interest are:  hospitals, casinos, banks, brokerage firms and those customers that operate a 24×7 application, like an internet storefront. 

The implementation cost for DB2 Mirror for i is going to be high, as compared to data replication, but once operational, the application should always be available.

2 thoughts on “An Explanation of IBM i 7.4 DB2 Mirror for i”

    1. It is not mandatory, but is a preferred solution as you will have SAN level redundancy too.
      You can run both LPARs on same SAN too, this is actually provide better performance

Leave a Reply to Ateesh Sharma Cancel Reply

Your email address will not be published.