anchor.diff:  Value: {"type":"execute-snapshot","data": {"data-collections": ["inventory.orders"], "type": "INCREMENTAL"}}
   ----
   
  +The MySQL connector's config has a new https://debezium.io/documentation/reference/stable/connectors/mysql.html#mysql-property-signal-kafka-topic[`signal.kafka.topic`] property. The topic has to have one partition and the delete retention policy.
  +
  +A separate thread retrieves the signal messages from the Kafka topic. The key of the Kafka message needs to match the connector's name as set in `database.server.name`. The connector will skip events that don't correspond to the connector's name with a log entry. The message key check allows reusing a signal topic for multiple connectors.
  +
  +The connector's offsets include incremental snapshot context when an incremental snapshot is running. The read-only implementation adds the Kafka signal offset to the incremental snapshot context. Keeping track of the offset allows it not to miss or double process the signal when the  connector restarts.
  +
   However, it's not required to use Kafka to execute a read-only incremental snapshot and the default `execute-snapshot` signal written into a signaling table will also work.
  -
  -A connector's config has a new `signal.kafka.topic` property. The topic has to have one partition and the delete retention policy.
  -
  -A separate thread retrieves the signal messages from the Kafka topic. The key of the Kafka message needs to match the connector's name as set in `database.server.name`. The connector will skip events that don't correspond to the connector's name with a log entry. The message key check allows reusing a signal topic for multiple connectors.
  -
  -The connector's offsets include incremental snapshot context when an incremental snapshot is running. The read-only implementation adds the Kafka signal offset to the incremental snapshot context. Keeping track of the offset allows it not to miss or double process the signal when the  connector restarts.
  -
  -== Schema changes during incremental snapshot
  -The Debezium MySQL connector https://debezium.io/documentation/reference/stable/connectors/mysql.html#mysql-property-incremental-snapshot-allow-schema-changes[allows schema changes during an incremental snapshot]. The connector will detect schema change during an incremental snapshot and re-select a current chunk to avoid locking DDLs.
  +Going forward, a REST API for triggering ad-hoc incremental snapshots may be envisioned as well,
  +either exposed through Debezium Server, or as an additional REST resource deployed to Kafka Connect.
  +
  +== Schema changes during incremental snapshots
  +
  +The Debezium MySQL connector link:/documentation/reference/stable/connectors/mysql.html#mysql-property-incremental-snapshot-allow-schema-changes[allows schema changes during an incremental snapshot]. The connector will detect schema change during an incremental snapshot and re-select a current chunk to avoid locking DDLs.
   
   _Note that changes to a primary key are not supported and can cause incorrect results if performed during an incremental snapshot._
   
  -Historized connectors like MySQL parse Data Definition Language (DDL) events such as `ALTER TABLE` from the binlog stream. Connectors keep an in-memory representation of each table's schema and use those schemas to produce the appropriate change events.
  +Historized Debezium connectors like the MySQL one parse Data Definition Language (DDL) events such as `ALTER TABLE` from the binlog stream. Connectors keep an in-memory representation of each table's schema and use those schemas to produce the appropriate change events.
   
   The incremental snapshot implementation uses binlog schema twice:
   
   1. at the moment of the chunk selection from the database
   2. at the moment of the chunk insertion to the binlog stream
   
  -The chunk’s schema has to match the binlog schema at both times. Let’s explore how the algorithm achieves matching schemas in detail.
  -
  -==== Matching chunk and binlog schema on selection
  +The chunk's schema has to match the binlog schema at both times. Let's explore how the algorithm achieves matching schemas in detail.
  +
  +=== Matching chunk and binlog schema on selection
   
   When the incremental snapshot queries a database, the rows have the table's latest schema. If the binlog stream is behind, the in-memory schema may be different from the latest schema. The solution is to wait for the connector to receive the DDL event in the binlog stream. After that, the connector can use the cached table's structure to produce the correct incremental snapshot events.
   
  
positive.code: --topic dbserver1.inventory.orders
  ----
  
  Now let’s start an incremental ad-hoc snapshot by sending a signal. The snapshot messages for the `orders` table are delivered to the `dbserver1.inventory.orders` topic. Messages for the `customers` table are delivered without interruption.
  
  [source,bash]
  ----
  
negative.code: ----
  
  == Conclusion
  Debezium is an excellent change data capture tool under active development, and it's a pleasure to be a part of its community. We're excited to use incremental snapshots in production here at Shopify. If you have similar database usage restrictions, check out the read-only incremental snapshots feature. Many thanks to my team and the Debezium team without whom this project wouldn't happen.
  