Mirrored Configurations
With mirrored InterSystems IRIS configurations, a database is duplicated (or mirrored) between participating mirror members. An InterSystems IRIS mirror set configuration represents the set of participating mirror members for an installation. For a complete description of InterSystems IRIS mirroring, see Mirroring in the High Availability Guide.
If Mirror Virtual IP (or an equivalent technology) is used to provide network redirection to the primary member, then configure the Web Gateway to connect to that address. No further action is required. The Virtual IP address is always mapped to the mirror primary.
For configurations where the Mirror Virtual IP cannot be used (or does not operate in certain disaster scenarios), it is possible to configure the Web Gateway to be mirror-aware. When the Web Gateway is mirror-aware, it assumes responsibility for determining which member is primary. To make a Web Gateway configuration mirror-aware, in the Web Gateway's Server Access section, select Configuration is Mirror Aware and provide the address of one of the mirror members.
Note:
There are situations where it is not appropriate for a Web Gateway configuration to be mirror-aware. For example, a Web Gateway configuration supporting the Management Portal should never be configured to be mirror-aware as the portal must always connect to a specific InterSystems IRIS server regardless of its mirror status.
If a mirror-aware Web Gateway configuration connects to an InterSystems IRIS server that is not a mirror member then the connection fails and the affected client receives a Server Availability error.
The Web Gateway obtains – from the Member that it first connects to – a list of failover members and disaster recovery (DR) members. The Web Gateway persists this list in its local configuration file (CSPRT.ini). If the Web Gateway subsequently cannot connect to the member defined in its configuration then it uses the list previously recorded locally to enable it to identify and connect to alternative members.
The Web Gateway cycles through the members list until it finds the primary. If it cannot find the primary, the Web Gateway defaults to the server defined in the Gateway configuration.
-
The Web Gateway repeatedly cycles through the list until it finds a member defined as primary.
-
To avoid the negative performance impact of a tight looping structure, the Web Gateway pauses after each cycle for a number of seconds equal to the number of tries.
-
For a given HTTP request, the Web Gateway spends no more time attempting to find the primary than that defined in the Server Response Timeout parameter.
-
When searching for the primary, the Web Gateway always connects to failover members first. It only tries async members if it cannot find the primary amongst the failover members. An async member only becomes primary if you manually designate it as primary.
Mirror members appear in the Web Gateway System Status form when the first connection is made. Mirror members are shown named as the current configuration name (as defined under the Web Gateway’s Server Access section) with the mirror set name, mirror, and mirror member name shown as a tooltip.
The columns, Mirror Name and Mirror Status appear in the 'InterSystems IRIS Servers' table. The name of the mirror set and mirror member are shown in the Mirror Name column. The current member status is shown in the Mirror Status column: the Member Type (Failover or Async) is shown and the primary member is labelled as Primary.
