Question
· Mar 8, 2021

How to sync info not in Mirror?

IRIS use MIRROR to ensure the continuous operation of the hospital business, but MIRROR synchronization data does not contain (web application configuration information, task plans, sql gateway, etc.), about the synchronization of such information do we have a better solution to solve this problem? For example, if we want to make cross-server backups of key information such as code (which can be used as business recovery),  if the cluster servers cannot recover and provide services in an unexpected situation but we need to resume production business with such backup information to quickly resume business, is there a good solution for this type of scenario?

Discussion (8)1
Log in or sign up to continue

There is a trick that may work for some pieces but requires very careful setup:
- create a new database that can be part of the MIRROR
- then you can map the components that are INDEPENDENT of the local instance to this DB

Be warned:
Identification and Isolation of these pieces can be quite tricky and sometimes also impossible
In addition, this can make troubleshooting and maintenance (release update?) rather complicated
and you should do an in-depth evaluation if the extra effort values the achieved result.  

Hi Vic!

These are great instructions and tools to export/import different server components:

So is the idea that this all should be performed manually by an administrator for a mirrored member?

If yes how often do we recommend performing these operations?

It's difficult to make a recommendation for how often these items should be synced. It is basically dependent on how often you make changes to these items, what types of changes you want to sync, how prepared you want to be for potential failovers, and what your recovery process during a failover would entail. If you make a change that the backup needs to take over and run your application, you should probably sync that change as soon as possible. Other changes may not be as critical.

This list can be grouped into 3.5 categories:

  • Almost  Runtime changes

Only the last 2 are critical for successful mirror failover and require dynamic handling
and the last requires also non-stop monitoring as it is not directly triggered by SysAdmin.