maria-developers team mailing list archive

[Nirbhay Choubey <nirbhay@xxxxxxxxxxx>]

Hi Kristian,

On Wed, Jun 29, 2016 at 4:31 AM, Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>
wrote:

> Nirbhay Choubey <nirbhay@xxxxxxxxxxx> writes:
>
> > It wouldn't prevent the user from doing REFRESH_BINARY_LOG, but with
> > wait_for_last_checkpoint_event() added to reload_acl_and_cache(), it
> would
> > ensure every REFRESH_BINARY_LOG (either from user or #2 above) waits
> > until last checkpoint event makes into the new binary log file.
>
> The user's query will wait, but it's not clear how that helps your SST
> (which it seems will be unaffected by the wait in the user's connection
> thread).
>

Lets say we move the wait outside of reload_acl_and_cache() and place it
after #3
and user does a REFRESH_BINARY_LOG (#4) after the wait is over but before
the main thread acquires LOCK_log (#6).

Since there is no wait in reload_acl_and_cache() anymore, user's FLUSH LOGS
will
create a new binary log file with binlog checkpoint event for the
penultimate binlog and
return, leaving it onto binlog background thread to take care of logging
the checkpoint
event for the current (new) binlog file.

Now, if background thread kicks in _after_ the file transfer (as shown in
#9 below), the
same problem occurs - the joiner complains of the missing binlog file.

1> FTWRL
2> reload_acl_and_cache()
3> wait_for_last_checkpoint_event()
    <!-- From another thread -->
    4> FLUSH LOGS (reload_acl_and_cache())
5> SET global innodb_disallow_writes=1
6> mysql_mutex_lock(LOCK_log)
7> file transfer
8> mysql_mutex_unlock(LOCK_log)
    <!-- Binlog background thread -->
    9>  MYSQL_BIN_LOG::write_binlog_checkpoint_event_already_locked()

Best,
Nirbhay