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. The status has been changed to "needs review".
Stay tuned!
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.