Advanced Clustering
If cloud deployment, high availability, or improved message throughput is a goal, multiple Mirth Connect instances can be deployed with a single, shared database (Postgres, SQL Server, Oracle, MySQL or Amazon Aurora). This allows channel configurations and message history to persist in a separate shared location as nodes may be removed or added to the cluster.
This deployment strategy does not require a separate plugin and can be accomplished using the open-source distribution of Mirth Connect. However with the open-source distribution alone, there are several limitations from an administrative standpoint.
The Advanced Clustering plugin is designed to ease the management of a clustered deployment. Without the plugin, you will need to log into each node separately to deploy/start/stop channels or monitor server error messages. Channel deployment states are maintained in-memory on each server, not in the shared database. Furthermore, whenever a node in the cluster fails, any partially processed or queued messages will need to be manually reassigned to a new node in order to resume processing. The primary goal of the plugin is to automate the addition of new nodes as well as the recovery of failed nodes and enable the Administrator UI to act as a single user interface for a cluster of Mirth Connect instances.
From the Mirth Connect dashboard, the Advanced Clustering plugin allows you to:
- Monitor the status of each server
- Deploy/start/stop/pause channels across all servers at once
- View message statistics totals for the entire cluster, or statistics for a particular server
- View any errors that occurred across the cluster while deploying/starting/stopping channels
- Automate the recovery of a failed node - A healthy node in the cluster will automatically resuming processing of any queued or unfinished messages from the failed node.
- Automate the addition of new node(s) - When joining the cluster, a new node will automatically deploy and start channels to match the state they currently have on the other node(s), eliminating any manual steps needed to ensure consistency across the cluster.
- Automatically coordinate polling connector execution (File Reader, Database Reader, JavaScript Reader) - Connectors that poll for messages will only execute on a single node in the cluster, preventing duplicate messages from being processed. If that node fails for any reason, a healthy node will automatically take over polling execution.
- Automatically coordinate data pruner execution - Ensures that only one node will execute the Data Pruner, eliminating unnecessary strain on the shared database.
- It does not provide load balancing or manage a load balancer. You will need to configure a load balancer separately, whether in a cloud environment or on-prem deployment.
- It does not eliminate the database as a single-point-of-failure (or as a performance bottleneck). It is recommended that you supply a shared database that is also highly available.
- It does not (yet) support no-downtime version upgrades using blue-green deployment. If this is a requirement, please let us know at mirthconnectsales@nextgen.com to help get this prioritized for addition in a future version :)
Contact mirthconnectsales@nextgen.com for more information.