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 signaling {data-collection} on the source database.

You submit a stop snapshot signal to the signaling {data-collection} by sending it in a SQL `INSERT` query.
The stop-snapshot signal 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.

.Using a source signaling channel to stop an incremental snapshot

. Send a SQL query to stop the ad hoc incremental snapshot to the signaling {data-collection}:
+
[source,sql,indent=0,subs="+attributes,+quotes"]
----
INSERT INTO _<signalTable>_ (id, type, data) values (_'<id>'_, 'stop-snapshot', '{"data-collections": ["_<fullyQualfiedTableName>_","_<fullyQualfiedTableName>_"],"type":"incremental"}');
----
+
For example,
+
include::{snippetsdir}/{context}-frag-signaling-fq-table-formats.adoc[leveloffset=+1,tags=stopping-incremental-snapshot-example]

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 table describes the parameters in the example:
+
.Descriptions of fields in a SQL command for sending a stop incremental snapshot signal to the signaling {data-collection}
[cols="1,2,6",options="header"]
|===
|Item|Value |Description

|1
|`{collection-container}.debezium_signal`
|Specifies the fully-qualified name of the signaling {data-collection} on the source database.

|2
|`ad-hoc-1`
| The `id` parameter specifies an arbitrary string that is assigned as the `id` identifier for the signal request. +
Use this string to identify logging messages to entries in the signaling {data-collection}.
{prodname} does not use this string.

|3
|`stop-snapshot`
| Specifies `type` parameter specifies the operation that the signal is intended to trigger. +

|4
|`data-collections`
|An optional component of the `data` field of a signal that specifies an array of {data-collection} names or regular expressions to match {data-collection} names to remove from the snapshot. +
The array lists regular expressions which match {data-collection}s by their fully-qualified names in the format `{collection-container}.table`

If you omit this component from the `data` field, the signal stops the entire incremental snapshot that is in progress.

|5
|`incremental`
|A required component of the `data` field of a 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.
|===
