Control snapshots without restarting a connector.
Signals let an operator request an initial data load from a running source connector. GIFRÖST supports starting an ad hoc snapshot for selected tables and stopping an incremental snapshot that is already in progress.
What Signals are
A signal contains an identifier, an operation name such as execute-snapshot or
stop-snapshot, and the data required to perform the operation. The connector reads
the request from an enabled signaling channel and performs it without being restarted.
Starts a snapshot for the selected tables in Incremental or Blocking mode.
Stops the current incremental snapshot or removes selected tables from it. It cannot stop a blocking snapshot.
Source systems
Supported source connectors
Signals are available for the Debezium source connectors listed below.
IBM Db2
Debezium Db2 connector
Informix
Debezium Informix connector
MongoDB
Debezium MongoDB connector
MySQL
Debezium MySQL connector
Oracle
Debezium Oracle connector
PostgreSQL
Debezium PostgreSQL connector
SQL Server
Debezium SQL Server connector
Signaling channels
Select the channel used to pass the signal to the running connector in the Signal Channel field.
SOURCE
The signal is inserted as a record in a signaling table in the source database. The connector
reads the change and performs the requested operation. The table must contain id, type, and
data columns.
CREATE TABLE debezium_signals (
id VARCHAR(42) PRIMARY KEY,
type VARCHAR(32) NOT NULL,
data VARCHAR(2048) NULL
);
id — a unique signal identifier, for example a UUID. It can also identify the signal in connector logs.type — the requested operation, for example execute-snapshot or stop-snapshot.data — operation data in JSON format, including the snapshot type and data collections.KAFKA
The signal is sent to the Kafka topic configured for the connector. Enable kafka in
signal.enabled.channels and set the topic in signal.kafka.topic.
test_connector
{
"type": "execute-snapshot",
"data": {
"type": "incremental",
"data-collections": ["schema1.table1"]
}
}
The Kafka message key must equal the connector's topic.prefix value.
In a standard configuration the connector still uses signal.data.collection to write watermark
markers, so enable both kafka and source. The exception is a MySQL or PostgreSQL connector
configured for read-only incremental snapshots with read.only=true.
Configure the channels
Channel settings are available under Connectors → Source → Signal.
| Channel | Required settings |
|---|---|
| SOURCE | Select source in Enabled channels names (signal.enabled.channels) and enter the fully qualified signaling table name in Signaling data collection (signal.data.collection). |
| KAFKA | Select kafka, verify signal.kafka.bootstrap.servers, and enter the topic in Signal kafka topic (signal.kafka.topic). |
FILE and JMX can be visible in the interface, but they are not supported in the current version.
Configure a signal
Select SOURCE or KAFKA and let GIFRÖST validate the connector configuration.
Choose EXECUTE_SNAPSHOT or STOP_SNAPSHOT and the available snapshot mode.
Browse replicated tables, review the selection, or enter full names manually.
Review the generated SQL or Kafka message, then send the signal.
Signal Type and Signal Mode
| Mode | Behavior | When to use it |
|---|---|---|
Incremental | Reads data in chunks while the connector continues to capture transaction-log changes. The default chunk size is 1024. | Use when ongoing change streaming must continue during the snapshot. |
Blocking | Pauses change streaming, performs a snapshot similar to an initial snapshot, and then resumes streaming. | Use when a temporary pause in streaming is acceptable. |
Configure the chunk size under Connectors → Source → Snapshot → Incremental snapshot chunk size.
EXECUTE_SNAPSHOT supports Incremental and Blocking modes. STOP_SNAPSHOT supports only Incremental.
Stopping an active incremental snapshot produces ABORTED. Sending STOP_SNAPSHOT after completion
does not change the completed operation.
Credential
Credential is the saved connection profile GIFRÖST uses to insert a signal into the table in
signal.data.collection. Its database user must have write permission on that table. The field is
required only for SOURCE. Select NEXT after completing the channel configuration.
Validation and REPAIR
If the connector configuration does not meet the selected channel's requirements, GIFRÖST shows an error. For supported errors, select Click here to resolve to review valid settings and required changes. REPAIR can automatically correct some settings.
Automatic repair adapts the connector to Signals requirements, but it does not guarantee that every user-specific requirement is preserved. Always review the final connector configuration.
Select tables
| Connector | Required data collection format |
|---|---|
| PostgreSQL, Db2 | schemaName.tableName |
| MySQL | databaseName.tableName |
| Oracle, SQL Server, Informix | databaseName.schemaName.tableName |
| MongoDB | databaseName.collectionName |
Select NEXT after choosing the tables.
Preview and send
Before sending, GIFRÖST displays a channel-specific preview:
- For SOURCE, SQL preview (signal INSERT) shows the
INSERTstatement forsignal.data.collection. - For KAFKA, Kafka message preview shows the key and value for
signal.kafka.topic. - Copy copies the generated command so it can be executed manually.
Select SEND SIGNAL to send the request. If the same signal has just been sent, the button is shown as SEND AGAIN. Signal confirmed contains details returned after receipt. For Kafka it can also contain the topic, partition, offset, and send timestamp. Use VIEW SIGNAL HISTORY to review previously sent signals.
Monitor the snapshot in Notifications
| Status | Meaning |
|---|---|
STARTED | The snapshot operation has started. |
IN_PROGRESS | A table is being processed. |
TABLE_SCAN_COMPLETED | One table scan has completed; scanned_collection identifies it. |
COMPLETED | The complete snapshot operation has finished. |
ABORTED | The snapshot operation has been interrupted. |
Tables covered by one signal share an operation identifier. Each table produces a separate
TABLE_SCAN_COMPLETED, followed by one COMPLETED for the complete snapshot.
In the current version, data_collections changes during execution. The first notification lists
all selected tables; later notifications omit completed tables. Incremental snapshot records can
also be identified in the table topic by op = r and source.snapshot = incremental.