Kristian Nielsen <knielsen@knielsen-hq.org> writes：
Here, the second event is just what you suggested, a rotate event containing the name of the master binlog file.
But I suppose, the issue is if the slaves relay logs are rotated in the middle of a master binlog file, due to max_relay_log_size < max_binlog_size or FLUSH LOGS on the slave? When I tested, I got this:
It indeed would put a rotate event i suggested at relay log head, but not always. if forcely insert a rotate event at relay log head，there would be a redundancy rotate event, which i think not a serious problem though.
One thing to be aware of is that relay log rotates can happen in the middle of a transaction. So you need to check that this is handled correctly. Also, there are some special semantics associated with rotate events, some rotate events are "fake" events generated on the master, and some are synthetic generated on the slaves, it needs to be all handled correctly. But I think it should be possible.
rotate event’s server id can tell us where it is from (master or slave), so the rotate event i suggested should contain master’ server id. i think there will be no difference to SQL Thread whether it is a fake rotate event or a real rotate event from master or a rotate event i suggested. but SQL Thread have to handle carefully a rotate event during a transaction.
I guess you would need to implement some relay log recovery procedure. Because in case of crash, the end of the relay log can be corrupt (partial transaction or event at the end). If we ensure that the SQL thread is also stopped at the time of recovery, that should be not too hard.
i can use xid event to detect a partial transaction, but how to detect a partial event without event checksum, because event checksum only contained in Mariadb 5.5+ and MySQL 5.6+