Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
The Microsoft Exchange Replication service has suspended log replay on database '<database name>' because the current copy queue length of 13 exceeds the threshold of 12. Replay will automatically be resumed when the queue length falls below 5.
|English: Request a translation of the event description in plain English.|
From a Microsoft support forum:
The LogReplayer component of the Microsoft Exchange Replication service includes new logic to suspend log replay if the copy queue length increases beyond a specific threshold. If the number of logs in the copy queue is greater than the number of log files that have been copied to the passive database copy, but not inspected by the passive copy, then the Microsoft Exchange Replication service will suspend log replay for the passive copy and log Warning event 4110 in the event log. When the number of log files in the copy queue drops below the number of non-inspected copied log files, the Microsoft Exchange Replication service will resume replay for the passive copy and log Informational event 4111 in the event log. After the copy queue length drop below the threshold, it will resume the log replay automatically.
We couldn't increase the the threshold for copy queue length, it is by design.
1. Network issue
2. Search index
You can try reseeding the DB once and see the results:
Update-MailboxDatabaseCopy -Identity <Database>\<serverName> –DeleteExistingFiles
Once you perform above resume DB copy and check the health and see the status for a week or so:
Resume-MailboxDatabaseCopy -Identity <Database>\<serverName>
According to Microsoft, the 12 messages threshold cannot be adjusted. The warning indicates a limitation in the replication bandwidth. As the event description indicates, the log replay will be resumed as soon as the queue length falls below 5.
The copy queue length mentioned in the event relates to Exchange replication and it is the number of logs recognized by the passive copy that needs to be replicated. See TD298065 for more details.
TF360892 provides some suggestions on what to do if the Exchange database copy isn't keeping up with the changes on the active database copy.
EV100549 (Uncovering Exchange 2010 Database Availability Groups) provides a good introduction along with best practicies for Database Availability Groups (DAGs).
From a support forum:
It seems to be your bandwidth to your server. You can not change the threshold or at least I do not know of anyone that knows how to do it. I have the exact same situation where my bandwidth does not keep up in peak times. I have a 24 hour lagged copy on this server.
Run this on your server multiple times during the day:
Test-ReplicationHealth | fl check, result, error
I bet you find that at certain times all is well and others will generate a delay error such as this:
Error: Log replay for database Mb\Server on machine is falling behind and cant keep up with log copy and inspection.....
EV100550 (Exchange 2010 Server Role Requirements Calculator) points to the Exchange Requirements Calculator than can estimate the necessary bandwidth for the database replication. This should assist in determining if the current issue is caused by insufficient bandwidth.
|Private comment: Subscribers only. See example of private comment|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated