Package io.debezium.connector.mysql

Class SourceInfo

java.lang.Object
io.debezium.connector.AbstractSourceInfo
io.debezium.connector.common.BaseSourceInfo
io.debezium.connector.binlog.BinlogSourceInfo
io.debezium.connector.mysql.SourceInfo
@NotThreadSafe public final class SourceInfo extends BinlogSourceInfo
Information about the source of information, which includes the position in the source binary log we have previously processed.

The source partition information describes the database whose log is being consumed. Typically, the database is identified by the host address port number of the MySQL server and the name of the database. Here's a JSON-like representation of an example database: 

 {
     "server" : "production-server"
 }

The offset includes the binlog filename, the position of the first event in the binlog, the number of events to skip, and the number of rows to also skip.

Here's a JSON-like representation of an example offset: 

 {
     "server_id": 112233,
     "ts_sec": 1465937,
     "gtid": "db58b0ae-2c10-11e6-b284-0242ac110002:199",
     "file": "mysql-bin.000003",
     "pos" = 990,
     "event" = 0,
     "row": 0,
     "snapshot": true
 }

The "gtids" field only appears in offsets produced when GTIDs are enabled. The "snapshot" field only appears in offsets produced when the connector is in the middle of a snapshot. And finally, the "ts" field contains the seconds since Unix epoch (since Jan 1, 1970) of the MySQL event; the message envelopes also have a timestamp, but that timestamp is the milliseconds since since Jan 1, 1970.

Each change event envelope also includes the source struct that contains MySQL information about that particular event, including a mixture the fields from the binlog filename and position where the event can be found, and when GTIDs are enabled the GTID of the transaction in which the event occurs. Like with the offset, the "snapshot" field only appears for events produced when the connector is in the middle of a snapshot. Note that this information is likely different than the offset information, since the connector may need to restart from either just after the most recently completed transaction or the beginning of the most recently started transaction (whichever appears later in the binlog).

Here's a JSON-like representation of the source for the metadata for an event that corresponds to the above partition and offset: 

 {
     "name": "production-server",
     "server_id": 112233,
     "ts_sec": 1465937,
     "gtid": "db58b0ae-2c10-11e6-b284-0242ac110002:199",
     "file": "mysql-bin.000003",
     "pos" = 1081,
     "row": 0,
     "snapshot": true,
     "thread" : 1,
     "db" : "inventory",
     "table" : "products"
 }
Author:
Randall Hauch