anchor.diff:  
   == Summary
   
  -In this blog post, we have discussed the motivation for incremental snapshotting.
  +In this blog post, we have discussed the motivation for the notion of incremental snapshotting,
  +as introduced by the DBLog paper.
   We have reviewed the methods used in the past to achieve the described functionality.
  -Then we dived into the deep waters of the implementation and in the end, we tried to use it live.
  -
  -We hope you will find the incremental snapshotting useful and we look forward to your feedback, experiences, and use cases.
  +Then we dived into the deep waters of the implementation of this novel snapshotting approach in Debezium, and in the end we tried to use it live.
  +
  +We hope you will find incremental snapshotting useful and we look forward to your feedback, experiences, and use cases.
  +In a future blog post, we'll talk about the support for incremental snaphots of read-only databases
  +(supported by the Debezium MySQL connector as of version 1.7) and how to trigger ad-hoc snapshots using a Kafka topic as the means of signalling instead of a database table.
  
positive.code: 
  +++<!-- more -->+++
  
  == Why?
  
  One of the biggest pain points in Debezium since its inception was the sup-optimal support for changes to the captured tables list.
  As a user, you create a new connector with a list of tables to be captured
  
negative.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.
  
  