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 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 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 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.