anchor.diff:  [[mysql-master-and-slave]]
   === MySQL master and slave
   
  -http://dev.mysql.com/doc/refman/5.7/en/replication-solutions.html[MySQL replication] can be used to set up a cluster of MySQL instances, where one of the MySQL server instances is considered the _master_ and the other(s) a _slave_. Topologies can include single master with single slave, single master with multiple slaves, and multiple masters with multiple slaves. Which you choose will depend on your requirements, your backup and recovery strategy, and how you are scaling MySQL to handle large data volumes and queries. 
  -
  -To use the MySQL connector with one of these topologies, the connector can follow one of the masters or one of the slaves (if that slave has its binlog enabled), but the connector will see only those changes in the cluster that are visible to that server. Generally, this is not a problem except for the multi-master topologies. 
  +http://dev.mysql.com/doc/refman/5.7/en/replication-solutions.html[MySQL replication] can be used to set up a cluster of MySQL instances, where one of the MySQL server instances is considered the _master_ and the other(s) a _slave_. Topologies can include single master with single slave, single master with multiple slaves, and multiple masters with multiple slaves. Which you choose will depend on your requirements, your backup and recovery strategy, and how you are scaling MySQL to handle large data volumes and queries.
  +
  +To use the MySQL connector with one of these topologies, the connector can follow one of the masters or one of the slaves (if that slave has its binlog enabled), but the connector will see only those changes in the cluster that are visible to that server. Generally, this is not a problem except for the multi-master topologies.
   
   The connector records its position in the server's binlog, which is different on each server in the cluster. Therefore, the connector will need to follow just one MySQL server instance. If that server fails, it must be restarted or recovered before the connector can continue.
   
  
positive.code: * `before` is an optional field that if present contains the state of the row _before_ the event occurred. The structure will  be described by the `mysql-server-1.inventory.customers.Value` Kafka Connect schema, which the `mysql-server-1` connector uses for all rows in the `inventory.customers` table.
  * `after` is an optional field that if present contains the state of the row _after_ the event occurred. The structure is describe by the same `mysql-server-1.inventory.customers.Value` Kafka Connect schema used in `before`.
  * `source` is a mandatory field that conains a structure describing the source metadata for the event, which in the case of MySQL contains several fields: the connector name, the name of the binlog file where the event was recorded, the position in that binlog file where the event appeared, the row within the event (if there is more than one), whether this event was part of a snapshot, and if available the MySQL server ID, and the timestamp in seconds.
  * `ts_ms` is optional and if present contains the time (using the system clock in the JVM running the Kafka Connect task) at which the connector processed the event. 
  
  And of course, the _schema_ portion of the event message's value contains a schema that decribes tihs envelope structure and the nested fields within it.
  
  
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`.
  