Highly available databases are highly scalable and depend on a
relational database management system (RDBMS) that is always running. Restrictions
apply when you choose a highly available database as your data store for the
messaging engine.
Databases that have a high availability framework or feature might have
redundant primary and standby servers. If you are using such a database as
your data store, certain specific actions are required:
- Ensure that the primary and standby databases are identical when the standby
database 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 routed by the system
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 when the standby database had last changed from peer
state to its current state (such as disconnected 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 WebSphere Application Server Network Deployment without
clustering, the default configuration for the node agent ensures automatic
restart.
- If you are running WebSphere Application Server Network Deployment with
clustering, peer recovery restarts the messaging engine. Ensure that you have
configured the high availability policy to enable peer recovery.