Application architecture
In a Db2® Mirror environment, the data is synchronously replicated between the nodes. The recovery time and recovery point objectives for your users will depend on the application architecture.
The application architecture model shown below is common today. The application is designed to be accessed and run on a specific IBM® i node.
You can continue to run these applications in either an active/passive or active/active environment. If a node becomes unavailable because of a planned or unplanned outage, users might need to take action to switch to the remaining node. Application state data may need to be included in the replicated data. In this application environment, in addition to the load balancing or business intelligence opportunities available with the synchronous data transfer, Db2 Mirror generally allows for faster switchovers of the application than other high availability solutions since the data is immediately available on the remaining node.
Takeover IP address groups is a Db2 Mirror concept which can help manage the access to applications within the Db2 Mirror environment. IP addresses can be associated with an application and switched between the Db2 Mirror nodes when a node becomes unavailable.
Applications that have been separated into an application and a data layer may be able to exploit Db2 Mirror to achieve an even lower recovery time objective as shown in this figure.
If your applications already have a separate application layer (running on IBM i or some other platform) and are using a connection technology such as JDBC, your entire application may easily be ready for continuous application availability. The JDBC layer has the ability to have a secondary connection to another node. If the first node is no longer available, the JDBC connection will automatically switch to the secondary node. There are other types of connections and technologies with built-in failover capability that also could be used.