#Mirroring

Background

For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.

Are you familiar with SQL databases, but not familiar with IRIS?  Then read on...

About a year ago I joined InterSystems, and that is how IRIS got on my radar.  I've been using databases for over 40 years—much of that time for database vendors—and assumed IRIS would be largely the same as the other databases I knew.

Enabling HSSYS Mirroring Out of the Gate with IKO

For those of us building InterSystems workloads on Kubernetes, we are definitely spoiled with the InterSystems Kubernetes Operator (IKO) doing the heavy lifting and mirroring on day one.  Where us spoiled brats jump up and down is when we try to add additional databases/namespaces when we provision from HealthConnect containers on day two, while others get to utilize HealthShare Mirroring for this task, the prerequisite of mirroring HSSYS out of the gate has been somewhat elusive.  Here is example on how you can this powerful feature up and running with the employment of IKO and IrisClusters.

Hi, Community!

Ready to strengthen your deployment of InterSystems IRIS® data platform?

👨‍💻See how to configure a mirrored pair to preserve the integrity of your data:

Setting Up a Mirrored Pair with Configuration Merge

Hi, Community!

Are you looking for ways to strengthen your InterSystems IRIS® data platform deployment? See how mirroring can help:

Architecting for Success with Mirroring

You may have noticed that to configure a mirror for InterSystems IRIS for Health™ and HealthShare® Health Connect there is a special requirement. I wanted to go through it step by step in this article.

This assumes you have already configured the second failover member and confirmed a successful failover member status in the mirror monitor:

Step 1: Enable HS_Services user (on backup and primary) 

Step 2: Switch to Namespace HSSYS and go to Interoperability > Configure > Credentials.

Mirror Your Database Across the Galaxy with Seeding

Hello cpf fans!  This distraction I used the "seed" capability in IRIS to provision an entire IrisCluster mirror, 4 maps wide with compute starting from an IRIS.DAT in a galaxy far far away.  This is pretty powerful if you have had a great deal of success with a solution running on a monolithic implementation and want it to scale to the outer rim with Kubernetes and the InterSystems Kubernetes Operator.  Even though my midichlorian count is admittely low, I have seen some hardcore CACHE hackers shovel around DATS, compact and shrink and update their ZROUTINES, so this same approach could also be helpful shrinking and securing your containerized workload too.  If you squint and feel all living things around you,  you can see a glimpse of in place (logical) mirroring in the future as a function of the operator and a migration path to a fully operational mirrored Death Star as the workload matures.

Background

For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.

A step by step implementation path to a cross regional stretched IrisCluster with Mirroring using the Intersystems Kubernetes Operator (IKO), Google Cloud Platform, and Tailscale.

I am giving this distraction the code name "Compliment Sandwich" for a reason yet to be realized, but I'd rather the community go right for the jugular shooting holes in a solution that implements wireguard based connectivity for our workloads in general, as I would like to refine it as a fall project leading up to KubeCon in Atlanta and if I miss the mark, Ill get it done before Amsterdam. 

Another step in this implementation path, adding cross cloud, cross regional stretched IrisCluster with Mirroring + Disaster Recovery using the Intersystems Kubernetes Operator (IKO) and Tailscale

Though trivial, Id like to go multi-cloud with the stretched IrisCluster for a couple of reasons to socialize the power of Wireguard when it supplies the network for a properly zoned IrisCluster by adding another mirror role to Amazon Web Services in the Western United States based datacenter in Oregon.

Background

For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.

Following on from JediSoft’s announcement of the general availability of JediSoft IRISsync®, I wanted to show how it can help prevent configuration drift and ensure your failover is always ready. 

When managing InterSystems IRIS production servers, even a minor configuration change can cause significant issues if it’s not replicated in your mirror environments. Often, these differences go unnoticed until your failover environment breaks.

This common, but critical, problem can lead to unexpected downtime at a vital moment and impact your business continuity.

We are excited to announce the general availability of JediSoft IRISsync®, our new synchronization and comparison solution built on InterSystems IRIS technology.  IRISsync makes it easy to synchronize and compare IRIS instances.

IRISsync was voted runner-up in the "Most Likely to Use" category at InterSystems READY 2025 Demos and Drinks.

A huge thanks to everyone who supported us — we’re thrilled to see IRISsync resonating with the InterSystems user community!

IRISsync provides clear visibility into differences between environments.

Hi all,

Just wondering if anyone has any experience with licensing in an HA mirroring environment. We have mirror setup with 2 DB servers (Primary and Backup), and a separate Arbiter using ISCAgent. We currently don't have a license server setup so users using our web app get interruptions and have to log in again if failover occurs. 

We have also see some spurious licensing issues when failover occurs and users are logging back in. So we were wondering if using a separate License server (possibly hosted on the Arbiter machine) would help alleviate these licensing issues?

InterSystems is pleased to announce the General Availability (GA) of the 2025.2 release of InterSystems IRIS® data platform. This is a Continuous Delivery (CD) release. Please note that the GA versions of InterSystems IRIS® for Health and HealthShare® Health Connect™ 2025.2 are currently withheld due to mirroring limitations introduced by security updates (details below).

Release Highlights

This release introduces impactful enhancements across security, developer experience, operations, and interoperability. Notable new features include:

1.

I am attempting to failover my TEST environment to the Backup, and I keep getting an error stating that 

06/01/25-18:47:54:516 (11864) 1 [Utility.Event] Primary startup failed, failed to read header of /archive/journal/MIRROR-IRISTEST-20250513.007 (file #63653)

however, when I go to /archive/journal/, I am not finding any record of MIRROR-IRISTEST-20250513.007 (file #63653)

to get out of this error message I have to restart what was the Primary and restart the Backup to get it back into a state that we can use it.

Hello,

We had a weird behavior of task manager in mirror async backup-failover pair:

1. server 1 was primary, server 2 backup for over a month, as there was no automatic failover (switch) both had IRIS up for over a month
2. We manually switched making server 2 primary
3. The tasks that had this issue were set to "run on Primary only"
4. Task manager started to execute tasks every minute: we noticed that "Next scheduled time" is always calculated in past date, and progressing by the task interval (e.g. a task that supposed to run every hour will have "Next scheduled time" in the past e.g.

Migrating InterSystems IRIS and InterSystems IRIS for Health from on-premises to the cloud offers many advantages for Application Providers and Solution Providers. These advantages include simplified operations, access to flexible resources, and enhanced resilience. Companies no longer need to worry about the physical constraints and expenses associated with maintaining on-prem infrastructure, such as power and space requirements and expensive computer hardware.

One of the most compelling benefits is the ability to accelerate speed to market. By removing the burden of infrastructure maintenance, cloud environments enable faster development and deployment cycles, allowing businesses to respond quickly to market demands and opportunities. Operational costs are also lowered, because companies can scale resources up or down based on actual needs, leading to more efficient use of capital. Moreover, migrating to the cloud can contribute to a reduced carbon footprint by optimizing energy usage through shared cloud infrastructure.

Transitioning to the cloud may involve significant changes. Companies may benefit from a more operational focus, managing and optimizing cloud resources continuously. This shift may require changes to business models, reconsideration of margins, and strategies for scaling operations up or out. While requiring more investment, embracing these changes can lead to improved agility and competitive advantage in the marketplace.

As an IT and cloud team manager with 18 years of experience with InterSystems technologies, I recently led our team in the transformation of our traditional on-premises ERP system to a cloud-based solution. We embarked on deploying InterSystems IRIS within a Kubernetes environment on AWS EKS, aiming to achieve a scalable, performant, and secure system. Central to this endeavor was the utilization of the AWS Application Load Balancer (ALB) as our ingress controller.

Hi, this post was initially written for Caché. In June 2023, I finally updated it for IRIS. If you are revisiting the post since then, the only real change is substituting Caché for IRIS! I also updated the links for IRIS documentation and fixed a few typos and grammatical errors. Enjoy :)

In this post, I show strategies for backing up InterSystems IRIS using External Backup with examples of integrating with snapshot-based solutions. Most solutions I see today are deployed on Linux on VMware, so a lot of the post shows how solutions integrate VMware snapshot technology as examples.

If you're running IRIS in a mirrored configuration for HA in GCP, the question of providing a Mirror VIP (Virtual IP) becomes relevant. Virtual IP offers a way for downstream systems to interact with IRIS using one IP address. Even when a failover happens, downstream systems can reconnect to the same IP address and continue working.

The main issue, when deploying to GCP, is that an IRIS VIP has a requirement of IRIS being essentially a network admin, per the docs.

To get HA, IRIS mirror members must be deployed to different availability zones in one subnet (which is possible in GCP as subnets always span the entire region). One of the solutions might be load balancers, but they, of course, cost extra, and you need to administrate them.

In this article, I would like to provide a way to configure a Mirror VIP without using Load Balancers suggested in most other GCP reference architectures.

Is it possible to use one IIS server to configure Webgateway and external Webserver for management portal when implementing synchronous mirroring with VIP  i.e Is it necessary to have two mirror servers(primary and Backup) , one Arbiter server, one Webserver for Webgateway and a sperate webserver for management portal? 

If anyone can please point to any documentation on Mirroring with Webgateway and external webserver for management portal will be really helpful. 

Thank you for your help

Hi Experts Can you advise how to setup a nic for VIP ?

Can you confirm that using this command is the correct

ip addr add *.*.*.*/2 dev nic?

then configure the VirtualAddressInterface in iris.cpf

restart and end enable in the smp?

thank you in advance

InterSystems FAQ rubric

If you do not specify the option to remove the mirror attribute of the mirror database when deleting the mirror configuration, the database cannot be restored to a normal state and will be mounted read-only the next time it is mounted. To restore the database to a read-write state, you must remove the mirror attribute using the system routine ^MIRROR.

I want to use ^Mirror routine to configure mirroring. Can someone please tell what classes and methods I need to use with syntax for configuring the mirroring please OR please point me to any tutorial where ^Mirror routine is used to configure mirror.