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 (which
is recommended) then the fourth piece of the task server address needs to use this
syntax, e.g. :mirror:MIRRORSET:DELTANJI-LOCAL
For example, instead of: ,LIVE,PATHOLOGY,c:\databases\deltanji-local
Use: ,LIVE,PATHOLOGY,:mirror:LIVEMIRROR: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 and the Deltanji Deploy install daemon.
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.