1. 10 Feb, 2014 2 commits
  2. 09 Feb, 2014 1 commit
  3. 08 Feb, 2014 3 commits
    • unknown's avatar
      MDEV-5636: Deadlock in RESET MASTER · 07eaf6ea
      unknown authored
      The problem is a deadlock between MYSQL_BIN_LOG::reset_logs() and
      MYSQL_BIN_LOG::mark_xid_done(). The former takes LOCK_log and waits for the
      latter to complete. But the latter also tries to take LOCK_log; this can lead
      to a deadlock.
      
      There was already code that tries to deal with this, with the flag
      reset_master_pending. However, there was still a small opportunity for
      deadlock, when an previous mark_xid_done() is still running when reset_logs()
      is called and is at the precise point where it first releases LOCK_xid_list
      and then re-aquires both LOCK_log and LOCK_xid_list.
      
      Solve by setting reset_master_pending in reset_logs() before taking
      LOCK_log. And also count how many invocations of LOCK_xid_list are in the
      progress of releasing and re-aquiring locks, and in reset_logs() wait for that
      number to drop to zero after setting reset_master_pending and before taking
      LOCK_log.
      07eaf6ea
    • unknown's avatar
      MDEV-4984: Implement MASTER_GTID_WAIT() and @@LAST_GTID. · 76e929a9
      unknown authored
      Rewrite the gtid_waiting::wait_for_gtid() function.
      The code was rubbish (and buggy). Now the logic is
      much clearer.
      
      Also fix a missing slave sync that could cause test failure.
      76e929a9
    • unknown's avatar
      MDEV-4984: Implement MASTER_GTID_WAIT() and @@LAST_GTID. · 3c97d24f
      unknown authored
      Couple of small fixes following buildbot testing.
      3c97d24f
  4. 07 Feb, 2014 2 commits
    • unknown's avatar
      MDEV-4726: Race in mysql-test/suite/rpl/t/rpl_gtid_stop_start.test · 7bb022f3
      unknown authored
      Some GTID test cases were using include/wait_condition.inc with a
      condition like SELECT COUNT(*)=4 FROM t1 to wait for the slave to
      catch up with the master. This causes races and test failures, as the
      changes to the tables become visible at the COMMIT of the SQL thread
      (or even before in case of MyISAM), but the changes to
      @@gtid_slave_pos only become visible a little bit after the COMMIT.
      
      Now that we have MASTER_GTID_WAIT(), just use that to sync up in a
      GTID-friendly way, wrapped in nice include/save_master_gtid.inc and
      include/sync_with_master_gtid.inc scripts.
      7bb022f3
    • unknown's avatar
      MDEV-4984: Implement MASTER_GTID_WAIT() and @@LAST_GTID. · 4e6606ac
      unknown authored
      MASTER_GTID_WAIT() is similar to MASTER_POS_WAIT(), but works with a
      GTID position rather than an old-style filename/offset.
      
      @@LAST_GTID gives the GTID assigned to the last transaction written
      into the binlog.
      
      Together, the two can be used by applications to obtain the GTID of
      an update on the master, and then do a MASTER_GTID_WAIT() for that
      position on any read slave where it is important to get results that
      are caught up with the master at least to the point of the update.
      
      The implementation of MASTER_GTID_WAIT() is implemented in a way
      that tries to minimise the performance impact on the SQL threads,
      even in the presense of many waiters on single GTID positions (as
      from @@LAST_GTID).
      4e6606ac
  5. 31 Jan, 2014 1 commit
  6. 08 Jan, 2014 1 commit
    • unknown's avatar
      MDEV-5509: Seconds_behind_master incorrect in parallel replication · 8cc6e90d
      unknown authored
      The problem was a race between the SQL driver thread and the worker threads.
      The SQL driver thread would set rli->last_master_timestamp to zero to
      mark that it has caught up with the master, while the worker threads would
      set it to the timestamp of the executed event. This can happen out-of-order
      in parallel replication, causing the "caught up" status to be overwritten
      and Seconds_Behind_Master to wrongly grow when the slave is idle.
      
      To fix, introduce a separate flag rli->sql_thread_caught_up to mark that the
      SQL driver thread is caught up. This avoids issues with worker threads
      overwriting the SQL driver thread status. In parallel replication, we then
      make SHOW SLAVE STATUS check in addition that all worker threads are idle
      before showing Seconds_Behind_Master as 0 due to slave idle.
      8cc6e90d
  7. 05 Feb, 2014 2 commits
  8. 03 Feb, 2014 1 commit
  9. 31 Jan, 2014 3 commits
  10. 28 Jan, 2014 9 commits
  11. 27 Jan, 2014 5 commits
  12. 26 Jan, 2014 9 commits
  13. 25 Jan, 2014 1 commit
    • Michael Widenius's avatar
      Fixed MDEV-4970: Wrong result with Aria table populated with disabled keys · 3d67c68a
      Michael Widenius authored
      Problem was that ALTER TABLE DISABLE KEYS incremented create_trid for the table,
      which made the new index entries invisible until the global trid catched up.
      
      Fixed by only updating create_trid if we are rewriting all rows and indexes.
      
      
      mysql-test/suite/maria/alter.result:
        Added test case
      mysql-test/suite/maria/alter.test:
        Added test case
      storage/maria/ha_maria.cc:
        Only updating create_trid if we are doing a full repair (and thus rewriting all rows and indexes).
      storage/maria/trnman.c:
        More DBUG_PRINT
      3d67c68a