1. 18 Dec, 2019 2 commits
  2. 16 Dec, 2019 2 commits
  3. 13 Dec, 2019 2 commits
  4. 11 Dec, 2019 2 commits
  5. 06 Dec, 2019 1 commit
    • Sujatha's avatar
      MDEV-20959: binlog.binlog_parallel_replication_marks_row fails in buildbot with wrong result · e949b2d4
      Sujatha authored
      Problem:
      =======
      Test "binlog.binlog_parallel_replication_marks_row" fails sporadically due to
      result length mismatch.
      
      Analysis:
      =========
      Test generates a binary log and it looks for certain words within the binary
      log file and prints them. For example word like "GTID,BEGIN,COMMIT ...".
      Binary log output contains base64 encoded characters. Occasionally the encoded
      characters match with the above words and results in test failure.
      
      +XwoFWxMBAAAALgAAAGEDAAAAAB8AAAAAAAEABHRlc3QAAnQxAAIDAwACFGTIDQ==
      +AAAAAAAAAAAEEwQADQgICAoKCgGTIDw9
      
      Fix:
      ===
      Improve the regular expression to match exact words.
      e949b2d4
  6. 05 Dec, 2019 4 commits
  7. 04 Dec, 2019 2 commits
  8. 03 Dec, 2019 3 commits
  9. 02 Dec, 2019 2 commits
  10. 30 Nov, 2019 2 commits
  11. 29 Nov, 2019 2 commits
    • Anel Husakovic's avatar
    • Daniel Black's avatar
      MDEV-15503: mtr fix --strace · 866e5c25
      Daniel Black authored
      $glob_mysql_test_dir was the wrong directory for strace output as
      it was for in-tree builds only so failed for:
      * out of tree builds
      * --parallel; and
      * --mem
      
      strace output wasn't saved.
      
      strace-option never replaced existing arguments (so ammended
      documentation).
      
      strace-client didn't accept an argument as described.
      
      Replaced specification of client with this with 'stracer' to be
      consistent with --debugger option.
      
      For consistency with debugger options, --client-strace was added to
      execute the strace on the mysqltest.
      
      Example: Running one test
      
      $ ./mtr --strace --client-strace funcs_1.is_table_constraints
      Logging: ./mtr  --strace --client-strace funcs_1.is_table_constraints
      vardir: /home/anel/mariadb/5.5/mysql-test/var
      Checking leftover processes...
      Removing old var directory...
       - WARNING: Using the 'mysql-test/var' symlink
      Creating var directory '/home/anel/mariadb/5.5/mysql-test/var'...
      Checking supported features...
      MariaDB Version 5.5.67-MariaDB-debug
      Installing system database...
       - SSL connections supported
       - binaries are debug compiled
      Collecting tests...
      
      ==============================================================================
      
      TEST                                      RESULT   TIME (ms) or COMMENT
      --------------------------------------------------------------------------
      
      worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
      funcs_1.is_table_constraints             [ pass ]   1270
      --------------------------------------------------------------------------
      The servers were restarted 0 times
      Spent 1.270 of 3 seconds executing testcases
      
      Completed: All 1 tests were successful
      
      $ find -L . -name \*strace -ls
            653     56 -rw-r--r--   1 anel     anel        57147 Nov 29 15:08 ./var/log/mysqltest.strace
            646   1768 -rw-r--r--   1 anel     anel      1809855 Nov 29 15:08 ./var/log/mysqld.1.strace
      
      Example: Running test in parallel
      
      $ mysql-test/mtr --strace --client-strace  --mem --parallel=3  main.select
      Logging: /home/dan/software_projects/mariadb-server/mysql-test/mysql-test-run.pl  --strace --client-strace --mem --parallel=3 main.select
      vardir: /home/dan/software_projects/build-mariadb-10.3/mysql-test/var
      Checking leftover processes...
      Removing old var directory...
      Creating var directory '/home/dan/software_projects/build-mariadb-10.3/mysql-test/var'...
       - symlinking 'var' to '/dev/shm/var_auto_0v2E'
      Checking supported features...
      MariaDB Version 5.5.67-MariaDB
       - SSL connections supported
      Collecting tests...
      Installing system database...
      
      ==============================================================================
      
      TEST                                  WORKER RESULT   TIME (ms) or COMMENT
      --------------------------------------------------------------------------
      
      worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
      worker[3]  - 'localhost:16040' was not free
      worker[2] Using MTR_BUILD_THREAD 301, with reserved ports 16020..16039
      worker[3] Using MTR_BUILD_THREAD 303, with reserved ports 16060..16079
      main.select                              w1 [ pass ]   7310
      --------------------------------------------------------------------------
      The servers were restarted 0 times
      Spent 7.310 of 11 seconds executing testcases
      
      Completed: All 1 tests were successful.
      
      $ find mysql-test/var/ -name \*strace -ls
        5213766   1212 -rw-r--r--   1  dan      dan       1237817 May 20 16:47 mysql-test/var/1/log/mysqltest.strace
        5214733  13016 -rw-r--r--   1  dan      dan      13328335 May 20 16:47 mysql-test/var/1/log/mysqld.1.strace
      
      $ mysql-test/mtr --strace --client-strace --strace-option='-e' --strace-option='trace=openat'  --mem --parallel=3  main.select
      ...
      $ find mysql-test/var/ -name \*strace -ls
        5220790      8 -rw-r--r--   1  dan      dan          6291 May 20 17:02 mysql-test/var/3/log/mysqltest.strace
        5224140    308 -rw-r--r--   1  dan      dan        314356 May 20 17:02 mysql-test/var/3/log/mysqld.1.strace
      $ more mysql-test/var/3/mysqltest.strace
      1692  openat(AT_FDCWD, "/home/dan/software_projects/mariadb-server/libmysql/.libs/tls/x86_64/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) =
      -1 ENOENT (No such file or directory)
      1692  openat(AT_FDCWD, "/home/dan/software_projects/mariadb-server/libmysql/.libs/tls/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOE
      NT (No such file or directory)
      
      Closes #600
      866e5c25
  12. 28 Nov, 2019 1 commit
  13. 26 Nov, 2019 5 commits
    • Vicențiu Ciorbaru's avatar
    • Vicențiu Ciorbaru's avatar
      MDEV-13288: Proper fix for cracklib-runtime · 427eedd0
      Vicențiu Ciorbaru authored
      The required dependencies should be added through the autobake script,
      to also cover distributions that do not support libcrack2.
      427eedd0
    • Vicențiu Ciorbaru's avatar
      MDEV-13288: Upstream debian patch · ed2379f9
      Vicențiu Ciorbaru authored
      ed2379f9
    • Seth Shelnutt's avatar
      23664bc7
    • seppo's avatar
      MDEV-19572 async slave node fails to apply MyISAM only writes (#1418) · 38839854
      seppo authored
      The problem happens when MariaDB master replicates writes for only non InnoDB
      tables (e.g. writes to MyISAM table(s)). Async slave node, in Galera cluster,
      can apply these writes successfully, but it will, in the end, write gtid position in
      mysql.gtid_slave_pos table. mysql.gtid_slave_pos table is InnoDB engine, and
      this write makes innodb handlerton part of the replicated "transaction".
      Note that wsrep patch identifies that write to gtid_slave_pos should not be replicated
      and skips appending wsrep keys for these writes. However, as InnoDB was present
      in the transaction, and there are replication events (for MyISAM table) in transaction
      cache, but there are no appended keys, wsrep raises an error, and this makes the söave
      thread to stop.
      
      The fix is simply to not treat it as an error if async slave tries to replicate a write
      set with binlog events, but no keys. We just skip wsrep replication and return successfully.
      
      This commit contains also a mtr test which forces mysql.gtid_slave_pos table isto be
      of InnoDB engine, and executes MyISAM only write through asyn replication.
      
      There is additional fix for declaring IO and background slave threads as non wsrep.
      These threads should not write anything for wsrep replication, and this is just a safeguard
      to make sure nothing leaks into cluster from these slave threads.
      38839854
  14. 22 Nov, 2019 1 commit
  15. 21 Nov, 2019 1 commit
    • Eugene Kosov's avatar
      cleanup DBUG · a51f3b09
      Eugene Kosov authored
      DbugParse(): removed mutex lock/unlock which should protect file writes only.
      And no file writes happen in this function.
      
      DbugFlush(): move mutex_unlock out of this method because fflush() doesn't
      need any locking.
      
      Slow stuff like mutex lock/unlock and accessing errno (TLS)
      is moved to a more narrow scope.
      a51f3b09
  16. 19 Nov, 2019 1 commit
  17. 18 Nov, 2019 3 commits
    • Jan Lindström's avatar
      Remove excessive sleep from test. · c6b097ab
      Jan Lindström authored
      c6b097ab
    • seppo's avatar
      MDEV-18497 CTAS async replication from mariadb master crashes galera nodes (#1410) · 5c68343d
      seppo authored
      This PR contains a mtr test for reproducing a failure with replicating create table as select statement (CTAS) through asynchronous mariadb replication to mariadb galera cluster.
      The problem happens when CTAS replication contains both create table statement followed by row events for populating the table. In such situation, the galera node operating as mariadb replication slave, will first replicate only the create table part into the cluster, and then perform another replication containing both the create table and row events. This will lead all other nodes to fail for duplicate table create attempt, and crash due to this failure.
      
      PR contains also a fix, which identifies the situation when CTAS has been replicated, and makes further scan in async replication stream to see if there are following row events. The slave node will replicate either single TOI in case the CTAS table is empty, or if CTAS table contains rows, then single bundled write set with create table and row events is replicated to galera cluster.
      
      This fix should keep master server's GTID's for CTAS replication in sync with GTID's in galera cluster.
      5c68343d
    • Varun Gupta's avatar
      MDEV-21044: Wrong result when using a smaller size for sort buffer · 29097256
      Varun Gupta authored
      Make sure that the sort buffers can store atleast one sort key.
      This is needed to make sure that all merge buffers are read else
      with no sort keys some merge buffers are skipped because the code
      makes a conclusion there is no data to be read.
      29097256
  18. 14 Nov, 2019 1 commit
  19. 12 Nov, 2019 1 commit
    • Sujatha's avatar
      MDEV-20953: binlog_encryption.rpl_corruption failed in buildbot due to wrong error code · 7df07c76
      Sujatha authored
      Problem:
      ========
      CURRENT_TEST: binlog_encryption.rpl_corruption
      
      mysqltest: In included file "./include/wait_for_slave_io_error.inc":
      ...
      At line 72: Slave stopped with wrong error code
      **** Slave stopped with wrong error code: 1743 (expected 1595,1913) ****
      
      Analysis:
      ========
      The test emulates the corruption at the various stages of replication for
      example in binlog file, in network and in relay log etc. It verifies that all
      corruption cases are handled through appropriate error messages.
      
      The test cases which emulate network failure expect following errors.
      --ER_SLAVE_RELAY_LOG_WRITE_FAILURE (1595)
      --ER_NETWORK_READ_EVENT_CHECKSUM_FAILURE (1743)
      
      Ideally test should expect error codes as 1595 and 1743.
      But the test actually waits on incorrect error code 1595,1913
      
      Fix:
      ===
      Added appropriate error code for 'ER_NETWORK_READ_EVENT_CHECKSUM_FAILURE'.
      Replaced 1913 with 1743.
      7df07c76
  20. 10 Nov, 2019 1 commit
    • Andrei Elkin's avatar
      MDEV-19376 Repl_semi_sync_master::commit_trx assertion failure: ... ||... · 13db50fc
      Andrei Elkin authored
      MDEV-19376 Repl_semi_sync_master::commit_trx assertion failure: ... || !m_active_tranxs->is_tranx_end_pos(trx_wait_binlog_name, trx_wait_binlog_pos)
      
      The assert indicates that the current transaction got caught uncleaned from
      the semisync master's cache when it is signaled to proceed upon its
      ack receive.
      
      The reason of missed cleanup turns out to be a flaw in the gtid
      connect mode.
      A submitted by connecting slave value of its last received event's
      binlog file *name* was adopted into
      {{Repl_semi_sync_master::m_reply_file_name}} as a part of semisync
      initialization.
      
      Notice that the initialization still refines the position part of the
      submitted last received event's binlog coordinates.
      The master side binlog filename:pos refinement is
      specific to the gtid connect mode for purpose of computing the latest
      binlog file to resume slave feeding from.
      Effectively in the gtid connect mode the computed resumption filename:pos
      may appear smaller in which case a new post-connect time committing
      transaction may be logged with its filename:pos also less than the
      submitted coordinates and that triggers the assert.
      
      Fixed with making the semisync initialization to use the refined filename:pos.
      It is guaranteed to be less than any new generated transaction's binlog:pos.
      13db50fc
  21. 08 Nov, 2019 1 commit