Currently a async member will be in sync with the primary, however in the event of an issue such as a global being deleted then both the servers would have the same issue. However if the async member had a delay journal process property then the async member could be a copy of the primary but behind by 24 hours as a example. The journals for the mirror would still be transferred in real time to the async mirror and in the event that the system is need to be current then they can be processed.
Thank you for submitting the idea. Based on information from our experts the status of your idea was changed to "Will not implement". Please look for details in the comments on the idea. Good luck!
There are comments on this idea from an InterSystems product manager and a community portal moderator.
The idea was transferred to the status “Will not be implemented”, since the author did not respond to comments for several months.
If the author responds to these comments, the status of this idea may be changed.
@Gary Holt, you have comments on your idea. Please answer them to help your idea to be promoted.
Hi Gary,
thanks for suggesting this.
It feels like 24h may be a bit of an arbitrary window. If you only notice the issue after 25h, this delay doesn't really help and if you do notice it within the 24h window, are you planning to still roll journal files forward up to right before? If that is the case, you could as well stick with the current async behaviour and roll back till right before the faulty set/kill.
If you meant to stick with that 24h granularity, maybe you're actually more talking about a daily backup/restore cycle rather than deploying this as a mirror?
Thanks,
benjamin
I'm sure, if you need it that way, you just can do nightly sync instead. The mirror is stopped during the day, and on at night. I think it's doable with a right configuration.