1. 02 Apr, 2019 6 commits
  2. 01 Apr, 2019 7 commits
  3. 30 Mar, 2019 2 commits
  4. 29 Mar, 2019 15 commits
  5. 28 Mar, 2019 8 commits
    • Sergei Petrunia's avatar
      MDEV-18080, part#1: MyRocks is slow with log-bin=off · 8fcd9478
      Sergei Petrunia authored
      The cause for this was fix MDEV-15372, which was trying to speed up
      the parallel slave.
      
      Part#1: Do not attempt the "optimization" for transactions that are not
      replication slave workers.
      8fcd9478
    • Sujatha Sivakumar's avatar
      MDEV-13895: GTID and Master_Delay causes excessive initial delay · e42192d7
      Sujatha Sivakumar authored
      Problem:
      ========
      When attempting to delay a Slave attached with GTID, there appears to be an
      extra delay applied initially. For example, this output reflects a Slave that is
      already delayed by 43200 seconds. When switching to GTID replication,
      replication is paused until SQL_Remaining_Delay counts down to 0:
      
      CHANGE MASTER TO master_use_gtid=current_pos; CHANGE MASTER TO
      MASTER_DELAY=43200;
      
      Seconds_Behind_Master: 44847
      Using_Gtid: Current_Pos
      SQL_Delay: 43200
      SQL_Remaining_Delay: 43089
      Slave_SQL_Running_State: Waiting until MASTER_DELAY seconds after master
      executed event
      
      Analysis:
      =========
      When slave initiates a GTID based connection request to master, the master sends
      two GTID_LIST events.  The first one is actual GTID_LIST event and the second
      one is a fake GTID_LIST event. This is sent by master to provide its current
      binlary log file position. The fake GTID_LIST events will have their ev->when=0.
      'when' (the timestamp) is set to 0 so that slave could distinguish between real
      and fake Rotate events.
      
      On slave side when MASTER_DELAY is configured to "X" the applier will ensure
      that there is a time delay of "X" seconds before the event is applied.
      
      General behaviour of MASTER_DELAY example:-
      
      Master
      timestamp of event e1=10
      timestamp of event e2=11
      
      On slave MASTER_DELAY=5
      Event e1 will be applied at = 15
      e2 will be applied at =16
      
      In bug scenario:-
      
      On Master: With GTIDs
      timestamp of event e1=10
      timestamp of event e2=0
      
      On Slave:
      e1 will be applied at = 10 + 5 =15
      For e2, since "e2->when=0" e2->when is set to current timestamp.
      i.e since the e2->when and current timestamp on slave is the same applier waits
      for additional master_delay=5 seconds. the ev->when contributes to
      "rli->last_master_timestamp".
      
      rli->last_master_timestamp= ev->when + (time_t) ev->exec_time;
      
      Fake events should not update the "ev->when" to "current timestamp" on slave.
      
      Fix:
      ===
      Remove the assignment of current timestamp to "ev->when" when "ev->when=0".
      e42192d7
    • Vladislav Vaintroub's avatar
    • Marko Mäkelä's avatar
      Revert MDEV-18464 and MDEV-12009 · d0116e10
      Marko Mäkelä authored
      This reverts commit 21b2fada
      and commit 81d71ee6.
      
      The MDEV-18464 change introduces a few data race issues. Contrary to
      the documentation, the field trx_t::victim is not always being protected
      by lock_sys_t::mutex and trx_t::mutex. Most importantly, it seems
      that KILL QUERY could wrongly avoid acquiring both mutexes when
      invoking lock_trx_handle_wait_low(), in case another thread had
      already set trx->victim=true.
      
      We also revert MDEV-12009, because it should depend on the MDEV-18464
      fix being present.
      d0116e10
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-19051 Avoid unnecessary writing MLOG_INDEX_LOAD · 0623cc7c
      Thirunarayanan Balathandayuthapani authored
      1) Avoid writing of MLOG_INDEX_LOAD redo log record during inplace
      alter table when the table is empty and also for spatial index.
      
      2) Avoid creation of temporary merge file for spatial index during
      index creation process.
      0623cc7c
    • Varun Gupta's avatar
      MDEV-18899: Server crashes in Field::set_warning_truncated_wrong_value · 38cad687
      Varun Gupta authored
      To fix the crash there we need to make sure that the
      server while storing the statistical values in statistical tables should do it
      in a multi-byte safe way.
      Also there is no need to throw warnings if there is truncation while storing
      values from statistical fields.
      38cad687
    • Jan Lindström's avatar
      MDEV-12009: Allow to force kill user threads/query which are flagged as high priority by Galera · 81d71ee6
      Jan Lindström authored
      As noted on kill_one_thread SUPER should be able to kill even
      system threads i.e. threads/query flagged as high priority or
      wsrep applier thread. Normal user, should not able to kill
      threads/query flagged as high priority (BF) or wsrep applier
      thread.
      81d71ee6
    • Jan Lindström's avatar
      MDEV-18464: Port kill_one_trx fixes from 10.4 to 10.1 · 21b2fada
      Jan Lindström authored
      Pushed the decision for innodb transaction and system
      locking down to lock0lock.cc level. With this,
      we can avoid releasing these mutexes for executions
      where these mutexes were acquired upfront.
      
      This patch will also fix BF aborting of native threads, e.g.
      threads which have declared wsrep_on=OFF. Earlier, we have
      used, for innodb trx locks, was_chosen_as_deadlock_victim
      flag, for marking inodb transactions, which are victims for
      wsrep BF abort. With native threads (wsrep_on==OFF), re-using
      was_chosen_as_deadlock_victim flag may lead to inteference
      with real deadlock, and to deal with this, the patch has added new
      flag for marking wsrep BF aborts only: victim=true
      
      Similar way if replication decides to abort one of the threads
      we mark victim by: victim=true
      
      innobase_kill_query
      	Remove lock sys and trx mutex handling.
      
      wsrep_innobase_kill_one_trx
      	Mark victim trx with victim=true
      
      trx0trx.h
      	Remove trx_abort_t type and abort type variable from
      	trx struct. Add victim variable to trx.
      
      wsrep_kill_victim
      	Remove abort_type
      
      lock_report_waiters_to_mysql
      	Take also trx mutex and mark trx as a victim for
      	replication abort.
      
      lock_trx_handle_wait_low
      	New low level function to check whether the transaction
      	has already been rolled back because it was selected as
      	a deadlock victim, or if it has to wait then cancel
      	the wait lock.
      
      lock_trx_handle_wait
      	If transaction is not marked as victim take lock sys
      	and trx mutex before calling lock_trx_handle_wait_low
      	and release them after that.
      
      row_search_for_mysql
      	Remove lock sys and trx mutex taking and releasing.
      
      trx_rollback_to_savepoint_for_mysql_low
      trx_commit_in_memory
      	Clean up victim variable.
      21b2fada
  6. 27 Mar, 2019 2 commits
    • Sergei Golubchik's avatar
      MDEV-18466 Unsafe to log updates on tables referenced by foreign keys with... · deff3f75
      Sergei Golubchik authored
      MDEV-18466 Unsafe to log updates on tables referenced by foreign keys with triggers in statement format
      
      ignore FK-prelocked tables when looking for write-prelocked tables
      with auto-increment to complain about "Statement is unsafe because
      it invokes a trigger or a stored function that inserts into an
      AUTO_INCREMENT column"
      deff3f75
    • Sergei Golubchik's avatar
      MDEV-7066 No Source RPMs ... (and so no "yum-builddep MariaDB-server" either) · d8084116
      Sergei Golubchik authored
      special cases:
      
      * change systemd detection to use CHECK_LIBRARY_EXISTS at least once,
        to have it detected by build_depends.cmake
      * similarly, use find_library for pam
      * unixODBC is weird, libodbc.so is in the unixODBC package, not
        in the unixODBC-devel, where normally all .so files belong.
        Packaging bug? As a workaround, use find_file(sql.h) instead of
        find_path(sql.h) to make sure that /usr/include/sql.h (not /usr/include)
        is cached by cmake, and later build_depends.cmake will select
        unixODBC-devel, as a package owning /usr/include/sql.h file.
      d8084116