1

I am experimenting with the mysql-binlog-connector-java library for Java. When running sample queries and observing the sequence of replicated events I noticed that the ROTATE event is received twice (with only slight difference). I was unable to find any information regarding this.

I am curious what is the purpose of such behaviour?

mysqlbinlog output:

BINLOG '
NBOeVxMBAAAAMAAAAOEPAAAAAEYAAAAAAAEABHRlc3QAA2ZvbwADAwMDAAV0++x3
NBOeVx4BAAAASgAAACsQAAAAAEYAAAAAAAEAAgAD//gBAAAAAgAAAAEAAAD4AQAAAAEAAAABAAAA
+AEAAAABAAAAAQAAAEGalIw=
'/*!*/;
# at 4139
#160731 15:03:16 server id 1  end_log_pos 4170 CRC32 0xe46a11ca     Xid = 102
COMMIT/*!*/;
# at 4170
#160731 15:03:16 server id 1  end_log_pos 4218 CRC32 0x49f876e3     Rotate to mysqld-bin.000865  pos: 4
# at 4
#700101  0:00:00 server id 1  end_log_pos 0 CRC32 0xa4f216d7    Rotate to mysqld-bin.000865  pos: 4
# at 4
#160731 15:03:16 server id 1  end_log_pos 120 CRC32 0x572d4724  Start: binlog v 4, server v 5.6.31-log created 160731 15:03:16
BINLOG '
NBOeVw8BAAAAdAAAAHgAAAAAAAQANS42LjMxLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAASRH
LVc=

mysql-binlog-connector-java output:

Event{header=EventHeaderV4{timestamp=1469977396000, eventType=ROTATE, serverId=1, headerLength=19, dataLength=29, nextPosition=4218, flags=0}, data=RotateEventData{binlogFilename='mysqld-bin.000865', binlogPosition=4}}
Event{header=EventHeaderV4{timestamp=0, eventType=ROTATE, serverId=1, headerLength=19, dataLength=29, nextPosition=0, flags=32}, data=RotateEventData{binlogFilename='mysqld-bin.000865', binlogPosition=4}}
1

The first one is real -- it is actually the last event in mysqld-bin.000865 at offset 4170, written by the master when that log was closed.

The second one is "fake," as evidenced by all the values set to 0. It is injected into the stream by the master when the binlog is being streamed out. You'll also see one of these at the very beginning of the replication stream. This event is essentially telling the slave that the next data it will receive is being read from that file at that position.

In the event of a master shutdown or crash, the last event in the prior log will not be a ROTATE event... but essentially, normally, this second event is just reuse of the same data structure to communicate that the master is actually switching the stream source to the next file, while the prior event is the record of what the master was intending to do while the original logs were being written.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.