Read this topic to understand the considerations that apply when
you use a highly available database as your data store.
Databases that have a high availability framework or feature can have redundant
primary and standby servers. If you are using such a database as your data store, note the following
restrictions:
- It is important to ensure that the primary and standby databases are identical
when the standby takes over from the primary database, unless you stop and
restart your messaging engine before
connections are routed to the standby database. If database clients, such
as the messaging engine, are transparently
routed from the primary database to the standby database, the messaging engine relies
on the data in both databases being identical.
- Do not use the one-phase commit optimization that enables applications
to share the JDBC connections used by a messaging engine.
If you use the High Availability Data Recovery (HADR) feature
of DB2, note the following restrictions:
- The messaging engine default
messaging provider supports only the synchronous and near-synchronoous synchronization
modes of HADR. The default messaging provider does not support asynchronous
HADR configurations.
- The TAKEOVER BY FORCE command is permitted only when the standby database
is in peer state, or in a non-peer state (such as disconnected state) having
changed from peer state.
If you configure a WebSphere Application Server to
use a highly available database as your data store and
a database failover occurs, the application server on which the messaging engine is
running might stop. The cause of this problem is that the messaging engine cannot
always treat the failover as a transient communications error.
When you configure a messaging engine to
use a highly available database for its data store,
ensure that the messaging engine can
restart automatically following an application server failure. Choose the
option that is appropriate for your configuration:
- If you are running a single server, WebSphere Application Server provides
no failover support. Consider other high availability provisions.
- If you are running the Network Deployment version without clustering,
the default configuration for the node agent ensures automatic restart.
- If you are running the Network Deployment version with clustering, peer
recovery restarts the messaging engine.
Ensure that you have configured the high availability policy to enable peer
recovery.