![](https://secure.gravatar.com/avatar/0c65dc0ac6187abaea3a690ac1c1ee5b.jpg?s=120&d=mm&r=g)
Hi Kristian,
On Wed, Jun 29, 2016 at 4:31 AM, Kristian Nielsen
Nirbhay Choubey
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