#Mirroring

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.

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.

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.”

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.

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.

Has anyone noticed that when IRIS is forced down that the EnsLib.JavaGateway.Services do not properly shut down and release the ports? While we can write a shell script to kill the processes at the OS level, I was wondering if anyone experienced this issue.

We are working on our Mirroring setup/failover and had the team testing forcing the Primary down to make the Backup to become the Primary Server. When this happened and we failed back, IRIS could not restart the JavaGateway.Services because the ports were still in use.

We recently went through an Audit of our Security Policies and Procedures when it comes to IRIS. As a result of that Audit, we need to make adjustments to the way that Security is setup within IRIS. I have already done my changes on our TEST and DEVELOPMENT environments, but now I am trying to plan out how do we make these changes in Production.

These changes include moving away from the PWS, setting up Apache/Web Gateway, moving to LDAP instead of using Delegated Authentication, updating Web Applications, updating Resources, updating Services, etc...

I am trying to work on a ZMIRROR that will execute a shell script to failover our VIP at the hardware level when NotifyBecomePrimary occurs.

We recently published a new White Paper on the use of reporting nodes ("asynchronous reporting mirror members" in full) in a mirrored environment. More and more customers are looking into this mechanism as a quick and easy way to set up a copy of their production data that stays current, yet can be used for analytical querying or heavy-duty reporting workloads without impacting the source system. Read the White Paper here.

It appears to be working correctly, mirroring data etc. but the status on the Primary Cache DB is showing the wrong status for the DR DB.

re-configured Cache Mirroring BUt still have the same issue afterwards.

The GUI display remains the same regardless.

From primary Cache portal

Hi All! You may be interested to hear we've just released a new podcast episode all about mirroring, featuring conversations with @Chad Severtson from InterSystems and Greg King from J2. Take a listen and chime in on the conversation here if you have thoughts!

https://5e18edf067eb59-03854285.castos.com/player/1573650
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]

Hello Everyone,

We currently have CSP application that runs under 2 servers(usually primary), and every month the server reboots for patching SERVER1(primary) in the morning and SERVER2(backup) at night.

Whenever the SERVER1 reboots SERVER2 behaves as primary and when SERVER1 comes back up it will act as backup server.

First Patching:

So, when SERVER1 is down, I need to start httpd service for SERVER2 and stop httpd service for SERVER1 (which is now backup server).

With the world (as well as our own technology) moving to the cloud at such a fast pace it is easy (at least for myself) to get caught up in the little details. One thing I, and some clients of ours, had run into a couple of times was the necessity to specify the version of the images one plans to use with the IKO.

I'm trying to create a simple mirror with two Cachés 2016.2.1.803 Instances,

but after i create the mirror with the primary and try to connect the fallouver server, i receive the following message:

ERRO #2071: Erro ao recuperar informações do conjunto espelho para 'BPLUS'. Erro: Connection failed: Unexpected error: <READ>SSLServer+191^MIRRORCTL

i'm not using ssl on this configuration, tried with arbiter and without, same effect.

Tried with Caché 2018.1 and Caché 2016.2.1, same problem.

Some tips?

Best,