InterSystems Mirroring


When Cache/Ensemble instances are mirrored there are a few things to be aware of.

ECP Connections


If you configure an ECP connection to a Caché instance that is mirroring its databases then your ECP connection should also have mirroring enabled (i.e. tick the Mirror Connection checkbox). Point your connection at the IP address or host DNS name of the primary failover member. Do not use the mirror VIP. Allow for double the number of connections because each instance of the mirror is counted as a separate ECP connection.

DELTANJI-LOCAL


There are two choices here. Either the DELTANJI-LOCAL database can be mirrored (which is preferred), or it can be unmirrored. If it is unmirrored then journalling must be switched off for this database, otherwise you will get <PROTECT> errors when you try to write to it across ECP. A journalled but unmirrored database is read-only across ECP.

Remote Location Physical Addresses


When a database is mirrored the extended global reference notation changes from ^["c:\database\live","LIVESERVER"]xxx to ^[":mirror:MIRRORSET:DATABASE","LIVESERVER"]xxx or from ^|"^LIVESERVER^c:\database\live"|xxx to ^|"^LIVESERVER^:mirror:MIRRORSET:DATABASE"|xxx. This affects the physical address syntax used for task server connections. If the DELTANJI-LOCAL database is mirrored then this also needs to use this syntax, e.g. :mirror:MIRRORSET:DELTANJI-LOCAL

For example, instead of: c:\databases\pathology,LIVE,PATHOLOGY,c:\databases\deltanji-local

Use: :mirror:LIVEMIRROR:PATHOLOGY,LIVE,PATHOLOGY,:mirror:LIVEMIRROR:DELTANJI-LOCAL

Or (if DELTANJI-LOCAL is not mirrored): :mirror:LIVEMIRROR:PATHOLOGY,LIVE,PATHOLOGY,c:\databases\deltanji-local

Task Server Startup


When a member of a failover mirror set is starting up it takes a while for it to decide whether it is a primary or backup node. During that time any database update will cause a <PROTECT> error because all the databases are initially mounted read-only.

To avoid problems with this, the task server should not start too soon. Additionally it only makes sense to run the task server on the primary node.

Deal with both of these issues by using NotifyBecomePrimary^ZMIRROR as the place to start the task server instead of SYSTEM^%ZSTART, e.g.

ZMIRROR ; Custom logic for specific mirroring events
 ; See http://docs.intersystems.com/cache20131/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_mirror#GHA_mirror_set_tunable_params_zmirror_routine
 q
 ;
NotifyBecomePrimary() PUBLIC {
 #;This procedure is called as a notification when this system becomes Primary.
 #;It does not return any value.
 #;Start the Deltanji task server on the primary system.
 try {
  j fast1^%vczn|"DELTANJI-LOCAL"|
 }
 catch e {
  d ##class(%SYS.System).WriteToConsoleLog("NotifyBecomePrimary^ZMIRROR error: "_e.AsSystemError(),,1)
 }
 q
}

The same strategy is recommended for autostarting the Beyond Compare server.

Source Control Class


Use Portal on the primary to set a namespace's source control class and the setting will probably turn up on the backup because on most Caché versions it is stored in the namespace's default database.

Cache5^%vcins


Running Cache5^%vcins() in the DELTANJI or DELTANJI-LOCAL namespace is necessary in order to load into the CACHESYS database (which is never mirrored) the Studio templates and add-ins. This should be done on every failover member, not just the current primary, and after every Cache upgrade as well as during a Deltanji upgrade.

Configuration


All of the Cache-level Deltanji configuration work (task server, DELTANJI-LOCAL database, namespace mapping etc) needs to be carried out on both the primary node and all the failover nodes including any DR async nodes. This can be tedious and error prone. The Deltanji config on each failover node should be explicitly tested to ensure everything is configured correctly. This can only be done by actually failing over to that node for real.