• Share
    • Twitter
    • LinkedIn
    • Facebook
    • Email
  • Feedback
  • Edit
Show / Hide Table of Contents

Database Mirroring scenarios

Some tooltip text!
• 2 minutes to read
 • 2 minutes to read

The system is largely self-bootstrapping. The table below summarises what happens in common situations.

Scenarios that are handled

Action SuperOffice cloud Customer / client
New customer CDC is enabled at the source. An initial snapshot is published. The client provisions, performs the initial snapshot, and starts long-polling for changes.
Replica restored from backup Ordinary streaming continues. Kafka offsets travel with the replica (stored in _ReplicationState). The client resumes from where the restored snapshot left off. Any changes published after the offset are received and applied.
Source database restored from backup or moved Tenant-operations sagas reset the offsets and trigger a fresh snapshot. The client receives upserts for the snapshotted rows and reaches a consistent state automatically. No manual intervention.
Writing to the replica fails Streaming continues. The client retries the failed batch. Progress is only committed when a transaction succeeds. Subsequent retries pick up where the last successful commit left off.
Client is offline for less than 7 days Events accumulate in Kafka. The client resumes from the saved offset and replays the buffered events.
Client is offline for more than 7 days Events have been purged from Kafka. The client cannot fill the gap by replay. Run resync-tables on the affected tables (or, in extreme cases, request a full reset from SuperOffice Operations).
New table added in SuperOffice Service The schema is detected by the connector and published. On the next schema-check cycle (default: hourly, SchemaUpdateIntervalSeconds) the client picks it up and snapshots it. Force immediately with update-schema.
Incompatible schema change (rare) A schema event is published. The client drops the affected table in the replica, re-creates it with the new schema, and requests a fresh snapshot for just that table.
Tenant suspended / resumed Provisioning sagas pause and then reset offsets. The client absorbs the resulting snapshot as upserts and continues.

Related

  • Set up the Database Mirroring client
  • Force re-sync
  • Change tracking
  • Troubleshooting
In This Article
© SuperOffice. All rights reserved.
SuperOffice |  Community |  Release Notes |  Privacy |  Site feedback |  Search Docs |  About Docs |  Contribute |  Back to top