The mirroring system is to a large extent self-bootstrapping.
Scenarios that are handled
Mirroring scenarios
| Action |
Online |
Partner |
|
New customer
|
Change tracking is enabled when each table is mirrored.
All rows considered changed.
|
The table created when each schema is received.
All rows populated.
|
|
Mirror restored from backup.
|
Ordinary mirroring.
|
LSN is part of the restored backup.
All changes done after restore will be retransmitted automatically.
|
|
Online restored from backup
|
Manual intervention needed to wipe the mirror.
It can be forced by turning off change tracking in the restored database.
|
Mirror wiped and repopulated remotely.
|
|
Writing to mirror fails
|
Ordinary mirroring next cycle.
|
LSN is updated only when a commit is successful.
All changes done after the last successful cycle will be transmitted.
|
|
Mirroring service is down for more than 7 days.
|
The mirror is automatically wiped and repopulated.
|
The mirror is automatically wiped and repopulated.
|
|
Incompatible schema change.
|
The error returned from the client-side causes retry with wipe/repopulate (not implemented in beta).
|
Schema change fails: the table is dropped and an error returned (not implemented in beta).
|