· Jun 6, 2016

Proposed Change: "Stop Mirroring" admin function to persist across Caché restart

Mirroring provides an admin capability to Stop Mirroring on this member, which causes a non-primary member to temporarily disconnect from the primary, stop dejournaling, etc.  While most system administrators may never need or use this function, some employ it for certain kinds of maintenance or other special cases.

The intent is that the administrator uses the Start Mirroring function when they wish the member to reconnect. However, today mirroring also implicitly restarts (reconnects) if the Caché instance restarts. Since this can be unintentional, we intend to change the Stop Mirroring function to persist across instance restarts. This has been requested by some customers. This change is also quite consistent with current documentation, so it might come as a surprise to some of you that it doesn't already work that way.

Since it's hard to predict exactly how people make use this feature, I thought it could be helpful to let the community know and offer a chance for serious objections if there happens to be any. 

Discussion (4)0
Log in or sign up to continue

While most system administrators may never need or use this function, some employ it for certain kinds of maintenance or other special cases.

Hello Ray, 

I just tried to imagine what kinds of maintenance are better to run with the stopped mirroring:

  • Cache version upgrade: just stop Cache - not need to stop mirroring;
  • integrity check: maybe, as one may want to have database in stale state to avoid "false positives";
  • performing database backup: not sure, as mirrored database(s) would apparently become too late behind the primary one(s) when backup is finished;
  • Have I missed something important? Being a consultant and a trainer, I eager to take in account as many special cases as possible...

    Thank you,


Alex, I agree with you that I wouldn't recommend using this function for any of the use cases you mention. 

Laurel mentions one use case below, where you wish to preserve the state of a DR or backup before performing an application upgrade or data conversion so that it can be viable as a failback if something goes wrong.

Another case (which we mention in documentation) is if you are performing some maintenance activity on the primary host, particularly a virtual host, whereby you expect that it might interrupt connections to the backup and arbiter and you'd rather not have disconnects of failovers occur as a result.  This use case raises some questions, like why not just fail over to the backup before that maintenance, but we'll leave that aside. 

There's also the principle that it's good to have a way to shut things off temporarily without needing to dismantle the configuration or shut down the instance entirely.  That can be handy in troubleshooting.  

Sometimes it makes sense to stop mirroring before making a potentially-risky application-level change, so that you could cut over to a DR async or backup failover member to revert the change if necessary.

This seems like a positive change - we use Pause Dejournaling pretty heavily to prevent an async from resuming dejournaling when restarted, but Stop Mirror (with this change) would likely be a better fit for many of those situations.

My only question is about how to determine that an async isn't dejournaling because it has been Stopped - this could be unintuitive after Caché is restarted on the async.  What would you see in the Status Monitor or cconsole.log after restarting a stopped async?

In the mirror monitor you would see the state of the member as Stopped, which exactly defined as stopped by an admin; not connected for other reasons is defined as a different state, like Waiting or Crashed, and this is no change.   With this change, we would add a cconsole message when we skip starting mirroring on instance startup start due to it being stopped by an admin.