One of my customers is using SnapDrive to perform rolling updates and scheduled updates of the SQL databases between their Primary and Secondary sites. They have noticed an issue over the past few weeks where they are expereincing periodic outages on their link between sites, which often occurs during a Snapmirror update. They are aware that they need to get this issue resolved, and that is a something they are working with their provider on, however I've noticed a behavior that I consider to be flawed. SnapDrive, when it triggers an update that gets interrupted, does not resume that update when the link becomes available again. Nor does it allow further scheduled updates to trigger a Snapmirror update. Apparently, when the triggered update gets interrupted, SnapDrive queues further updates indefinitely, and the only mechanism for getting automatic updates to resume is to restart the SnapDrive service.
I hesitate to tell the customer to build a process which automatically restarts SnapDrive on a daily basis to get these updates to resume, but this is the only mechanism I can find to get this working again. If I try a manual update after an interrupted transmission using SnapDrive, I will get an application log warning indicating the requests has been queued. Days can pass and this behavior will not change, even though I can use the CLI or FilerView to directly submit a SnapMIrror update just fine. Only a service restart clears this up.
Is it possible to manually clear this queue without changing the service state, or to have a timer on queued requests so that they expire after a period of time? We are using SDW 6.0.2. Any advice would be appreciated. Thanks in advance!
If snapmirror update fails due to connection issues, SnapDrive queues these requests and periodically (1 min) tries to run snap mirror updates. If any snapmirror update for the same comes, we ignore as we already have it in queue.
Logically this periodical snapmirror update should have addressed your problem. I could not understand what went wrong...SnapDrive log file will help in narrowing down the problem.
Thanks for the reply. That was my understanding as well, but it appears the update retries are not actually occurring, while it still queues new requests coming in. I'm waiting for this behavior to hit again, so I can capture diagnostics during the problem. Once I have a repro scenario, I'll get a case opened with the GSC.
Apologies for jumping on an old thread and raising this issue again. I have this exact same issue and have made no progress on it through normal channels. Does anyone have any experience in resolving the problem? A reboot of the host running SnapDrive will resolve the issue but obviously this is not viable every time the problem occurs..
I just want to let everyone know that I came accross the same issue.
We have Exchange 2007 with 10 storage groups with SnapManager for Exchange and SnapMirror updates are being sent about every 4 hours to the backup storage.
We had a maintenance period with our backup storage that required to restart it a couple of times and out of 20 volumes with Exchange databases, one of them would could not get replicated.
When looking at the Windows Event Viewer the snapmirror updates were just not sent for that particular volume. Then I restarted the SnapDrive service and I could see the following log and everything was okay then.
A SnapMirror update request from source (**************:EXMBX01_SG01_DATA) to destination (**************-BACKUP:EXMBX01_SG01_DATA) was successfully sent.
We are using SnapDrive 6.1. No plans to update it yet because everything is working mostly okay.