Database mirroring scenarios

In this article

    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).