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.
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...
Can a Cache Mirror be used in the cloud ? (ie stand up a Primary and Backup member instances in a High Availability Cache Mirroring configuration)
I'm investigating the validity of this configuration, because I was of the understanding that this may not possible due to these cloud servers not (typically) having fixed ip addresses, which interferes with the Virtual IP settings for the mirror set.
Is this correct, and if there are workarounds (like Load Balancing ?) can I have details on how this should be configured ?
Good day!
Is there an opportunity to debug the ISCAgent behaviour (in Linux)? ISCAgent uses /etc/iscagent/iscagent.conf as configuration file, but in docs I've found a description only for two parameters (port number and interface - http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...). Other parameters I can see by running /usr/local/etc/cachesys/ISCAgentCtrl status:
MIRROR is the best solution for almost immediate replications to a Failover Server. The related mechanics are based on Global Journaling.
Globals hold Data and Classes and Routines and more ... If Mirroring is in place all is in sync. With minimum delays This is of course rather useful for code changes in Classes, Routines, ....
To what extent is Embedded Python covered by Mirroring? Or: What is required to Synchronize EmbeddedPython like Mirroring.
Hi, we have mirrored databases, now we have three nodes. Primary, backup, async. They are sync by journals and with some TB each node (expensive storage).
I would like to have a scenario where the two nodes (Primary and backup) have the same amount of messages (purge task of x days) , both as failover, but the asynchronous node should have more messaging, as much as the storage allows us. We want to use this node so provider can give support(search old messages), but not have databases in production that are so large that they are hardly consulted.
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 work on deploying IRIS inside Docker container. I really like %Installer class can automate many steps. I want to establish an ECP connection to a mirror database and then define a remote database on the application server. I have already seen we can create local database and namespace in %Installer. What code is needed to establish ECP connection?
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?
I have a Read-Only Reporting Async with a Remote Database defined to a non-mirrored database on the primary failover member. I would like to update the non-mirrored database on the primary from the async; so far all my attempts fail with *protect* errors.
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 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 have noticed that my backup mirror is warning that the MirrorDatabaseLatencyTime is having a bad time (time in ms is 3000, and warnvalue is 3000). While I look into what may be causing this latency between the two servers, I was considering if reducing the size of the journal files would improve this value in any way.
My assumption is that reducing the file size would mean that the frequency of the journal files being created would be increased, but the reduced size would mean that the transfer and application of each file would be reduced.
Hi, I updated the schema on our live node, but the change did not occur on the mirror server. Is there some setting that I need to enable? Everything else seems to be updating but the schema has not
Can you advice on what I could be missing or is this something that is known?
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:
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
Does anyone have experience with installing the Arbiter Container using Podman instead of Docker in a Red Hat environment? I was able to pull down the docker image, but unsure what are the next steps as I am confused on how to start the container using Podman and ensure the parameters are set appropriately? Does anyone have the steps that I should take? Should I go through the WRC? Does the WRC have experience using Podman?
Or should I just install the ISC Agent instead of using the Container?
I'm using $ZUTIL(49) to get information of the databases I want to add to a mirror. This information is passed to ##class(SYS.Mirror).CatchupDB(plstPathDatabases) in order to Catchup all databases addes to a Mirror.
By likes