• Sujatha Sivakumar's avatar
    Bug#13596613:SHOW SLAVE STATUS GIVES WRONG OUTPUT WITH · 03bfc41b
    Sujatha Sivakumar authored
    MASTER-MASTER AND USING SET USE
    
    Problem:
    =======
    In a master-master set-up, a master can show a wrong
    'SHOW SLAVE STATUS' output.
    
    Requirements:
    - master-master
    - log_slave_updates
    
    This is caused when using SET user-variables and then using
    it to perform writes. From then on the master that performed
    the insert will have a SHOW SLAVE STATUS that is wrong and  
    it will never get updated until a write happens on the other
    master. On"Master A" the "exec_master_log_pos" is not
    getting updated.
    
    Analysis:
    ========
    Slave receives a "User_var" event from the master and after
    applying the event, when "log_slave_updates" option is
    enabled the slave tries to write this applied event into
    its own binary log. At the time of writing this event the
    slave should use the "originating server-id". But in the
    above case the sever always logs the  "user var events"
    by using its global server-id. Due to this in a
    "master-master" replication when the event comes back to the
    originating server the "User_var_event" doesn't get skipped.
    "User_var_events" are context based events and they always
    follow with a query event which marks their end of group.
    Due to the above mentioned problem with "User_var_event"
    logging the "User_var_event" never gets skipped where as
    its corresponding "query_event" gets skipped. Hence the
    "User_var" event always waits for the next "query event"
    and the "Exec_master_log_position" does not get updated
    properly.
    
    Fix:
    ===
    `MYSQL_BIN_LOG::write' function is used to write events
    into binary log. Within this function a new object for
    "User_var_log_event" is created and this new object is used
    to write the "User_var" event in the binlog. "User var"
    event is inherited from "Log_event". This "Log_event" has
    different overloaded constructors. When a "THD" object
    is present "Log_event(thd,...)" constructor should be used
    to initialise the objects and in the absence of a valid
    "THD" object "Log_event()" minimal constructor should be
    used. In the above mentioned problem always default minimal
    constructor was used which is incorrect. This minimal
    constructor is replaced with "Log_event(thd,...)".
    
    sql/log_event.h:
      Replaced the default constructor with another constructor
      which takes "THD" object as an argument.
    03bfc41b
log_event.h 119 KB