#Mirroring

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. Enter the Password for your predefined HS_Services user (on backup and primary)

Step 3: Schedule the Mirror

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.

Unfortunately the built-in storage classes in most Kubernetes implementations (whether cloud or on-prem) do not provide this capability:

• Does not support access mode "ReadWriteMany"
• Does not support being mounted on more than one pod at a time
• Does not support access across availability zones

However, some Kubernetes add-ons (both provider and

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.

Unfortunately the built-in storage classes in most Kubernetes implementations (whether cloud or on-prem) do not provide this capability:

• Does not support access mode "ReadWriteMany"
• Does not support being mounted on more than one pod at a time
• Does not support access across availability zones

However, some Kubernetes add-ons (both provider and

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.

Unfortunately the built-in storage classes in most Kubernetes implementations (whether cloud or on-prem) do not provide this capability:

• Does not support access mode "ReadWriteMany"
• Does not support being mounted on more than one pod at a time
• Does not support access across availability zones

However, some Kubernetes add-ons (both provider and

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.

IRISsync eliminates that risk by

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.       Security Enhancements with the New IRISSECURITY

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.  However I was surprised to find that IRIS is in several ways quite unlike other databases, often much better.  With this, my first article in the Dev Community, I'll give a high-level overview of IRIS for people that are already familiar with the other databases such as Oracle, SQL Server, Snowflake, PostgeSQL, etc.   I hope I can make things clearer and simpler for you and save you some time getting started.

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. 

There is a Namespace/Database that is on the backup and not part of the mirror,

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. 

However, our challenge extended beyond the initial cluster and application deployment; we needed to establish an efficient and

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.

IRIS backup

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.

The procedure is as follows (execute in the %SYS namespace):

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.

The SYS.Mirror CatchupDB() method requires a System File Number/Inode value as a parameter.   I have not yet found a suitable internal method to get this value.  Is anyone aware of a utility method that would do this?   I do know I can get this value with a small amount of Python or by calling out to the OS.  However I wanted to stick with pure Objectscript in this project if possible.  

Failing in this I will use embedded python to run the line or two of Python needed to get this value.

Thank you for any hints

ISCAgent is automatically installed with Cache, runs as a service and can be configured to
start with the system. This is fine – but the complication comes when this is on VCS clusters with
Mirroring on. When installing a Single Instance of Cache in a Cluster, point number 2. Says “Create
a link from /usr/local/etc/cachesys to the shared disk. This forces the Caché registry and all
supporting files to be stored on the shared disk resource you have configured as part of the
service group.”
So on the second passive node – this statement makes ISCAgent startup with the system, nor manually
starting it

Hi! I am planning to move my Arbiter from a Unix server to a container(again on linux). To do this, I need the ISCAgent tar.gz file to configure Arbiter for our mirrored servers. I have tried searching for it on the Intersystems help forums but couldn't find it. Is it possible for someone to redirect me to the correct website to download it?

Thank you in advance!!

I had a question about using ZSTART, ZSTOP, and ZMIRROR.

• If we use them and it is not correct, does it mess up with any of the existing functionality?
• So, if I create a ZSTART with a simple command of starting the %JDBC Server will that mess up anything existing in the Startup sequence?
• Is ZSTART, ZSTOP, and ZMIRROR just an extension of the existing functionality, or does it alter how the built in functionality runs?
• Should we tread lightly in the use of them?

If you're running IRIS in a mirrored configuration for HA in Azure, 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 Azure, 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 Azure as subnets can span several zones). 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 the using Load Balancers suggested in most other Azure reference architectures.