Highly available databases
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 the data store for the messaging engine.
Databases that have a high availability framework or feature might have redundant primary and standby servers. If we 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 we 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 we configure a WAS to use a highly available database as the 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 the configuration:
- If we are running a single server, WebSphere Application Server provides no failover support. Consider other high availability provisions.
- If we are running WebSphere Application Server Network Deployment without clustering, the default configuration for the node agent ensures automatic restart.
- If we are running WebSphere Application Server Network Deployment with clustering, peer recovery restarts the messaging engine. Ensure that we have configured the high availability policy to enable peer recovery.
Related concepts
Message store high availability Message stores