This might be a dumb question but I didn't see anything about it in the Mirroring documentation. Are processes that are currently running when the primary fails over to the secondary automatically switched over and continue processing? Or are they terminated and would need to be restarted on the secondary?
I have a pair of servers configured as a mirror, each server sits in a separate data centre.
I have noticed that occasionally, the primary will report that the backup is disconnected in the Mirror Monitor, and I believe this to be due to connection conditions between the two data centres.
I have a DR member and in this cache server the database "cachetemp" start to getting bigger without any reason (50GB that was all the free disk space we have)
In the members of the mirrors the cachetemp its ok and the size is 31MB.
I restarted the server because I read that the cachetemp database purge when restarting, but didnt happend.
Any recommendation to clean this database? can I just deleate the CACHE.DAT from this database?
Our mirrored HealthShare environment has failed over a few times recently due to underlying infrastructure issues (that are being worked on and resolved).
In the HealthShare logs we are seeing:
10/06/22-00:54:35:925 (4736) 1 Journal Daemon has been inactive with I/O pending for 10 seconds: gjrnoff=524741316,iocomplete=523852600,filecnt=1011,fail=0 10/06/22-00:54:55:086 (4736) 3 CP: Pausing users because Journal Daemon has not shown signs of activity for 30 seconds. Users will resume if Journal Daemon is active again
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...
Mirroring provides an admin capability to Stop Mirroring on this member, which causes a non-primary member to temporarily disconnect from the primary, stop dejournaling, etc. While most system administrators may never need or use this function, some employ it for certain kinds of maintenance or other special cases.
A common need for our customers is to configure both HealthShare HealthConnect and IRIS in high availability mode.
It's common for other integration engines on the market to be advertised as having "high availability" configurations, but that's not really true. In general, these solutions work with external databases and therefore, if these are not configured in high availability, when a database crash occurs or the connection to it is lost, the entire integration tool it becomes unusable.
This article provides a reference architecture as a sample for providing robust performing and highly available applications based on InterSystems Technologies that are applicable to Caché, Ensemble, HealthShare, TrakCare, and associated embedded technologies such as DeepSee, iKnow, Zen and Zen Mojo.
Azure has two different deployment models for creating and working with resources: Azure Classic and Azure Resource Manager. The information detailed in this article is based on the Azure Resource Manager model (ARM).
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.
Is it possible to make the cache terminal available over a mirrored vip address for a healthshare mirrored environment? So that connecting to a terminal for a mirrored environment will always connect to the Live Node?
I'm looking to write a Powershell script to run against the system and need to connect to the Live Node in a mirrored setup. Is this possible or am I going to have to log onto each node to establish which is Live. Or does this even matter?
I'm trying to add a DR async member to a mirror but when I add this member I get this messages in the mirror monitor (on the DR member):
The message im talking about is the "missing Mirrored Databases report".
The only step I did was the " System Administration -> Configuration -> Mirror Settings -> Join as Async" an fill the blanks. Maybe Im skipping a step?
In this post, I am going to detail how to set up a mirror using SSL, including generating the certificates and keys via the Public Key Infrastructure built in to InterSystems IRIS Data Platform. I did a similar post in the past for Caché, so feel free to check that out here if you are not running InterSystems IRIS. Much like the original, the goal of this is to take you from new installations to a working mirror with SSL, including a primary, backup, and DR async member, along with a mirrored database. I will not go into security recommendations or restricting access to the files. This is meant to just simply get a mirror up and running. Example screenshots are taken on a 2018.1.1 version of IRIS, so yours may look slightly different.
I asked previously about the DR server in the cloud but actually, I'm curious about the backup server to use as analytics server more than for recovery in DR case.
There is a recommended practice to use an async mirror as a server for BI (InterSystems Analytics, DeepSee)
The question is if I have PRIMARY in the cloud (AWS, Google, Azure, etc) "how far" should async mirror member be placed? Same cloud, same private cloud or it doesn't matter at all for analytics purposes?
I am working on setting up our Failover techniques as we move to a Mirror Environment with a Arbiter, 2 Failover Nodes, and a Async (DR) Node. There are some system commands that I would like to call when the Mirror moves, and I am working on a ZMIRROR routine for that, but I also wanted to create an additional step if we wanted to manually shutdown and for the Mirror to move. So I was looking at using ZSTOP to call a couple of different items while shutting down, while the documentation has an example a couple of questions come to mind about using ZSTOP.
When I log into Backup mirror member it becomes too slow to load and navigate, I tried to check message log and I saw the error message about Database mirror latency and database disk issue which when I check it looks fine to me. Please have a look at the below screenshots and advise what the issue could be.
When I run df -h through SSH :
200G is the volume size, 194G is used space, 6.5G is available space and 97% IS %Use
I have a DR Mirror with a WIJ that is 5 times as large as the Primary Failover member. My Read-Write Reporting mirror WIJs are the same size as the Primary. I don't know why the DR WIJ i so large and would like to shrink it to the same size as the others. Any suggestions are welcome. Thanks!
In the context of IKO (Iris Kubernetes Operator) the question of Service not redirecting dynamically to the correct Pod is still pending. In production this can be dangerous since an overload (or any other simpler problem) can cause you to change the main Pod and leave the application inoperable until we intervene.
Intersystems support warned that this is still an issue of IKO, but there are some possibilities that I am studying.
To explore an idea I had, I would like the help of this Forum to answer the following question:
I have Ensemble/Healthshare running in a production environment which is setup with a mirror failover and an arbiter sitting between them.
In the event of a failover we have a number of connections that need stopping/monitoring and starting in a certain order.
Is there a programmatic way we can detect the failover and stop certain services and operations immediately and then start them up again in the required order, checking their connection state before starting the next connection.
By replies
Open Exchange app.png)
.png)