Events

class pymysqlreplication.event.BeginLoadQueryEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]
Attributes:
file_id block-data
class pymysqlreplication.event.ExecuteLoadQueryEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]
Attributes:

slave_proxy_id execution_time schema_length error_code status_vars_length

file_id start_pos end_pos dup_handling_flags

class pymysqlreplication.event.GtidEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

GTID change in binlog event

gtid

GTID = source_id:transaction_id Eg: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23 See: http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-concepts.html

class pymysqlreplication.event.HeartbeatLogEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

A Heartbeat event Heartbeats are sent by the master only if there are no unsent events in the binary log file for a period longer than the interval defined by MASTER_HEARTBEAT_PERIOD connection setting.

A mysql server will also play those to the slave for each skipped events in the log. I (baloo) believe the intention is to make the slave bump its position so that if a disconnection occurs, the slave only reconnects from the last skipped position (see Binlog_sender::send_events in sql/rpl_binlog_sender.cc). That makes 106 bytes of data for skipped event in the binlog. this is also the case with GTID replication. To mitigate such behavior, you are expected to keep the binlog small (see max_binlog_size, defaults to 1G). In any case, the timestamp is 0 (as in 1970-01-01T00:00:00).

Attributes:
ident: Name of the current binlog
class pymysqlreplication.event.IntvarEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]
Attributes:
type value
class pymysqlreplication.event.QueryEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

This evenement is trigger when a query is run of the database. Only replicated queries are logged.

class pymysqlreplication.event.RotateEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

Change MySQL bin log file

Attributes:
position: Position inside next binlog next_binlog: Name of next binlog file
class pymysqlreplication.event.XidEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

A COMMIT event

Attributes:
xid: Transaction ID for 2PC

Row events

This events are send by MySQL when data are modified.

class pymysqlreplication.row_event.DeleteRowsEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

This event is trigger when a row in the database is removed

For each row you have a hash with a single key: values which contain the data of the removed line.

class pymysqlreplication.row_event.TableMapEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

This evenement describe the structure of a table. It’s sent before a change happens on a table. An end user of the lib should have no usage of this

class pymysqlreplication.row_event.UpdateRowsEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

This event is triggered when a row in the database is changed

For each row you got a hash with two keys:
  • before_values
  • after_values

Depending of your MySQL configuration the hash can contains the full row or only the changes: http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_binlog_row_image

class pymysqlreplication.row_event.WriteRowsEvent(from_packet, event_size, table_map, ctl_connection, **kwargs)[source]

This event is triggered when a row in database is added

For each row you have a hash with a single key: values which contain the data of the new line.