Db2 Mirror advantages

Db2 Mirror - active/passive

You can choose to run your application on one of the nodes, with the other node in active standby mode with live production data ready to use. This is referred to as an active/passive environment. If your business has the requirement for real-time analysis of data, with Db2 Mirror there is an accessible copy of the production data on the second node. You can choose to run your production environment on one of the nodes, while running real-time queries and business intelligence on the second node with no performance impact to the production node.

Db2 Mirror - active/read-only

You can also choose to configure Db2 Mirror so one node is restricted from initiating changes to replicated objects. This is referred to as a read-only environment which is an active/passive environment that is enforced by the Db2 Mirror configuration. In a read-only environment, changes to replicated objects can only be initiated from the primary node. The secondary node remains in sync with the changes occurring on the primary node. Applications or users on the secondary node can read, but not initiate changes to the production data.

Db2 Mirror - active/active

For load balancing purposes, you can distribute users and applications across the nodes. This is called an active/active environment. Since updates to the replicated data are synchronous, users on both nodes see the same data. Within the IBM® i operating system, locking is implemented across the nodes to ensure the integrity of changes across the nodes. If a node becomes unavailable, users and applications can be redirected to the active node.

In each of these environments, with no application changes, you will see a reduction in production downtime due to outages.

Mixed release Db2 Mirror environment

One of the common pain points within a production environment is any outage required to perform system or application maintenance. Db2 Mirror can reduce and, in some cases, eliminate production outages due to planned IPLs and updates. With the ability to temporarily suspend replication, one node can continue processing transactions while the second node is IPLed or maintenance is applied. Once the IPL is complete and communication has been reestablished between the nodes, the changes that were tracked by the active node are pushed to the second node to make the database files identical again. Then the process can be reversed by suspending replication again and IPLing or performing maintenance on the first node.

A similar rolling upgrade strategy can be used to update your server or storage hardware. One node can be upgraded while replication is suspended and production continues on the other node. Replication can be resumed to bring the data up to date on the upgraded node. Then replication can be suspended again to upgrade the second node.

As shown in the figure below, the IBM i operating system levels and related software product levels do not need to be identical across the Db2 Mirror nodes. The rolling upgrade scenarios extend beyond differences in PTF levels to also support having the Db2 Mirror nodes running on different IBM i operating system levels.

By implementing an architecture that uses a synchronously replicated database you can reduce the time to switch over and minimize data loss in an unplanned outage. The Db2 Mirror product helps facilitate that goal within a data center and is compatible with most existing disaster recovery strategies.

Because the data is synchronously replicated between the nodes, the recovery point objective (RPO) and recovery time objective (RTO) for outages can be reduced to near zero. Application changes are not required to see a reduction in production downtime due to outages. Further RTO improvements can be seen if your applications are designed to run in a continuously available environment.