Currently the I/O thread flushes the relay log after writing every event to it. That is slower than 3.23's design where slave reads one event from the socket and executes it immediately without writing it anywhere, as it adds disk writes compared to 3.23. The reason to have a relay log in 4.0 was for the case when the slave lags behind the master: if slave is one hour of execution behind master, and master burns before this hour gap has been closed, slave will never be able to be up-to-date (it didn't have time to fetch binlog, as it fetches/executes/fetches/executes); with a relay log, slave can quickly fetch all the binlog gap from master, so that if master soon crashes, its binlog is safe and slave can become up-to-date. But it was not intended to slow down the normal case where slave is close to master (in terms of binlog lag). In this normal case, the I/O and SQL thread could often be writing/reading the same in-memory tail of the relay log, and so there is no need to write this tail to disk (like how it was in 3.23). In other words, the proposal is to change the design: - slave I/O thread should not flush the relay log after writing every event - relay log should still be IO_CACHE-like (that is, an IO_CACHE or a new variant of it). - slave I/O thread writes to the relay log (IO_CACHE); slave SQL thread "prunes" the IO_CACHE buffer as it advances into it (i.e. executed events are wiped out from the buffer, won't go to disk); the buffer's beginning can thus be re-used by the slave I/O thread, it's a circular buffer - as a result, if both threads stay close there is never any disk write. - but if a lag appears, the IO_CACHE buffer becomes full and then overflows to the disk relay log, then the slave SQL thread goes to read this disk relay log; as the SQL thread catches up it "enters again" the IO_CACHE buffer, and so the disk relay log is not written anymore and so is deleted. - the disk relay log becomes more of a temporary file, unparsable (as missing events or even pieces of events), just a temp file backing the IO_CACHE sometimes. - in case of crash, as the relay log is unreliable (missing parts etc), we just restart fetching from the master from the last *executed* position. - we *might* want to provide an option to give the old behaviour (relay log a parsable log, flushed after each event), if there is an interest (is there?).