Skip to content
  • Alfranio Correia's avatar
    93a5a834
    BUG#11763471 BUG#56184 Rolled back transaction without non-transactional table... · 93a5a834
    Alfranio Correia authored
    BUG#11763471 BUG#56184 Rolled back transaction without non-transactional table updated was binlogged
    BUG#11763126 BUG#55798 Slave SQL retry on transaction inserts extra data into non-transaction table
    
    BUG#56184
    ---------
    The transaction modified non-transactional table will be binlogged with
    ROLLBACK if it rolls back on master. It includes the case that all
    statements which modified non-transactional table are binlogged outside
    the transaction. Example:
    
      BEGIN
      INSERT INTO trans-table;
      INSERT INTO non-trans-table;
      ROLLBACK
    
    This will be binlogged as:
    
      BEGIN
      INSERT INTO non-trans-table;
      COMMIT
      BEGIN
      INSERT INTO trans-table;
      ROLLBACK;
    
    All statements in the second binlogged transaction modify only transactional
    tables and are rolled back safely on master. So the second transaction should
    not be binlogged.
    
    After 5.5, there are two caches for binary logs, a transactional cache and a
    statement cache. When executing a transaction, statements that modified only
    transactional tables are always put in transactional cache. Statements that
    modified non-transactional tables can be put in either transactional or
    non-transactional cache depending on different situations. In this patch, a
    flag is added to mark if there is any statement that modified non-transactional
    table in transactional cache.
    
    When rolling back a transaction on master, transactional cache should not be
    flushed to binary log, if there is no statement in it that modified a
    non-transactional table. Otherwise, it should be flushed into binary log
    followed by 'ROLLBACK' statement.
    
    BUG#55798
    ---------
    When a temporary error(eg. Lock timeout) happens, Slave SQL thread will rollback
    the transaction and retry it again. But it is possible that the transaction
    cannot be rolled back safely. For example a non-transactional table has been
    modified by the transaction. It will make master and slave diverge.
    
    After this patch, SQL thread will not retry to execute a transaction which
    cannot be rolled back safely if temporary error is encountered.
    
    ADDITIONAL CHANGES
    ------------------
    Some refactoring related to THD_TRANS::modified_non_trans_table and
    binlog_cache_data was also done.
    93a5a834
    BUG#11763471 BUG#56184 Rolled back transaction without non-transactional table...
    Alfranio Correia authored
    BUG#11763471 BUG#56184 Rolled back transaction without non-transactional table updated was binlogged
    BUG#11763126 BUG#55798 Slave SQL retry on transaction inserts extra data into non-transaction table
    
    BUG#56184
    ---------
    The transaction modified non-transactional table will be binlogged with
    ROLLBACK if it rolls back on master. It includes the case that all
    statements which modified non-transactional table are binlogged outside
    the transaction. Example:
    
      BEGIN
      INSERT INTO trans-table;
      INSERT INTO non-trans-table;
      ROLLBACK
    
    This will be binlogged as:
    
      BEGIN
      INSERT INTO non-trans-table;
      COMMIT
      BEGIN
      INSERT INTO trans-table;
      ROLLBACK;
    
    All statements in the second binlogged transaction modify only transactional
    tables and are rolled back safely on master. So the second transaction should
    not be binlogged.
    
    After 5.5, there are two caches for binary logs, a transactional cache and a
    statement cache. When executing a transaction, statements that modified only
    transactional tables are always put in transactional cache. Statements that
    modified non-transactional tables can be put in either transactional or
    non-transactional cache depending on different situations. In this patch, a
    flag is added to mark if there is any statement that modified non-transactional
    table in transactional cache.
    
    When rolling back a transaction on master, transactional cache should not be
    flushed to binary log, if there is no statement in it that modified a
    non-transactional table. Otherwise, it should be flushed into binary log
    followed by 'ROLLBACK' statement.
    
    BUG#55798
    ---------
    When a temporary error(eg. Lock timeout) happens, Slave SQL thread will rollback
    the transaction and retry it again. But it is possible that the transaction
    cannot be rolled back safely. For example a non-transactional table has been
    modified by the transaction. It will make master and slave diverge.
    
    After this patch, SQL thread will not retry to execute a transaction which
    cannot be rolled back safely if temporary error is encountered.
    
    ADDITIONAL CHANGES
    ------------------
    Some refactoring related to THD_TRANS::modified_non_trans_table and
    binlog_cache_data was also done.
Loading