anchor.diff:  6. Optionally write the DDL changes to the _schema change topic_, including all necessary `DROP ...` and `CREATE ...` DDL statements
   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. Record in the connector offsets that the connector successfully completed the snapsho.
  +9. Record in the connector offsets that the connector successfully completed the snapshot.
   
   The transaction started in step 1 does not prevent other clients from making changes to the tables rows, but will instead provide the connector with a consistent and unchanging view of the data in the tables. However, the transaction does not prevent other clients from applying DDL, which could interfere with the connector's attempt to read the binlog position and the table schemas. So, the connector obtains a global read lock in step 2 to prevent such problems, and it keeps this lock for a very short period of time while it reads the binlog position and table schemas in steps 3 and 4. This global read lock is released in step 5, before the connector performs the bulk of the work of copying the data.
   
  
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: 
  |`database.whitelist`
  |_empty string_
  |An optional comma-separated list of regular expressions that match database names to be monitored; any database name not included in the whitelist will be excluded from monitoring. By default all databases will be monitored. May not be used with `database.blacklist`.
  
  |`database.blacklist`
  |_empty string_
  