mirror server down, will this affect replication?

Question

mirror server down, will this affect replication?

Viewing 3 posts - 16 through 17 (of 17 total)

You must be logged in to reply to this topic. Login to reply

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 1

aqkhan_k (4/29/2010)
When a publication database is mirrored, Log Reader Agent behavior is governed by the mirroring state of the database. By default, the Log Reader Agent can only replicate log records that have been hardened in the log on the mirror server (the process in which the mirror server writes a transaction log record to the transaction log file is termed hardening the log). This means it cannot replicate log records with a Log Sequence Number (LSN) that is higher than the LSN of the last log record that was hardened on the mirror.
It is possible for the principal to become exposed (the mirror is accessible but there are log records that have not yet been hardened on the mirror) or isolated (the mirror is inaccessible). In both cases, if the principal is still able to serve the database, any changes made to the database are not replicated until the corresponding log records are hardened on the mirror.
This behavior introduces latency in the replication stream, and is done so that if a mirroring failover occurs, it is guaranteed that replication Subscribers cannot be “ahead” of the new principal database.
When the Log Reader Agent is waiting for transaction log records to be hardened on the mirror, the following message is entered in the Log Reader Agent history:
Replicated transactions are waiting for next Log backup or for mirroring partner to catch up.

Okay, that makes some sense. Again, this goes back to where I said this needed to be tested. I am new to database mirroring and we don't use replication (set it up years ago in a test environment (SQL 2000)).

TheRedneckDBA SSChampion Points: 14001 More actions · Answer 2

aqkhan_k (4/29/2010)
When a publication database is mirrored, Log Reader Agent behavior is governed by the mirroring state of the database. By default, the Log Reader Agent can only replicate log records that have been hardened in the log on the mirror server (the process in which the mirror server writes a transaction log record to the transaction log file is termed hardening the log). This means it cannot replicate log records with a Log Sequence Number (LSN) that is higher than the LSN of the last log record that was hardened on the mirror.
It is possible for the principal to become exposed (the mirror is accessible but there are log records that have not yet been hardened on the mirror) or isolated (the mirror is inaccessible). In both cases, if the principal is still able to serve the database, any changes made to the database are not replicated until the corresponding log records are hardened on the mirror.
This behavior introduces latency in the replication stream, and is done so that if a mirroring failover occurs, it is guaranteed that replication Subscribers cannot be “ahead” of the new principal database.
When the Log Reader Agent is waiting for transaction log records to be hardened on the mirror, the following message is entered in the Log Reader Agent history:
Replicated transactions are waiting for next Log backup or for mirroring partner to catch up.

Interesting. I hadn't thought of it from that angle. Thanks for the explanation!

The Redneck DBA

Kishore-132325 Hall of Fame Points: 3784 More actions · Answer 3

For SQL 2008, we can enable trace flag 1448 on the instance of the publisher database. Then, Log Reader Agent will always copy the transactions that are marked for replication from the transaction log into the distribution database.