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