• unknown's avatar
    Fix for BUG#24432 · 914ae41f
    unknown authored
    "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values".
    When in an INSERT ON DUPLICATE KEY UPDATE, using
    an autoincrement column, we inserted some autogenerated values and
    also updated some rows, some autogenerated values were not used
    (for example, even if 10 was the largest autoinc value in the table
    at the start of the statement, 12 could be the first autogenerated
    value inserted by the statement, instead of 11). One autogenerated
    value was lost per updated row. Led to exhausting the range of the
    autoincrement column faster.
    Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12.
    This bug breaks replication from a pre-5.0.24 master.
    But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
    behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34]
    master to a fixed (5.0.36) slave! To warn users against this when
    they upgrade their slave, as agreed with the support team, we add
    code for a fixed slave to detect that it is connected to a buggy
    master in a situation (INSERT ON DUP KEY UPDATE into autoinc column)
    likely to break replication, in which case it cannot replicate so
    stops and prints a message to the slave's error log and to SHOW SLAVE
    STATUS.
    For 5.0.36->[5.0.24,5.0.34] replication we cannot warn as master
    does not know the slave's version (but we always recommended to users
    to have slave at least as new as master).
    As agreed with support, I'll also ask for an alert to be put into
    the MySQL Network Monitoring and Advisory Service.
    
    
    mysql-test/r/rpl_insert_id.result:
      results to check the bugfix; without the bugfix, you would see, in
      master and slave:
      "3,2" instead of "2,2" for the INSERT VALUES testcase,
      "11,6,..." instead of "6,6,..." for the INSERT SELECT testcase.
    mysql-test/t/rpl_insert_id.test:
      testing that BUG#24432 is fixed
    sql/log_event.cc:
      A trick to force the master to pretend it is old and features BUG#24432.
      To do fast lookups in the list of known bugs by version, we compute
      the 3 X.Y.Z numbers from the master's version string and cache that
      into a new member Format_description_log_event::server_version_split.
      We do this computation in the event's two constructors.
      A simple prevention against buffer overrun when reading the master's
      version from a binlog event (assume the event is corrupted on disk,
      and so the version string on disk is longer than ST_SERVER_VER_LEN
      (50), then we would not get a closing 0 at the end of the class member.
    sql/log_event.h:
      new member to hold the "split server version" (3 numbers X.Y.Z),
      and a method to compute this from the version string.
    sql/slave.cc:
      a function which tells, based on master's version (as found
      in the Format_description event in the relay log being executed),
      if master can have a certain bug. This function uses a list of
      bug_id / first_version_with_bug / first_version_with_fix.
      If the test is positive, a short error message is put into SHOW SLAVE
      STATUS, and a verbose message is put into the slave's error log.
      The caller is expected to stop the slave in this case.
    sql/slave.h:
      new function to test if the replication master has a bug
    sql/sql_insert.cc:
      Fix for BUG#24432:t he reason was a misplaced restore_auto_increment() 
      (misplaced when fixing BUG#20188). Indeed, when updating the row,
      it is clear that the autogenerated auto_increment value will not be
      used for this row (and if by "chance" the autoinc value present
      in the updated row is >= to the not used autogenerated value,
      adjust_next_insert_id_after_explicit_value() will fix next_insert_id).
      We also add code for a fixed slave to detect that it is connected to
      a buggy master (in which case it cannot replicate so stops).
    mysql-test/r/rpl_known_bugs_detection.result:
      see that SHOW SLAVE STATUS prints information that slave found a bug
      in master, and does not execute the dangerous event (table stays
      empty).
    mysql-test/t/rpl_known_bugs_detection-master.opt:
      pass debug symbol to make the master pretend it has BUG#24432
    mysql-test/t/rpl_known_bugs_detection.test:
      new test to see if bug detection by slave works
    914ae41f
log_event.h 54.3 KB