How Snapshots and Logs are Used with Durability

In-memory database updates you make using DDL and DML commands are written to logs on disk. When the size of the updates reaches snapshot_trigger_size, a snapshot is taken and written to disk. Following the creation of a snapshot, subsequent DDL and DML in-memory updates are again written to the logs, until snapshot_trigger_size is again reached.

Following a server restart, the latest snapshot and the logs containing the updates made after the snapshot are loaded from disk and replayed in memory.

How Snapshots and Logs are Used with Replication

With replication, database partitions are copied from a primary host to a secondary host.

When a replica is provisioned, it receives an initial snapshot from the master. The replica replays this snapshot.

Going forward, the replica receives and replays logs from the master. These logs contain the in-memory database updates (from DDL and DML commands) made on the master. Following the creation of a snapshot, subsequent DDL and DML in-memory updates on the master are again written to the logs that are sent to the replica, until snapshot_trigger_size (as set on the master) is again reached.

For clusters that use unlimited storage:

• While replicas typically do not handle snapshots, they do download the latest snapshot from unlimited storage when provisioning or recovering.

• While the master does not send snapshots to replicas, it does upload snapshots directly to unlimited storage.

For clusters that do not use unlimited storage:

• Master partitions send the latest snapshot when provisioning a replica.

• When the master takes a new snapshot, this action is communicated to the replica. The replica then takes its own snapshot, which is identical to the master’s, and stores it in the same location.

• Replicas may cancel or skip taking a snapshot for various reasons.