In some situations, it might be necessary to stop an incremental snapshot.
For example, you might realize that snapshot was not configured correctly, or maybe you want to ensure that resources are available for other database operations.
You can stop a snapshot that is already running by sending a signal to the {data-collection} on the source database.

You submit a stop snapshot signal to the signaling {data-collection} by inserting a stop snapshot signal document into it.
The stop snapshot signal that you submit specifies the `type` of the snapshot operation as `incremental`, and, optionally specifies the {data-collection}s that you want to omit from the currently running snapshot.
After {prodname} detects the change in the signaling {data-collection}, it reads the signal, and stops the incremental snapshot operation if it's in progress.


.Additional resources
You can also stop an incremental snapshot by sending a JSON message to the xref:{context}-stopping-an-incremental-snapshot-kafka[Kafka signaling topic].

.Prerequisites

* {link-prefix}:{link-signalling}#debezium-signaling-enabling-source-signaling-channel[Signaling is enabled]. +
** A signaling data collection exists on the source database.
** The signaling data collection is specified in the xref:{context}-property-signal-data-collection[`signal.data.collection`] property.

.Procedure

. Insert a stop snapshot signal document into the signaling {data-collection}:
+
[source,bash,indent=0,subs="+attributes,+quotes"]
----
_<signalDataCollection>_.insert({"_id" : _<idNumber>_,"type" : "stop-snapshot", "data" : {"data-collections" ["_<collectionName>_", "_<collectionName>_"],"type": "incremental"}});
----
+
For example,
+
[source,bash,indent=0,subs="+attributes"]
----
db.debeziumSignal.insert({
"type" : "stop-snapshot",
"data" : {
"data-collections" ["\"public\".\"Collection1\"", "\"public\".\"Collection2\""],
"type": "incremental"}
});
----
+
The values of the `id`, `type`, and `data` parameters in the signal command correspond to the {link-prefix}:{link-signalling}#debezium-signaling-description-of-required-structure-of-a-signaling-data-collection[fields of the signaling {data-collection}].
+
The following list describes the parameters in the example:
+
`db.debeziumSignal.insert`::
Specifies the fully-qualified name of the signaling {data-collection} on the source database.

`type`::
Specifies the kind of signal to send, in this case a `stop-snapshot` signal.

`_id`::
This optional field is omitted in the preceding signal.
Because the document does not explicitly assign a value to the parameter, MongoDB automatically assigns an arbitrary id to the document.
This `_id` becomes the identifier for the signal request.
{prodname} does not use this identifier string; however you can use the `id` to collate log messages with documents in the signaling {data-collection}.

data.data-collections::
An optional component in the `data` field of the signal that specifies an array of {data-collection} names or regular expressions that represent {data-collection}s that you want to exclude from the snapshot.
The regular expressions in the array match the fully-qualified names of {data-collection}s in the format `database.collection`.

data.type::
A required component in the `data` field of a stop snapshot signal that specifies the type of snapshot operation that is to be stopped.
Currently, the only valid option is `incremental`.
If you do not specify a `type` value, the signal fails to stop the incremental snapshot.
