anchor.diff:  |`precise`
   a| Specifies how the connector should handle values for `DECIMAL` and `NUMERIC` columns: `precise` (the default) represents them precisely using `java.math.BigDecimal` values represented in change events in a binary form; or `double` represents them using `double` values, which may result in a loss of precision but will be far easier to use. See link:#decimal-values.
   
  -|`include.schema.changes` 
  +|`include.schema.changes`
   |`true`
   |Boolean value that specifies whether the connector should publish changes in the database schema to a Kafka topic with the same name as the database server ID. Each schema change will be recorded using a key that contains the database name and whose value includes the DDL statement(s). This is independent of how the connector internally records database history. The default is `true`.
   
  -|`max.batch.size` 
  +|`max.batch.size`
   |`2048`
   |Positive integer value that specifies the maximum size of the blocking queue into which change events read from the database log are placed before they are written to Kafka. This queue can provide backpressure to the binlog reader when, for example, writes to Kafka are slower or if Kafka is not available. Events that appear in the queue are not included in the offsets periodically recorded by this connector. Defaults to 2048, and should always be larger than the maximum queue size specified in the `max.queue.size` property.
   
  -|`max.queue.size` 
  +|`max.queue.size`
   |`1024`
   |Positive integer value that specifies the maximum size of each batch of events that should be processed during each iteration of this connector. Defaults to 1024.
   
  -|`poll.interval.ms` 
  +|`poll.interval.ms`
   |`1000`
   |Positive integer value that specifies the number of milliseconds the connector should wait during each iteration for new change events to appear. Defaults to 1000 milliseconds, or 1 second.
   
  -|`connect.timeout.ms` 
  +|`connect.timeout.ms`
   |`30000`
   |A positive integer value that specifies the maximum time in milliseconds this connector should wait after trying to connect to the MySQL database server before timing out. Defaults to 30 seconds.
   
  -|`gtid.source.includes` 
  +|`gtid.source.includes`
   |
   |A comma-separated list of regular expressions that match source UUIDs in the GTID set used to find the binlog position in the MySQL server. Only the GTID ranges that have sources matching one of these include patterns will be used. May not be used with `gtid.source.excludes`.
   
  -|`gtid.source.excludes` 
  +|`gtid.source.excludes`
   |
   |A comma-separated list of regular expressions that match source UUIDs in the GTID set used to find the binlog position in the MySQL server. Only the GTID ranges that have sources matching none of these exclude patterns will be used. May not be used with `gtid.source.includes`.
   |=======================
  
positive.code: 
  ==== Connector is stopped for a duration
  
  If the connector is gracefully stopped, the database can continue to be used and any new changes will be recorded in the MySQL server's binlog. When the connector is restarted, it will resume reading the MySQL binlog where it last left off, recording change events for all of the changes that were made while the connector was stopped. 
  
  A properly configured Kafka cluster is able to https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines[massive throughput]. Kafka Connect is written with Kafka best practices, and given enough resources will also be able to handle very large numbers of database change events. Because of this, when a connector has been restarted after a while, it is very likely to catch up with the database, though how quickly will depend upon the capabilities and performance of Kafka and the volume of changes being made to the data in MySQL.
  
  
negative.code: |Semantic type (schema name)
  |Notes
  
  |`DATE`
  |`INT32`
  |`io.debezium.time.Date`
  | Represents the number of days since epoch.
  
  |`TIME`, `TIME(0)`, `TIME(1)`, `TIME(2)`, `TIME(3)`
  |`INT32`
  |`io.debezium.time.Time`
  | Represents the number of milliseconds past midnight, and does not include timezone information.
  
  |`TIME(4)`, `TIME(5)`, `TIME(6)`
  |`INT64`
  |`io.debezium.time.MicroTime`
  | Represents the number of microseconds past midnight, and does not include timezone information.
  
  |`DATETIME`, `DATETIME(0)`, `DATETIME(1)`, `DATETIME(2)`, `DATETIME(3)`
  |`INT64`
  |`io.debezium.time.Timestamp`
  | Represents the number of milliseconds past epoch, and does not include timezone information.
  