locked
I can't understand how mirroring forced service tolerate data loss?! RRS feed

  • Question

  • In Synchronous Database Mirroring (High-Safety Mode), they (Microsoft) say:

    "After synchronization finishes, every transaction committed on the principal database is also committed on the mirror server, guaranteeing the protection of the data. This is achieved by waiting to commit a transaction on the principal database until the principal server receives a message from the mirror server stating that it has hardened the transaction's log to disk"

    then and on that same link they said:

    "When the partners are connected and the database is already synchronized, manual failover is supported. If the mirror server instance goes down, the principal server instance is unaffected and runs exposed (that is without mirroring the data). If the principal server is lost, the mirror is suspended, but service can be forced to the mirror server (with possible data loss). For more information, see Forced Service (with Possible Data Loss)."

    Reading in that link Forced Service (with Possible Data Loss), they explained how and why data loss is possible to happen:

    "It is essential to understand that forcing service can cause data loss. Data loss is possible because the mirror server cannot communicate with the principal server and, therefore, cannot guarantee that the two databases are synchronized."!!!

    If the data will not be committed to the principal until the principal receives an acknowledgement from the mirror that the transactions have been hardened to the log of the mirror, how the difference in data will happen? 
    for example, if someone inserted a data on the principal, but the principal went down before it was able to send the transactions to the mirror, as per the first quotation the data will not be committed to the principal because it didn't receive any message from the mirror that the transactions are safe in mirror log; so the principal and the mirror should stay sync!



    • Edited by Butmah Monday, May 23, 2016 9:56 AM
    Monday, May 23, 2016 9:50 AM

Answers

  • You are not totally correct, I might not find this in current books but (in certain cases) failure to commit on Mirror will not force failure to commit on principal. This is something internal and not documented. Although the sync mode would be like wait for commit on mirror but what if mirror does not responds at all like disconnection. 

    From Forced Service allow data loss please read section "Risk of forcing service"

    It is essential to understand that forcing service can cause data loss. Data loss is possible because the mirror server cannot communicate with the principal server and, therefore, cannot guarantee that the two databases are synchronized. Forcing service starts a new recovery fork. Because the original principal database and mirror database are on different recovery forks, each database now contains data that the other database does not: the original principal database contains whatever changes were not yet sent from its send queue to the former mirror database (the unsent log); the former mirror database contains whatever changes occur after service was forced. 

    This is what referred as being mismatch in data.


    Cheers,

    Shashank

    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    My TechNet Wiki Articles

    MVP

    Tuesday, May 24, 2016 6:03 AM

All replies

  • Well you got confused here.

    The option of "Forced service allow data loss" is ONLY possible in Asynchronous mirroring and the very first paragraph you quoted is for Synchronous mirroring. In Async principal does not waits for mirror to commit data, it will just send log buffer to mirror and would commit its data while in Sync it will wait for commit to be entered on Mirror before committing on principal

    Async mirroring is ONLY possible in enterprise edition. If you can afford some data loss you can go with Async it has less overheads as compared to Sync mirorring


    Cheers,

    Shashank

    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    My TechNet Wiki Articles

    MVP

    Monday, May 23, 2016 10:53 AM
  • Shanky, thanks as usual.

    However can you please confirm your answer but after you check the first link that I've posted in my question, especially the "High-Safety Mode Without Automatic Failover" part where they said:

    "When the partners are connected and the database is already synchronized, manual failover is supported. If the mirror server instance goes down, the principal server instance is unaffected and runs exposed (that is without mirroring the data). If the principal server is lost, the mirror is suspended, but service can be forced to the mirror server (with possible data loss). For more information, see Forced Service (with Possible Data Loss)."

    Again this is under the article which is titled "Synchronous Database Mirroring (High-Safety Mode)"

    Monday, May 23, 2016 11:09 AM
  • OK I got it what you are asking. Actually this is telling various scenarios about mirroring. Yes it told before that with sync mirroring the primary will wait for secondary to commit and this Seems like a good scenario for no data loss, but this is a myth and so the BOL tried to explain you other scenario.

    Consider scenario where Principal is down such that it cannot to mirror in that case there might be some transactions which were not sent on mirror but executed on principal so in that case you have no option but to force and make the mirror server as principal. Now when you do that the transactions which were there on principal did not reached mirror so this is what book is referring to as "A data loss". 

    Hope this is clear 


    Cheers,

    Shashank

    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    My TechNet Wiki Articles

    MVP

    Monday, May 23, 2016 11:34 AM
  • Consider scenario where Principal is down such that it cannot to mirror in that case there might be some transactions which were not sent on mirror but executed on principal so in that case you have no option but to force and make the mirror server as principal. Now when you do that the transactions which were there on principal did not reached mirror so this is what book is referring to as "A data loss". 

    Sorry but this is not what I understand from BOL when I read:

    "This is achieved by waiting to commit a transaction on the principal database until the principal server receives a message from the mirror server stating that it has hardened the transaction's log to disk" ... this is again under Synchronous Database Mirroring (High-Safety Mode)

    What I understand from that, and applying on your example/scenario, that although those "some transactions" were executed on the principal they will not be committed on the principal until the mirror tells that it got them hardened on mirror's log files. And if the principal was not able to send those executed but not committed transactions to the mirror, because the principal went down, a network problem, or any reason, those uncommitted transactions should remain uncommitted on the principal as per the above line that I've quoted from BOL!, hence the principal should not have more committed data than the mirror, hence they should be always in sync! ...

    I hope you understand now what confuses me.


    Tuesday, May 24, 2016 5:14 AM
  • You are not totally correct, I might not find this in current books but (in certain cases) failure to commit on Mirror will not force failure to commit on principal. This is something internal and not documented. Although the sync mode would be like wait for commit on mirror but what if mirror does not responds at all like disconnection. 

    From Forced Service allow data loss please read section "Risk of forcing service"

    It is essential to understand that forcing service can cause data loss. Data loss is possible because the mirror server cannot communicate with the principal server and, therefore, cannot guarantee that the two databases are synchronized. Forcing service starts a new recovery fork. Because the original principal database and mirror database are on different recovery forks, each database now contains data that the other database does not: the original principal database contains whatever changes were not yet sent from its send queue to the former mirror database (the unsent log); the former mirror database contains whatever changes occur after service was forced. 

    This is what referred as being mismatch in data.


    Cheers,

    Shashank

    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    My TechNet Wiki Articles

    MVP

    Tuesday, May 24, 2016 6:03 AM