1. 10 Jul, 2013 1 commit
    • unknown's avatar
      MDEV-4708: GTID strict mode doesn't work on a database with purged binlogs · 1e432778
      unknown authored
      When a new master is provisioned that does not have any old binlogs,
      the @@gtid_slave_pos is used to know where in the GTID history the
      provisioning happened. A slave is allowed to connect at the point of
      this value of @@gtid_slave_pos, even if that GTID is not in the
      binlogs on the new master.
      
      But --gtid-strict-mode did not correctly handle this case. When strict
      mode was enabled, an attempt to connect at the position would cause an
      error about holes in the binlog, which is not correct.
      
      This patch adds a hash of GTIDs that need to be treated specially by
      GTID strict mode to deal correctly with this case.
      1e432778
  2. 24 Jun, 2013 3 commits
  3. 25 Jun, 2013 1 commit
  4. 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
  5. 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
  6. 20 Jun, 2013 1 commit
  7. 18 Jun, 2013 1 commit
  8. 16 Jun, 2013 4 commits
  9. 15 Jun, 2013 6 commits
  10. 14 Jun, 2013 1 commit
  11. 10 Jun, 2013 1 commit
  12. 08 Jun, 2013 1 commit
  13. 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
  14. 06 Jun, 2013 5 commits
  15. 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
  16. 04 Jun, 2013 1 commit
  17. 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
  18. 01 Jun, 2013 2 commits