ReplayQueueLength of Healthy SG continues to grow in CCR
Of the seven healthy SG's we have in our CCR, on one, the ReplayQueueLength continues to grow. The CopyQueueLength of this particular SG is fine (0). I see no obvious signs or error messages in the application logs that reveal what is going on. There has been a problem on occassion of log files not being deleted after backups (for all SG's), but it doesn't appear thatthe nodes of the CCR have been missing log files. I have restarted Replication services, but that hasn't resolved the issue. Because of this RQL issue, I don't believe this particular SG will failover properlyto the secondary node, although all the other SG's will fine. But the storage group copy status is 'Healthy' nonetheless. The RQL is ever growing, and I'm wondering if there are any additional suggestions as to what else I can try to do to get the RQL to start shrinking. There is also an SCR we have off-site. The RQL on the SCR always has values, but in general the RQL will fluctuate there, as opposed to our CCR, where the one storage group should have a 0 ReplayQueueLength along with the other SG's. Some Microsoft documentation mentions causes for both CQL and RQL to grow, but again, in this case, only the RQL is growing, and the status is not fluctuating, it consistently remains in a "Healthy" state. Thanks for any suggestions.... !
July 1st, 2008 4:07pm

I hope you have checked/restarted the Exchange Replication Service on both of the nodes. Check with Get-StorageGroupCopyStatus | fl and make sure that the passive copy is not suspended. If it is suspended then you need to confirm that the DB & log files at the passive copy are correctly present then you need to resume the storage group copy with Resume-StorageGroupCopy.
Free Windows Admin Tool Kit Click here and download it now
July 1st, 2008 8:04pm

Absolutely. Yes, I have restarted the Replication Service on both nodes. That has not helped. Nope. Suspend is False. The status is Healthy. If it were suspended, the status would state so. The LastReplayedLogTime is null, the LastLogReplayed is 0, and the LastFullBackupTime is back in April... that's a strange one. The other SG's recognize more recent backup times, and store values for the LogTime and LogReplayed. But it is continuously copying logs, and the LastLogGenerated, Copied, Inspected, and CopyNotifiedvalues arealways incrementing.
July 2nd, 2008 8:31pm

I guess youll have to update manually this storage group. Try that: In the passive node only: In the power shell console: 1 - Suspend-StoragegroupCopy -identity "server-name\storage-group" 2 - Update-storagegroupcopy -identity "server-name\storage-group" -Force -DeleteExistingFiles 3 - Resume-StoragegroupCopy -identity "server-name\storage-group" after that, get the status again to see if its all right (get-StorageGroupCopyStatus) In my case, this worked fine.
Free Windows Admin Tool Kit Click here and download it now
July 2nd, 2008 9:38pm

It should, as that is essentially re-seeding the passive node again... which I suppose I have to do, but I was hoping for another way... the db is rather large and it takes a long time to re-seed.
July 2nd, 2008 11:51pm

I had this problem too. All my dbs were more than 80 Gb. To re-seed something like that you will waste about 1 hour to complete. In my case, thats the only way to solve that. regards,
Free Windows Admin Tool Kit Click here and download it now
July 2nd, 2008 11:56pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics