Skip to content
  • Venkatesh Duggirala's avatar
    739ac254
    BUG#20928790 SHOW BINLOG EVENTS COMPLETELY LOCKS DOWN WRITES TO BINLOG, HENCE TRANSACTIONS. · 739ac254
    Venkatesh Duggirala authored
    Problem: While a `SHOW BINLOG EVENTS` is executing, any parallel transaction
    is blocked.
    
    Analysis:
    ========
    
    In the good old days, replication was coded such that every access to the
    binlog was protected by a mutex. So `Show binlog events` also acquires
    LOCK_log mutex and loops through the file to print the events in order not
    to get conflicts with any ongoing operations. While this operation is happening,
    all binlog write operation which are trying to acquire LOCK_log mutex are blocked.
    Hence all the parallel transactions are blocked.
    
    When 'show binlog events' opens the file to read the events from it,
    the file is locked and if there is parallel purge operation to delete
    this file that operation will fail with a warning that "file 'xyz' was
    not purged because it was being read by another thread". Hence
    server does not require to acquire a lock while iterating through
    the events in the file.
    
    Fix:
    ====
    Acquire LOCK_log only for the duration to calculate the log's end
    position. LOCK_log should be acquired even while we are checking
    whether the log is active log or not. Once 'end_pos' is calculated
    for the given binary log, the events are displayed till that position.
    Since we do not acquire LOCK_log (acquired only for less duration),
    parallel transactions will not be blocked for large duration.
    739ac254
    BUG#20928790 SHOW BINLOG EVENTS COMPLETELY LOCKS DOWN WRITES TO BINLOG, HENCE TRANSACTIONS.
    Venkatesh Duggirala authored
    Problem: While a `SHOW BINLOG EVENTS` is executing, any parallel transaction
    is blocked.
    
    Analysis:
    ========
    
    In the good old days, replication was coded such that every access to the
    binlog was protected by a mutex. So `Show binlog events` also acquires
    LOCK_log mutex and loops through the file to print the events in order not
    to get conflicts with any ongoing operations. While this operation is happening,
    all binlog write operation which are trying to acquire LOCK_log mutex are blocked.
    Hence all the parallel transactions are blocked.
    
    When 'show binlog events' opens the file to read the events from it,
    the file is locked and if there is parallel purge operation to delete
    this file that operation will fail with a warning that "file 'xyz' was
    not purged because it was being read by another thread". Hence
    server does not require to acquire a lock while iterating through
    the events in the file.
    
    Fix:
    ====
    Acquire LOCK_log only for the duration to calculate the log's end
    position. LOCK_log should be acquired even while we are checking
    whether the log is active log or not. Once 'end_pos' is calculated
    for the given binary log, the events are displayed till that position.
    Since we do not acquire LOCK_log (acquired only for less duration),
    parallel transactions will not be blocked for large duration.
Loading