At most, users will have
a single transaction fail; when they retry the same transaction, it will succeed.
Failover in High Availability mode is a thing of beauty. It??™s faster than a SQL clustering
failover because it only has to fail over to a single database, it requires no client redirection,
and, in many cases, no one but the DBA knows a failover even occurred. You can
also initiate failover manually if server patches require a reboot of the principal node.
Failback
In the event of a failover, failback is simply a case of the mirror and witness nodes both
agreeing that the principal is unavailable for any of the following reasons:
??? A network error of some kind
??? DBA error on the principal node (been there, done that)
??? Principal server failure
??? Failure of the SQL Server instance
It would be possible for a clever programmer to actually check to see if any of
these types of errors have occurred and to retry the transaction against the mirror.
There should be no risk of updating the mirror while the principal is still running.
While in mirror mode, only the principal can update the database.
Pages:
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403