January 11, 2013 at 2:07 pm
Hi,
In database mirroring, for "high-safety mode without automatic failover" it is mention that :
"Every transaction committed on the principal database is also committed on the mirror server, guaranteeing 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."
And it is also mention that:
"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). "
So, If the principal server is lost, why service can be forced to the mirror server WITH POSSIBLE DATA LOSS ?
Why with WITH POSSIBLE DATA LOSS ?
ref: http://msdn.microsoft.com/en-us/library/ms179344(d=printer,v=sql.105).aspx
regards,
cygne
January 12, 2013 at 1:42 am
Did you follow the link in that msdn article you referenced, http://msdn.microsoft.com/en-us/library/ms189977(v=sql.105).aspx? It does a good job of explaining what happens.
January 14, 2013 at 6:44 am
Hi,
yes I read this article.
I understand the possible data loss with high-performance mode(asynchronous).
But I still don't understand why we can have possible data loss with high-safety mode?
In high-safety mode, transaction committed on the principal are also committed on the mirror.
Do you have an idea ?
best regards
David
January 14, 2013 at 6:51 am
"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). "
The possible data loss is when the priciple fails while the mirror was also failed. In that scenario if the mirror is brought up and forced to be the new principle data loss may have occurred because transactions may have been on the principle that were not applied to the mirror yet.
Joie Andrew
"Since 1982"
January 14, 2013 at 7:01 am
Thanks for your answer.
It's clear now.
best regards
January 14, 2013 at 7:08 am
cygne17_2 77208 (1/14/2013)
Hi,yes I read this article.
I understand the possible data loss with high-performance mode(asynchronous).
But I still don't understand why we can have possible data loss with high-safety mode?
In high-safety mode, transaction committed on the principal are also committed on the mirror.
Do you have an idea ?
best regards
David
It said it in the article:
If service is forced because the principal server has failed, potential data loss is depends on whether any transaction logs were not sent to the mirror server before the failure. Under high-safety mode, this is possible only until the mirror database becomes synchronized.
There is a possibility if the principal and mirror are synchronized, that when the principal fails that it may not have sent the most recent transactions to the mirror database. These would be transactions that had been queued but not yet sent, perhaps due to network latency or a high volume of transactions. At this point, the databases may have actually been in a synchronizing state but SSMS or Mirroring Monitor had not yet changed to reflect it.
January 14, 2013 at 11:42 am
But I still not understand why ?
In safety-mode, principal do not applied change on datafile until it's write in transaction log of the mirror.
So, if principal crashed, the transaction not written to the mirror will be rollback on the old principal when it will come back.
So the data will not be lost because they will not be applied on old principal.
missing something ?
regards,
January 14, 2013 at 1:22 pm
But I still not understand why ?
In safety-mode, principal do not applied change on datafile until it's write in transaction log of the mirror.
So, if principal crashed, the transaction not written to the mirror will be rollback on the old principal when it will come back.
So the data will not be lost because they will not be applied on old principal.
missing something ?
regards,
There are a couple of reasons why transactions would not have come over I can think of. One is if the mirror server was in a suspended state when the primary failed and then forced to become the primary. In that scenario there are commands that could have applied on the primary that did not apply on the mirror.
Another reason could be because db mirroring works in near real-time using queues. Depending on the amount of traffic and the latency between the primary and mirror servers I can see a scenario where commands are not yet received at the mirror before failover. I believe Paul Randal did an article on this for TechNet magazine.
Some time later...
Yep, he did.
http://technet.microsoft.com/en-us/magazine/hh334997.aspx
Joie Andrew
"Since 1982"
January 15, 2013 at 4:20 am
As Joie has stated and as Paul Randal's article explains even with safety on (synchronous mode), without a witness a mirror disconnection will allow the principal to stay online and the send queue to grow, this represents the data loss risk factor.
Also, in normal operation, if the principal fails before this send queue has been processed by the mirror, the mirror needs to be forced into service at the risk of data loss.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 15, 2013 at 9:12 am
Thanks all for you answers.
Have a nice day!
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply