BlockReplication Event Log Warning ID 245 – Should I be concerned?

I noticed a fair amount of alerts in one of the Exchange 2010 SP1 environments I have access to related to block mode replication warnings. The event source is HighAvailability and the event ID is 245. The event type is “Warning” and the events are located inside the crimson channel on an Exchange 2010 SP1 mailbox server that is a member of a DAG. Below is the location of the event log.

This event shoud not show up on a pre-SP1 mailbox server as “continuous replication – block mode” was not introduced until SP1 for Exchange Server 2010. For more information related to block mode replication and what is does, please go here.

First I wanted to verify whether or not the Exchange 2010 SP1 dag is operating in block mode. I merely was curious as to what the current state of the replication was as Exchange will switch between the two continuous replication models on its own.

For information on how to verify this, see here.

What is the error?

Source: HighAvailability    EventID: 245   Type:Warning
General Information Tab:
Block-mode replication for database copy ‘DatabaseServerName’ released a range of complete but unfinalized logs from generation 0x13b30b to 0x13b30b. The data is identical to the active copy but the file timestamps may differ by a small value

Thinking about how block mode continuous replication is invoked, we know that the passive copy of the Exchange database has caught up and is only relying on the EXX.chk file at this point to determine what has been commited to the in-memory copy of the edb file, written to the database on disk, and to determine what the active copy dag member needs to provide from a replication persepective. This warning seems to be due to either a *over event or something that would cause the system to close or write what is in memory to a .log file and timestamp it, but with a timestamp that is different from the source. My thought is that this warning is written to the block mode operation log when Exchange determines it needs to switch from block mode back to file mode for whatever reason.

It is the log copiers job to determine when to switch between continous replication file mode (CRFM) and continous replicatoin block mode (CRBM). If the log copier were to track via logging somewhere when it switches between the two modes, I could match up the event timestamps to see if my theory holds true.

Diagnostic Logging set to High on the MSExchangeRepl service did not show anything informative during the same time frame as the 245 warnings other than database redundancy health check scheduled tasks and log truncation due to backups as expected. This is only a hunch that I will try to validate but in my experiences so far with Exchange 2010 SP1 and DAG, this warning can be safely ignored. If anyone reads this and can shed some light, please let me know. I will continue to dig as well!

Users feedback ( 1 )

  1. Ken said:

    I too was curious about these events. I would expect this to be ok and acceptable since the time that it takes for the replicated data to be a bit behind in time while in block mode.

    “In block mode, as each update is written to the active database copy’s active log file it is also shipped to the passive mailbox copies.”

    From this descritpion it seems that in Block mode data is being injected into logs, first to the active copy and then to passive copy (opposed to file mode where standard log shipping is being used and logs are copied as a whole file). Block mode would allow for a more up-to-date commit process incase of a failure of the active copy.

    Just my thoughts, I could be way off base.

Any thoughts?