anchor.diff:  EOF
   ----
   
  -From the log we see that only one table `customers` is snapshotted:
  +From the log we see that as per the `table.include.list` setting only one table is snapshotted, `customers`:
   
   ----
   connect_1    | 2021-09-24 13:38:21,781 INFO   Postgres|dbserver1|snapshot  Snapshotting contents of 1 tables while still in transaction   [io.debezium.relational.RelationalSnapshotChangeEventSource]
  
positive.code:     --topic dbserver1.inventory.orders
  ----
  
  As the last step, we will terminate the deployed systems and close all terminals.
  
  [source,bash]
  ----
  
negative.code: 
  == Summary
  
  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 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.
  