Hi kristian,
currently, a relaylog is immediately purged after it be completely replayed
(relay_log_purge=1). and if IO thread crashes, we should delete all relay logs
and fetch master binlog again from exec_master_log_pos/file
(relay_log_purge=ON). I think that make a greap waste of disk IO especially to
cloud disk. The critical problem is that there is no method to know the
original binlog filename on master of a event in relaylog.
Actually we can know a relaylog event's original binlog offset on master, but
we can't know the original binlog filename. so why not forcely add a rotate
event or any other new type event which contained the original master binlog
filename at begin of a relay log. as I know two different master binlogs'
events wouldn't contained in one relay log, so the original binlog filename of
a relaylog's events is only one.
If we want to know a relaylog event's original binlog filename/position, we can
get original filename from the begin of relaylog, and get original binlog
offset from event's "end log pos". oppositely, if we know a event's binlog
filename/end positon on master, wo also can quickly find it in slave's relay
log.
That can make many benefits, firstly no need to delete all relay logs and fetch
master binlogs again when IO thread crashed, because we can get exact last
read_master_log_filename/position from last relay log. secondly, there is no
need to use GTID in 1 vs n replication failover Scenario (Gtid must set
log_slave_updates=ON in mysql 5.6, which increase disk IO load), if master
crashes, other slaves can get lost events for the newest slave's relay log, as
long as relay log don't be purged, then promotes the newest slave to master.
Thanks.
2014-11-26
nanyi607rao
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
