Mirth Connect High Availability Setup: Clustering, Failover & Zero Downtime

Part of our complete guide to Mirth Connect - Complete Guide for Healthcare Leaders.

High availability (HA) is essential for modern healthcare systems. When Mirth Connect goes down, clinical workflows stop, alerts fail, and patient safety is at risk. Since Mirth Connect often handles HL7, FHIR, DICOM, XML, and other healthcare messages, ensuring a zero-downtime, fault-tolerant setup is critical.

This guide explains how to design and implement a complete HA architecture for Mirth Connect including database clustering, load balancing, shared storage, session management, failover testing, and long-term maintenance.

Why High Availability Matters in Healthcare

Mirth Connect is the backbone of many interoperability workflows. When it goes offline:

• Clinical workflows are delayed
• Critical alerts fail to trigger
• Duplicate or lost patient data increases risk
• HIPAA compliance issues arise
• Financial losses occur due to downtime

Healthcare systems typically aim for 99.99% uptime, equal to less than one hour of downtime per year.

Understanding HA Requirements — RTO and RPO

Before designing the architecture, define your business expectations:

• RTO (Recovery Time Objective): Maximum acceptable downtime
• RPO (Recovery Point Objective): Maximum acceptable data loss

Typical healthcare requirements:

• RTO: 5 - 30 minutes
• RPO: 0- 5 minutes

These values directly shape your HA design, especially database clustering and failover mechanisms.

High Availability Architecture Overview

A single-server Mirth setup has multiple failure points: application crashes, hardware failures, network issues, or database downtime.

A proper HA design removes these risks with layered redundancy:

• Load Balancer Cluster: HAProxy or NGINX
• Multiple Mirth Instances: active or passive
• Clustered Database: PostgreSQL + Patroni or MySQL Galera
• Shared Storage: NFS or GlusterFS
• Redundant Networking: VLANs, redundant switches, dual NICs

A front-end load balancer distributes traffic across active Mirth nodes. This ensures that clients connect through a virtual service or VIP rather than directly to individual nodes. 

The load balancer can use Layer 4 or Layer 7 methods. Layer 7 Reverse Proxy is the recommended method for Mirth Connect thanks to its high performance and implementation flexibility. 

Note that certain behaviors, such as header insertion or transparency, may not be active by default and require specific configuration. A load balancer gives Mirth Connect high availability by directing traffic only to healthy nodes. Load balancing also helps handle increased traffic and improves response times for healthcare applications. 

Mirth Connect's architecture supports various load-balancing configurations to meet different deployment needs.

This ensures no single failure can stop message processing.

Prerequisites and Planning

Hardware Requirements

• Mirth Servers: 4 - 8 vCPU, 8 - 16 GB RAM
• Database Nodes: 8- 32 vCPU, 16 - 32 GB RAM
• Load Balancers: 2 nodes minimum
• Shared Storage: RAID 10 SSD/NVMe

Software Requirements

• Linux (RHEL, CentOS, Ubuntu)
• Java 11+
• Mirth Connect 4.0+
• PostgreSQL 12+ or MySQL 8.0+
• HAProxy 2.0+ or NGINX

Network Requirements

• 1 Gbps internal bandwidth
• < 5 ms latency to the database
• Correct DNS + clock synchronization across all server nodes using NTP is essential to prevent database conflicts and reduce waiting times in data processing. This ensures minimal latency and seamless interoperability
• Open ports for Mirth, DB, HAProxy

Setting Up the Database Cluster

Implementing Mirth Connect for high availability involves clustering multiple Mirth Connect instances to share a single database, which eliminates single points of failure. A clustered database is mandatory, because Mirth stores:

• Channels
• Metadata
• Message logs
• User sessions

The recommended method for ensuring high availability is to use a clustered database configuration that includes replication and automatic failover. PostgreSQL is recommended as a highly available database for Mirth Connect, though Oracle, SQL Server, and MySQL are also supported. 

This approach ensures data integrity and reliable failover, which are critical for maintaining continuous operations in healthcare environments.

Option 1 — PostgreSQL + Patroni

• Automatic failover
• Synchronous replication
• Quorum and split-brain protection

Option 2 — MySQL/MariaDB Galera Cluster

• Synchronous multi-master replication
• High write throughput
• Automatic cluster recovery

Connection pooling must be enabled in Mirth to prevent DB overload.

Load Balancer Configuration

Use HAProxy or NGINX to distribute traffic and ensure high availability. A Layer 7 Reverse Proxy is recommended to handle SSL termination and manage X-Forwarded-For headers for Mirth Connect. This ensures accurate client IP recognition and secure connections.

Key responsibilities:

• Routing incoming traffic across nodes
• Health checking Mirth instances
• SSL termination
• Failover handling
• Session stickiness when required

The load balancer should be configured to log client IP addresses and health checks for monitoring and security. Configuration files can be downloaded via API or scripts for backup and migration purposes, supporting automation and disaster recovery. If a primary node fails, a secondary node can automatically take over the Virtual IP and resume processing queued messages through a heartbeat mechanism.

Correct health checks ensure nodes are only used when fully healthy.

Mirth Connect HA Node Configuration

Each node must have identical configurations except for node IDs.

Critical settings:

• Cluster mode enabled
• Database sessions activated
• Centralized logs
• Consistent channel deployment
• Cache synchronization scripts

If you are achieving high availability without the Advanced Clustering plugin, more manual configuration is required. For example, you need to disable auto-start for polling channels on each node to prevent duplicate processing.

Tools like Ansible should manage configuration consistency across nodes.

Shared Storage Configuration

Shared storage is required for:

• Logs
• Channel exports
• Certificates
• Custom libraries

Secure access to shared storage and credentials is essential for automation and seamless data exchange. This ensures that only authorized systems and users can retrieve or integrate sensitive healthcare data.

Common options:

• NFS Server
• GlusterFS Cluster (replicated)

Use an SSD or NVMe for improved throughput and reduced latency.

Session and State Management

For proper failover:

• Enable database-backed sessions
• Synchronize caches periodically
• Use idempotent channel logic to avoid duplicate processing
• Store critical queues in the database

This ensures users remain authenticated and messages are not reprocessed after a failover.

NextGen Healthcare Integration

NextGen Healthcare Integration, powered by NextGen Connect, delivers a proven architecture for healthcare organizations seeking high availability, scalability, and seamless interoperability. 

The architecture processes hundreds of millions of clinical documents annually. It supports mission-critical workflows that demand zero downtime and reliable message processing. The platform's high availability features are backed by ongoing support from the NextGen Healthcare team and a vibrant open-source community. Healthcare organizations can depend on continuous improvements, security verification, and rapid response to evolving industry needs. 

Recent licensing changes have shifted the landscape for the free version. Even so, the commitment to community-driven development and enterprise-grade support means NextGen Connect remains a cornerstone for secure, scalable healthcare integration. 

This ongoing collaboration helps organizations meet growing demands for secure data exchange, regulatory compliance, and resilient system performance.

Configuration Best Practices

• Use connection pooling
• Set correct timeouts (HTTP + DB)
• Use retry & backoff strategies
• Implement circuit breakers
• Isolate instance-specific directories

These prevent cascading failures and ensure stable HA behavior.

Common Pitfalls and How to Avoid Them

• Split brain: Fix with proper quorum (Patroni/Galera)
• DB connection exhaustion: Enforce pooling & connection limits
• File locking issues: Separate instance-specific directories
• Version mismatch: Use automation (Ansible, CI/CD)
• Configuration drift: Validate config checksums

Testing and Validation

Perform structured testing:

• Failover test (shutdown one node)
• Database failover simulation
• Network partition testing
• Load testing (JMeter)
• End-to-end message testing

Automated test suites should run after each deployment.

Monitoring and Maintenance

Monitor:

• Mirth node health
• Database replication lag
• Error rates
• Message throughput
• Load balancer status

Use tools like Prometheus, Alertmanager, and ELK for visibility.

Maintenance tasks:

• Daily health checks
• Weekly DB maintenance
• Monthly failover drills
• Regular certificate rotation

Conclusion

Mirth Connect HA requires much more than running multiple servers. Proper planning, database clustering, load balancing, shared storage, synchronized configuration, and continuous testing all contribute to a reliable HA environment.

With the right architecture, healthcare organizations can achieve:

• Zero-downtime failover
• Consistent message processing
• Audit-ready compliance
• Resilience against hardware and network faults

A well-architected Mirth HA setup ensures safe, uninterrupted patient data flow across the entire healthcare ecosystem. Thousands of clients and organizations account for Mirth Connect's widespread adoption, supported by active forums and a dedicated website for resources and support.