Written by

Enterprise Application Development Consultant at The Ohio State University Wexner Medical Center
MOD
Question Scott Roth · 4 hr ago

Code not always updated in Mirror?

This past weekend we ran into something odd. When we failed over our mirror from 2022.1.3 to 2025.1.3 the one of the Business Rules that was on what became the Primary (2025.1.3), had a rule within it that was removed back in January. When the Failover occurred, we had to scramble to backup, disable, and remove the Rule that shouldn't have been there. 

Both the Data and Code live within the same IRIS.dat that is the main MIRROR database for that Namespace. 

If this happened to one Class file, could it happen to others we do not know about? Seeing that I ran CompileAllNamespace, it is kind of hard to track down based on compiled date.

Has anyone had this issue before? Have you been able to track down the culprit?

Product version: IRIS 2025.1
$ZV: IRIS for UNIX (Red Hat Enterprise Linux 8 for x86-64) 2025.1.3 (Build 481_1U) Tue Feb 3 2026 15:24:0

Comments

DC AI Bot · 4 hr ago Bot

This issue could be related to how mirroring works and certain configurations within the mirror setup:

  1. Code and Mappings: Code in InterSystems IRIS is treated as data and should theoretically be mirrored like other data unless there is a configuration issue. A potential issue could be related to database mappings or where the code resides. It is important to ensure that all code databases are part of the mirror and properly journaled. Additionally, you should verify that mappings, like package or routine mappings, are consistent across mirrored nodes 12.

  2. Namespace %SYS: Namespace %SYS is excluded from mirroring since it typically contains static or server-specific configurations. If your code involves components stored or mapped from %SYS, they will not be mirrored. If you want such critical components mirrored, you may need to create a new database within the mirror and remap the critical components there, but this setup requires careful evaluation 34.

  3. Manual Interventions: In mirrored setups, some components or changes like scheduled tasks or production adapter settings might not automatically replicate. It might be necessary to manually ensure consistency across the nodes by inspecting and applying changes manually on all mirror members 5.

  4. Schema Mapping: Ensure that all schemas are correctly homed and mapped within mirrored databases. If your schema resides in a non-mirrored namespace or database such as ENSLIB (commonly excluded from mirrors), those changes will not replicate 4.

You should confirm if the databases and code are stored in properly mirrored databases. If the problem persists, further investigation into the node configurations or mappings might be needed.


Sources:

Tell us more:
Don't like the style
Not factually correct
Didn't fully follow instructions
Refused when it shouldn't have
Being lazy
More...
Submit
0 0
Yaron Munz · 2 hr ago

AI bot answer is not relevant to the question.

You say that code/data is in the same DB that is mirrored. 2025 and 2022 are using different version of journaling, but 2025 is capable of de-journaling journals from previous version (but not the vice versa).

1. When you upgraded the failover to 2025 (the one which is the new primary) did you had any issues with journal files? (might be that some files were dropped in the upgrade and not processed).
2. is that "missing rule" mapped to another DB that is not in mirror?

0