anchor.diff:  ...
   ----
   
  -Each of these steps reports what the connector is doing to perform the consistent snapshot. For example, Step 6 involves reverse engineering the DDL create statements for the tables that are being captured; Step 7 releases the global write lock just 0.3 seconds after acquiring it, and Step 8 reads all of the rows in each of the tables and reports the time taken and number of rows found. Note that in our example database, the MySQL connector completed its consistent snapshot in just 0.38 seconds. 
  +Each of these steps reports what the connector is doing to perform the consistent snapshot. For example, Step 6 involves reverse engineering the DDL create statements for the tables that are being captured; Step 7 releases the global write lock just 0.3 seconds after acquiring it, and Step 8 reads all of the rows in each of the tables and reports the time taken and number of rows found. Note that in our example database, the MySQL connector completed its consistent snapshot in just 0.38 seconds.
   
   [NOTE]
   ====
  
positive.code: * `before` is an optional field that if present contains the state of the row _before_ the event occurred. The structure will  be described by the `dbserver1.inventory.customers.Value` Kafka Connect schema, which the `dbserver1` connector uses for all rows in the `inventory.customers` table.
  * `after` is an optional field that if present contains the state of the row _after_ the event occurred. The structure is describe by the same `dbserver1.inventory.customers.Value` Kafka Connect schema used in `before`.
  * `source` is a mandatory field that contains a structure describing the source metadata for the event, which in the case of MySQL contains several fields: the connector name, the name of the binlog file where the event was recorded, the position in that binlog file where the event appeared, the row within the event (if there is more than one), the names of the affected database and table, the MySQL thread ID that made the change, whether this event was part of a snapshot, and if available the MySQL server ID, and the timestamp in seconds.
  * `ts_ms` is optional and if present contains the time (using the system clock in the JVM running the Kafka Connect task) at which the connector processed the event. 
  
  If we look at the `payload` of the event's _value_, we can see the information in the event, namely that it is describing that the row was created, contains the `id`, `first_name`, `last_name`, and `email` of the inserted row.
  
  [TIP]
  ====
  You may have noticed that the JSON representations of the events are much larger than the rows they describe. This is because Kafka Connect ships with every event key and value the _schema_ that describes the _payload_. Over time, this structure may change, and having the schemas for the key and value in the event itself makes it much easier for consuming applications to understand the messages, especially as they evolve over time. 
  
  The Debezium MySQL connector constructs these schemas based upon the structure of the database tables. If you use DDL statements to alter the table definitions in the MySQL databases, the connector reads these DDL statements and updates its Kafka Connect schemas. This is the only way that each event is structured exactly like the table from where it originated at the time the event occurred. But the Kafka topic containing all of the events for a single table might have events that correspond to each state of the table definition.
  
  
negative.code: 
  First, Debezium log output makes use of _mapped diagnostic contexts_, or MDC, which allow the log messages to include thread-specific information like the connector type (e.g., `MySQL` in the above log messages after "INFO" or "WARN" fields), the logical name of the connector (e.g., `dbserver1` above), and the connector's activity (e.g., `task`, `snapshot` and `binlog`). Hopefully these will make it easier to understand what is going on in the multi-threaded Kafka Connect service.
  
  The first few lines involve the `task` activity of the connector, and basically report some bookkeeping information such that the connector was started with no prior offset. The new three lines involve the `snapshot` activity of the connector, specifically that a snapshot is being started using the `debezium` MySQL user and the MySQL grants associated with that user.
  
  [TIP]
  ====
  