anchor.diff:  The `source` field is the exact same structure that appears in normal data change events written to table-specific topics. You can use the contents of this field to correlate the events on different topics.
   ====
   
  -As mentioned above, each schema change event will contain one or more DDL statements that apply to a single database. What happens if a client submits a series of DDL statements that apply to _multiple_ databases (e.g., perhaps they use fully-qualified names)? If MySQL applies those statements atomically (e.g., as a single transaction), then the connector will take those DDL statements _in order_, group them by the affected database, and then create a schema change event for each of those groups. On the other hand, if MySQL applies those statements individually, then the connector will create a separate schema change event for each statement. 
  +As mentioned above, each schema change event will contain one or more DDL statements that apply to a single database. What happens if a client submits a series of DDL statements that apply to _multiple_ databases (e.g., perhaps they use fully-qualified names)? If MySQL applies those statements atomically (e.g., as a single transaction), then the connector will take those DDL statements _in order_, group them by the affected database, and then create a schema change event for each of those groups. On the other hand, if MySQL applies those statements individually, then the connector will create a separate schema change event for each statement.
   
   [[events]]
   === Events
  
positive.code: |Default
  |Description
  
  |`name` 
  |
  |Unique name for the connector. Attempting to register again with the same name will fail. (This property is required by all Kafka Connect connectors.)
  
  |`connector.class` 
  |
  |The name of the Java class for the connector. Always use a value of `io.debezium.connector.mysql.MySqlConnector` for the MySQL connector.
  
  |`tasks.max` 
  |`1`
  |The maximum number of tasks that should be created for this connector. The MySQL connector always uses a single task and therefore does not use this value, so the default is always acceptable.
  
  |`database.hostname` 
  |
  |IP address or hostname of the MySQL database server.
  
  |`database.port` 
  |`3306`
  |Integer port number of the MySQL database server.
  
  |`database.user` 
  |
  |Name of the MySQL database to use when when connecting to the MySQL database server.
  
  |`database.password` 
  |
  |Password to use when when connecting to the MySQL database server.
  
  |`database.server.name` 
  |_host:port_
  |Logical name that identifies and provides a namespace for the particular MySQL database server/cluster being monitored. The logical name should be unique across all other connectors, since it is used as a prefix for all Kafka topic names eminating from this connector. Defaults to '_host_:_port_', where _host_ is the value of the `database.hostname` property and _port_ is the value of the `database.port` property, though we recommend using an explicit and meaningful logical name.
  
  |`database.server.id` 
  |_random_
  |A numeric ID of this database client, which must be unique across all currently-running database processes in the MySQL cluster. This connector joins the MySQL database cluster as another server (with this unique ID) so it can read the binlog. By default, a random number is generated between 5400 and 6400, though we recommend setting an explicit value.
  
  |`database.history.kafka.topic` 
  |
  |The full name of the Kafka topic where the connector will store the database schema history.
  
  |`database.history.kafka.bootstrap.servers` 
  |
  |A list of host/port pairs that the connector will use for establishing an initial connection to the Kafka cluster. This connection will be used to retrieving database schema history previously stored by the connector, and for writing each DDL statement read from the source database. This should point to the same Kafka cluster used by the Kafka Connect process.
  
  |`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 monitoried. May not be used with `database.blacklist`.
  
  |`database.blacklist` 
  |_empty string_
  |An optional comma-separated list of regular expressions that match database names to be excluded from monitoring; any database name not included in the blacklist will be monitored. May not be used with `database.whitelist`.
  
  |`table.whitelist` 
  |_empty string_
  |An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables to be monitored; any table not included in the whitelist will be excluded from monitoring. Each identifer is of the form _databaseName_._tableName_. By default the connector will monitor every non-system table in each monitored database. May not be used with `table.blacklist`.
  
  |`table.blacklist` 
  |_empty string_
  |An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables to be excluded from monitoring; any table not included in the blacklist will be monitored. Each identifer is of the form _databaseName_._tableName_. May not be used with `table.whitelist`.
  
  |`column.blacklist` 
  |_empty string_
  |An optional comma-separated list of regular expressions that match the fully-qualified names of columns that should be excluded from change event message values. Fully-qualified names for columns are of the form _databaseName_._tableName_._columnName_, or _databaseName_._schemaName_._tableName_._columnName_.
  
  |`column.truncate.to._length_.chars` 
  |_n/a_
  |An optional comma-separated list of regular expressions that match the fully-qualified names of character-based columns whose values should be truncated in the change event message values if the field values are longer than the specified number of characters. Multiple properties with different lengths can be used in a single configuration, although in each the length must be a positive integer. Fully-qualified names for columns are of the form _databaseName_._tableName_._columnName_, or _databaseName_._schemaName_._tableName_._columnName_.
  
  |`column.mask.with._length_.chars` 
  |_n/a_
  |An optional comma-separated list of regular expressions that match the fully-qualified names of character-based columns whose values should be replaced in the change event message values with a field value consisting of the specified number of asterisk (`*`) characters. Multiple properties with different lengths can be used in a single configuration, although in each the length must be a positive integer. Fully-qualified names for columns are of the form _databaseName_._tableName_._columnName_, or _databaseName_._schemaName_._tableName_._columnName_.
  
  |`time.precision.mode` 
  |`adaptive`
  a| Time, date, and timestamps can be represented with different kinds of precisions, including: `adaptive` (the default) captures the time and timestamp values exactly as in the database uses either millisecond, microsecond, or nanosecond precision values based on the database column's type; or `connect` always represents time and timestamp values using Kafka Connect's built-in representations for Time, Date, and Timestamp, which uses millisecond precision regardless of the database columns' precision. See link:#temporal-values.
  
  
negative.code: |Default
  |Description
  
  |`connect.keep.alive`
  |`true`
  |A boolean value that specifies whether a separate thread should be used to ensure the connection to the MySQL server/cluster is kept alive.
  
  |`table.ignore.builtin`
  |`true`
  |Boolean value that specifies whether built-in system tables should be ignored. This applies regardless of the table whitelist or blacklists. By default system tables are excluded from monitoring, and no events are generated when changes are made to any of the system tables.
  
  |`database.history.kafka.recovery.poll.interval.ms`
  |`100`
  |An integer value that specifies the maximum number of milliseconds the connector should wait during startup/recovery while polling for persisted data. The default is 100ms.
  
  |`database.history.kafka.recovery.attempts`
  |`4`
  |The maximum number of times that the connector should attempt to read persisted history data before the connector recovery fails with an error. The maximum amount of time to wait after receiving no data is `recovery.attempts` x `recovery.poll.interval.ms`.
  
  
  |`snapshot.mode`
  |`initial`
  |Specifies the criteria for running a snapshot upon startup of the connector. The default is `initial`, and specifies the connector can run a snapshot only when no offsets have been recorded for the logical server name. The `when_needed` option specifies that the connector run a snapshot upon startup whenever it deems it necessary (when no offsets are available, or when a previously recorded offset specifies a binlog location or GTID that is not available in the server). The `never` option specifies that the connect should never use snapshots and that upon first startup with a logical server name the connector should read from the beginning of the binlog; this should be used with care, as it is only valid when the binlog is guaranteed to contain the entire history of the database. If you don't need the topics to contain a consistent snapshot of the data but only need them to have the changes since the connector was started, you can use the `schema_only` option, where the connector only snapshots the schemas (not the data).
  
  |`snapshot.minimal.locks`
  |`true`
  |Controls how long the connector holds onto the global MySQL read lock (preventing any updates to the database) while it is performing a snapshot. The default is `true`, meaning the connector holds the global read lock for just the initial portion of the snapshot while the connector reads the database schemas and other metadata. The remaining work in a snapshot involves selecting all rows from each table, and this can be done in a consistent fashion using the `REPEATABLE READ` transaction even when the global read lock is no longer held and while other
  MySQL clients are updating the database. However, in some cases where clients are submitting operations that MySQL excludes from `REPEATABLE READ` semantics, it may be desirable to _block all writes_ for the entire duration of the snapshot. In only such cases, set this property to `false`.
  