User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit

High Availability Overview

Running MDM in the high availability mode minimizes the chances of failure to provide consolidation, creation, and validation of master data. Operating MDM in the high availability mode is crucial if MDM provides services to customers (for example, front-end application), which require the 24x7x365 availability.

Supported HA Modes

MDM servers can be installed on a cluster with the following configurations.

Active/Passive (Cold Standby)

This is the most basic option. The primary MDM server is active (running and serving read and write requests). The secondary MDM server on the cluster is turned off (that is, in Cold Standby mode). If the primary MDM server fails, the secondary MDM server must be started manually or in a custom-built automated way. This configuration can fulfill only basic DR requirements, among the supported configurations this one will have the longest time to recover.

Active/Passive (Hot Standby)

The primary MDM server is active (running and serving read and write requests). The secondary MDM server is started in the RO mode and does not serve any read or write requests (that is, is in Hot Standby mode). If the primary MDM server fails, the secondary MDM server is automatically switched to RW mode and all traffic is re-routed to it. The benefit of this configuration is that the Hot Standby server is up-to-date with the runtime situation and is ready to start serving any requests faster than in the Cold Standby configuration.

Active/Active (RW/RO)

All MDM servers are started on all cluster nodes, with one server running in the read-write mode and all other in the read-only mode. If the read-write server fails, the next request is re-routed to a different MDM server which has been automatically switched from read-only to read-write mode. Unlike Active/Passive modes, the Active/Active mode enables (in addition to HA) horizontal scalability of MDM RO services.

Supported HA Services

MDM provides many services to its consumers, primarily lookup, match & merge, and validation services. Services can be recognized as stateful and stateless. Currently, it is not possible to run stateful services on several cluster nodes simultaneously. Stateless services can be run on all servers on the cluster, and hence can be scaled horizontally. A list of main services is provided in the table below.

Service Server in R/O Mode Server in R/W Mode Service Description




Obtaining all attributes of a given entity by the primary key.




Setting attributes for a given entity by the primary key.




Searching for a given entry by an attribute.




Identifying an entry of a given entity by a set of attributes.

DQ Firewall



Validating input attributes by lookup entries or rules.




Matching an entry with other entries in the group.




Merging an entry with other entries in the group.

Event Handler



Interface to 3rd-party systems.

Full Export



Full export of all entries regardless of the previous export.

Delta Export



Delta export of entries since the last export.

Architecture and Components

In the sample architecture below, load balancing capabilities need to be provided by the existing infrastructure.

High availability architecture

MDM Cluster

The MDM cluster contains MDM servers, one running in the RW mode, while all others run in the RO mode.

MDM Web App Cluster

MDM Web App can benefit from HA Web App servers set up to be able to share a session ID among the nodes. There can also be a mechanism where a router is capable of remembering a user session ID and route the requests accordingly to the same MDM Web App node. Or combination of above mentioned. VLDB persistence is highly recommended for HA setup.

Zookeeper Cluster

MDM relies on Zookeepeer for its high availability setup, using it to maintain the information on which MDM instance (node) is active (RW). Since only one MDM node is supposed to operate in the Read-Write (RW) mode, this information is crucial in preventing multiple RW nodes and corrupting the shared master repository.

The Zookeeper cluster consists of at least 3 nodes, which communicate with each other. MDM nodes are in constant contact with the Zookeeper cluster via the High Availability Component.

Load Balancer/Virtual IP

The traffic coming from source and consuming applications or systems relies on an existing loading balancing/routing layer.


MDM uses one of the supported relational database for data persistence. To run MDM in high availability mode, all underlying infrastructure components must be also set up in HA mode, including the database. The procedure to set the database up in high availability mode is platform specific. Please refer to the vendor documentation for the respective database technology to set your database up in HA mode.


MDM uses Keycloak service for authentication and authorization. The Keycloak service itself needs to be set up in high availability mode as well.

Shared Storage

The MDM server uses a specific storage area to temporarily store runtime information as well as persistent data structures (for example lookups, input/output files) to the disk. If you set up your cluster in Active/Active mode, this area must reside on a shared storage which can be accessed by all nodes of the cluster. To support the high availability setup, the storage infrastructure providing the shared storage area must be also set up in high availability mode.


In the case of WS composition and orchestration using a EAI platform (ESB), that platform has to be operating in HA mode as well. The same applies to messaging and/or data streaming middleware providing online data input and consuming data output to/from MDM.

Was this page useful?