anchor.diff:  |Semantic type (schema name)
   |Notes
   
  -|`DATE` 
  +|`DATE`
   |`INT32`
   |`org.apache.kafka.connect.data.Date`
   | Represents the number of days since epoch.
   
  -|`TIME[(M)]` 
  +|`TIME[(M)]`
   |`INT64`
   |`org.apache.kafka.connect.data.Time`
  -| Represents the number of milliseconds since midnight, and does not include timezone information. MySQL allows `M` to be in the range 0-6 to store up to microsecond precision, though this mode results in a loss of precision when `M` > 3. 
  -
  -|`DATETIME[(M)]` 
  +| Represents the number of milliseconds since midnight, and does not include timezone information. MySQL allows `M` to be in the range 0-6 to store up to microsecond precision, though this mode results in a loss of precision when `M` > 3.
  +
  +|`DATETIME[(M)]`
   |`INT64`
   |`org.apache.kafka.connect.data.Timestamp`
  -| Represents the number of milliseconds since epoch, and does not include timezone information. MySQL allows `M` to be in the range 0-6 to store up to microsecond precision, though this mode results in a loss of precision when `M` > 3. 
  +| Represents the number of milliseconds since epoch, and does not include timezone information. MySQL allows `M` to be in the range 0-6 to store up to microsecond precision, though this mode results in a loss of precision when `M` > 3.
   
   |=======================
   
  
positive.code: [[reading-the-binlog]]
  === Reading the MySQL binlog
  
  The MySQL connector will typically spend the vast majority of its time reading the binlog of the MySQL server to which it is connected. 
  
  As the MySQL connector reads the binlog, it transforms the binary log events into Debezium _create_, _update_, or _delete_ events that include the position in the binlog (including GTIDs if they are used) where the event was found. The MySQL connector forwards these change events to the Kafka Connect framework (running in the same process), which then synchronously writes them to the appropriate Kafka topic. Kafka Connect uses the term _offset_ for the source-specific position information that Debezium includes with each event, and Kafka Connect periodically records the most recent offset in another Kafka topic. 
  
  When Kafka Connect gracefully shuts down, it stops the connectors, flushes all events to Kafka, and records the last offset received from each connector. Upon restart, Kafka Connect reads the last recorded offset for each connector, and starts the connector from that point. The MySQL connector uses the binlog filename, the position in that file, and the GTIDs (if they are enabled in MySQL server) recorded in its offset to request that MySQL send it the binlog events starting just after that position.
  
  
negative.code: 
  ==== Configuration and startup errors
  
  The connector will fail upon startup, report an error/exception in the log, and stop running when the connector's configuration is invalid, when the connector cannot successfully connect to MySQL using the specified connectivity parameters, or when the connector is restarting from a previously-recorded position in the MySQL history (via binlog coordinates or GTID set) and MySQL no longer has that history available.
  
  In these cases, the error will have more details about the problem and possibly a suggested work around. The connector can be restarted when the configuration has been corrected or the MySQL problem has been addressed.
  
  ==== MySQL becomes unavailable
  
  Once the connector is running, if the MySQL server it has been connected to becomes unavailable for any reason, the connector will fail with an error and the connector will stop. Simply restart the connector when the server is available.
  
  Note that when using GTIDs and a highly available MySQL cluster, you can simply restart the connector immediately, and the connector will connect to a different MySQL server in the cluster, find the location in that server's binlog that represents the last transaction that was processed completely, and start reading the new server's binlog from that location.
  
  