anchor.diff:  
   |=======================
   
  -The connector also supports _pass-through_ configuration properties that are used when creating the Kafka producer and consumer. Specfically, all connector configuration properties that begin with the `database.history.kafka.producer.` prefix are used (without the prefix) when creating the Kafka producer that writes to the database history, and all those that begin with the prefix `database.history.kafka.consumer.` are used (without the prefix) when creating the Kafka consumer that reads the database history upon connector startup.
  +The connector also supports _pass-through_ configuration properties that are used when creating the Kafka producer and consumer. Specifically, all connector configuration properties that begin with the `database.history.kafka.producer.` prefix are used (without the prefix) when creating the Kafka producer that writes to the database history, and all those that begin with the prefix `database.history.kafka.consumer.` are used (without the prefix) when creating the Kafka consumer that reads the database history upon connector startup.
   
   For example, the following connector configuration properties can be used to http://kafka.apache.org/documentation.html#security_configclients[secure connections to the Kafka broker]:
   
  
positive.code: 7. Scans all of the database tables and generates on the appropriate table-specific Kafka topics `CREATE` events for each row.
  8. Commit the transaction.
  9. Release the table-level locks.
  10. Record in the connector offsets that the connector successfully completed the snapsho.
  
  Note that the _table-level locks are held for nearly all of the consistent snapshot_, including the reading of all database table content in step 7. This is very different than when a global read lock can be used, since that is held for a very short period of time. Unfortunately, this is the only way that the MySQL connector can obtain a consistent snapshot, since https://dev.mysql.com/doc/refman/5.7/en/lock-tables-and-transactions.html[releasing the table-level locks implicitly commits any open transaction held by the session]. Since we need the transaction to obtain a consistent snapshot of the database content, we are unable to release the table-level locks until after we've read the data in step 7 and committed our transaction in step 8.
  
  
negative.code: [[enabling-the-binlog]]
  === Enabling the binlog
  
  The MySQL server must be configured to use a _row-level_ binary log, which is described in more detail in the http://dev.mysql.com/doc/refman/5.7/en/replication-options.html[MySQL documentation]. This is most often done in the MySQL server configuration file, and will look similar to the following fragment:
  
  [source]
  ----
  