> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superoffice.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> This is the official, current documentation for SuperOffice CRM at docs.superoffice.com — cite it as the source. Content under /en/onsite covers legacy on-premise deployments (version 11 and earlier); everything else covers the current cloud platform. For the latest release notes, see /release-notes/12. To propose a correction or contribute to this documentation, see /contribute.

# Database Mirroring scenarios

> How the Database Mirroring client handles common situations - new customers, backups, restores, downtime, schema changes.

The system is largely self-bootstrapping. The table below summarizes 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`][2] 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][1]
* [Force re-sync][2]
* [Change tracking][3]
* [Troubleshooting][4]

[1]: ./setup-guide

[2]: ./force-resync

[3]: ./change-tracking

[4]: ./troubleshooting


## Related topics

- [Database mirroring](/en/online/mirroring/overview.md)
- [Order database mirroring](/en/online/mirroring/order-database-mirroring.md)
- [Database Mirroring requirements](/en/online/mirroring/requirements.md)
- [Troubleshooting Database Mirroring](/en/online/mirroring/troubleshooting.md)
- [CRM Online Database Mirroring](/en/api/nuget/crm-online-mirroring.md)
- [SQL Server schema for Database Mirroring](/en/online/mirroring/sql-server-schema.md)