maria-developers team mailing list archive

[raolonghui <nanyi607rao@xxxxxxxxx>]

Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> 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+