1. 16 Feb, 2016 1 commit
  2. 15 Feb, 2016 10 commits
  3. 12 Feb, 2016 1 commit
  4. 11 Feb, 2016 3 commits
  5. 08 Feb, 2016 1 commit
  6. 06 Feb, 2016 1 commit
  7. 04 Feb, 2016 3 commits
  8. 03 Feb, 2016 2 commits
  9. 01 Feb, 2016 4 commits
  10. 26 Jan, 2016 1 commit
  11. 25 Jan, 2016 3 commits
  12. 19 Jan, 2016 1 commit
  13. 15 Jan, 2016 3 commits
    • Kristian Nielsen's avatar
      Merge branch 'tmp' into tmp-10.0 · 74b1af19
      Kristian Nielsen authored
      Conflicts:
      	sql/slave.cc
      74b1af19
    • Kristian Nielsen's avatar
      Fix error handling for GTID and domain-based parallel replication · 06b2e327
      Kristian Nielsen authored
      This occurs when replication stops with an error, domain-based parallel
      replication is used, and the GTID position contains more than one domain.
      Furthermore, it relates to the case where the SQL thread is restarted
      without first stopping the IO thread.
      
      In this case, the file/offset relay-log position does not correctly
      represent the slave's multi-dimensional position, because other domains may
      be far ahead of, or behind, the domain with the failing event. So the code
      reverts the relay log position back to the start of a relay log file that is
      known to be before all active domains.
      
      There was a bug that when the SQL thread was restarted, the
      rli->relay_log_state was incorrectly initialised from @@gtid_slave_pos. This
      position will likely be too far ahead, due to reverting the relay log
      position. Thus, if the replication fails again after the SQL thread restart,
      the rli->restart_gtid_pos might be updated incorrectly. This in turn would
      cause a second SQL thread restart to replicate from the wrong position, if
      the IO thread was still left running.
      
      The fix is to initialise rli->relay_log_state from @@gtid_slave_pos only
      when we actually purge and re-fetch relay logs from the master, not at every
      SQL thread start.
      
      A related problem is the use of sql_slave_skip_counter to resolve
      replication failures in this kind of scenario. Since the slave position is
      multi-dimensional, sql_slave_skip_counter can not work properly - it is
      indeterminate exactly which event is to be skipped, and is unlikely to work
      as expected for the user. So make this an error in the case where
      domain-based parallel replication is used with multiple domains, suggesting
      instead the user to set @@gtid_slave_pos to reliably skip the desired event.
      06b2e327
    • Alexey Botchkov's avatar
      MDEV-9106 Audit plugin not working with MySQL 5.7. · 9c9d10b4
      Alexey Botchkov authored
              fixing Windows crash.
      9c9d10b4
  14. 13 Jan, 2016 2 commits
  15. 12 Jan, 2016 1 commit
  16. 11 Jan, 2016 1 commit
    • Otto Kekäläinen's avatar
      MDEV-9354: Debian: unmask the mysql.service on installation · 2a9f84b9
      Otto Kekäläinen authored
      Unmask the systemd mysql.service if left behind by mysql-server-5.6
      
      Without this a simple 'apt-get install mariadb-server' would end
      up with a system where mysqld is not running despite it was
      running OK with mysql-server-5.6 installed, and users might wrongly
      think mariadb-server package is broken when the real cause was
      the removal of mysql-server-5.6 that left a /etc/systemd/system/
      file behind pointing to /dev/null.
      2a9f84b9
  17. 07 Jan, 2016 2 commits