1. 25 Jun, 2013 1 commit
  2. 24 Jun, 2013 1 commit
    • unknown's avatar
      Fix sporadic failure of test rpl.rpl_gtid_startpos · 748e8a35
      unknown authored
      The test did RESET MASTER and then tried to use --sync_with_master
      to wait for GTID-based replication to catch up. This though has
      a race, there is a small window where the _old_ pre-RESET MASTER
      position on the slave is higher than the new pos-RESET MASTER
      position, causing the --sync_with_master to be a no-op.
      
      Fix by using include/wait_condition.inc instead.
      748e8a35
  3. 21 Jun, 2013 2 commits
    • unknown's avatar
      MDEV-4692: mysql.gtid_slave_pos accumulates values for a domain · df66ee7f
      unknown authored
      When we load the slave state from the mysql.gtid_slave_pos at server start, we
      need to load all the rows into the in-memory hash, not just the most recent
      one in each replication domain. Otherwise we accumulate cruft in the form of
      old rows each time the server restarts.
      df66ee7f
    • unknown's avatar
      MDEV-4688: empty @@gtid_slave_pos during slave commit. · 6e7d7f9b
      unknown authored
      In record_gtid(), too many rows were deleted from the slave position
      hash - we need to always keep on to the most recent committed row,
      so we have a valid slave position at all times.
      6e7d7f9b
  4. 20 Jun, 2013 1 commit
  5. 18 Jun, 2013 1 commit
  6. 16 Jun, 2013 4 commits
  7. 15 Jun, 2013 6 commits
  8. 14 Jun, 2013 1 commit
  9. 10 Jun, 2013 1 commit
  10. 08 Jun, 2013 1 commit
  11. 07 Jun, 2013 5 commits
    • unknown's avatar
      MDEV-4490: Old-style master position points at the last GTID event after slave restart · b5fcf33d
      unknown authored
      Now whenever we reach the GTID point requested from the slave (when using GTID
      position to connect), we send a fake Gtid_list event. This event is used by
      the slave to know the current old-style position for MASTER_POS_WAIT(), and
      later the similar binlog position for MASTER_GTID_WAIT().
      
      Without this fake event, if the slave is already fully up-to-date with the
      master, there may be no events sent at the given position for an indeterminate
      time.
      b5fcf33d
    • unknown's avatar
      MDEV-4486: Allow to start old-style replication even if mysql.rpl_slave_state is unavailable · 03aa4876
      unknown authored
      If the mysql.gtid_slave_pos table is not available, we cannot load nor update
      the current GTID position persistently. This can happen eg. after an upgrade,
      before mysql_upgrade_db is run, or if the table is InnoDB and the server is
      restarted without the InnoDB storage engine enabled.
      
      Before, replication always failed to start if the table was unavailable. With
      this patch, we try to continue with old-style replication, after suitable
      complaints in the error log. In strict mode, or if slave is configured to use
      GTID, slave still refuses to start.
      03aa4876
    • Sergey Vojtovich's avatar
      Merge. · fb1a8f04
      Sergey Vojtovich authored
      fb1a8f04
    • unknown's avatar
      MDEV-4591:Setting gtid* values from inside a transaction might cause unexpected results · dbe2c506
      unknown authored
      Now we give an error on attempts to set @@SESSION.gtid_domain_id or
      @@SESSION.gtid_seq_no when a transaction is active.
      dbe2c506
    • unknown's avatar
      MDEV-4483: CHANGE MASTER TO master_use_gtid=xxx looses old-style coordinates. · 7b6ab563
      unknown authored
      There was some old code that cleared the position in CHANGE MASTER,
      it was forgotten to be removed.
      
      In addition, add code that saves/restores the old-style position
      when we nuke the old relay logs as part of GTID slave start.
      Normally we will not use these, but it could be useful in case
      the GTID connect fails and user wants to go back to the old-style
      coordinates.
      7b6ab563
  12. 06 Jun, 2013 5 commits
  13. 05 Jun, 2013 3 commits
    • unknown's avatar
      Fix two small problems in previous push. · 64e53a0f
      unknown authored
      64e53a0f
    • unknown's avatar
      MDEV-26: Global transaction ID. · 5cb486d1
      unknown authored
      Fix problems related to reconnect. When we need to reconnect (ie. explict
      stop/start of just the IO thread by user, or automatic reconnect due to
      loosing network connection with the master), it is a bit complex to correctly
      resume at the right point without causing duplicate or missing events in the
      relay log. The previous code had multiple problems in this regard.
      
      With this patch, the problem is solved as follows. The IO thread keeps track
      (in memory) of which GTID was last queued to the relay log. If it needs to
      reconnect, it resumes at that GTID position. It also counts number of events
      received within the last, possibly partial, event group, and skips the same
      number of events after a reconnect, so that events already enqueued before the
      reconnect are not duplicated.
      
      (There is no need to keep any persistent state; whenever we restart slave
      threads after both of them being stopped (such as after server restart), we
      erase the relay logs and start over from the last GTID applied by SQL thread.
      But while the SQL thread is running, this patch is needed to get correct relay
      log).
      5cb486d1
    • Sergey Vojtovich's avatar
      ccdfeb04
  14. 04 Jun, 2013 1 commit
  15. 03 Jun, 2013 1 commit
    • unknown's avatar
      MDEV-4605: Failing to load GTID slave position from rpl.gtid_slave_pos · 7ad47ab0
      unknown authored
      There were several cases where the slave GTID position was not loaded
      correctly before being used. This caused various failures such as
      corrupting the position at slave start and empty values of
      @@gtid_slave_pos and @@gtid_current_pos.
      
      Fixed by adding more checks for loaded position, and by always loading
      the position at server startup.
      7ad47ab0
  16. 01 Jun, 2013 2 commits
  17. 30 May, 2013 1 commit
  18. 29 May, 2013 2 commits
    • unknown's avatar
      MDEV-4485: Incorrect error handling in record_gtid(). · 6feadb10
      unknown authored
      Fix the error handling when access to the table mysql.gtid_slave_pos
      fails for whatever reason. Add some test cases.
      6feadb10
    • unknown's avatar
      MDEV-4485: Master did not allow slave to connect from the very start (empty... · 385780f5
      unknown authored
      MDEV-4485: Master did not allow slave to connect from the very start (empty GTID pos) if GTIDs from other multi_source master was present
      
      The idea in the code was to protect the user that tries to connect a slave
      to a master with completely different domains than what was intended. If
      none of the domains in the start position are present at all in the master
      binlog, we gave an error.
      
      However, this is a stupid idea. Because when a slave connects to a master
      to start replication from the very start of binlogs - such as when setting
      up new master->slave servers from scratch - there will be just this
      situation, the requested slave position is empty for all the domains in the
      master's binlog.
      
      So the code that gives this error is wrong, and the solution is simply to
      remove it.
      385780f5
  19. 28 May, 2013 1 commit