Database mirroring scenarios
•
Environment: cloud
Some tooltip text!
• 1 minute to read
• 1 minute to read
The mirroring system is to a large extent self-bootstrapping.
Scenarios that are handled
| 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). |