An error occurred fetching the project authors.
  1. 14 Oct, 2016 2 commits
    • Kristian Nielsen's avatar
      MDEV-7145: Delayed replication, cleanup some code · b2bc6dad
      Kristian Nielsen authored
      The original MySQL patch left some refactoring todo's, possibly
      because of known conflicts with other parallel development (like
      info-repository feature perhaps).
      
      This patch fixes those todos/refactorings.
      Signed-off-by: default avatarKristian Nielsen <knielsen@knielsen-hq.org>
      b2bc6dad
    • Kristian Nielsen's avatar
      MDEV-7145: Delayed replication, intermediate commit. · 19abe79f
      Kristian Nielsen authored
      Initial merge of delayed replication from MySQL git.
      
      The code from the initial push into MySQL is merged, and the
      associated test case passes. A number of tasks are still pending:
      
      1. Check full test suite run for any regressions or .result file updates.
      
      2. Extend the feature to also work for parallel replication.
      
      3. There are some todo-comments about future refactoring left from
      MySQL, these should be located and merged on top.
      
      4. There are some later related MySQL commits, these should be checked
      and merged. These include:
          e134b9362ba0b750d6ac1b444780019622d14aa5
          b38f0f7857c073edfcc0a64675b7f7ede04be00f
          fd2b210383358fe7697f201e19ac9779879ba72a
          afc397376ec50e96b2918ee64e48baf4dda0d37d
      
      5. The testcase from MySQL relies heavily on sleep and timing for
      testing, and seems likely to sporadically fail on heavily loaded test
      servers in buildbot or distro build farms.
      Signed-off-by: default avatarKristian Nielsen <knielsen@knielsen-hq.org>
      19abe79f
  2. 22 Jun, 2016 1 commit
    • Vicențiu Ciorbaru's avatar
      MDEV-8638: REVOKE ALL PRIVILEGES, GRANT OPTION FROM CURRENT_ROLE breaks replication · b4496129
      Vicențiu Ciorbaru authored
      Fix the replication failure caused by incorect initialization of
      THD::invoker_host && THD::invoker_user.
      
      Breakdown of the failure is this:
      Query_log_event::host and Query_log_event::user can have their
      LEX_STRING's set to length 0, but the actual str member points to
      garbage. Code afterwards copies Query_log_event::host and user to
      THD::invoker_host and THD::invoker_user.
      
      Calling code for these members expects both members to be initialized.
      Eg. the str member be a NULL terminated string and length have
      appropriate size.
      b4496129
  3. 04 May, 2016 1 commit
    • Sujatha Sivakumar's avatar
      Bug#12818255: READ-ONLY OPTION DOES NOT ALLOW · 818b3a91
      Sujatha Sivakumar authored
      INSERTS/UPDATES ON TEMPORARY TABLES
      Bug#14294223: CHANGES NOT ALLOWED TO TEMPORARY TABLES ON
      READ-ONLY SERVERS
      
      Problem:
      ========
      Running 5.5.14 in read only we can create temporary tables
      but can not insert or update records in the table. When we
      try we get Error 1290 : The MySQL server is running with the
      --read-only option so it cannot execute this statement.
      
      Analysis:
      =========
      This bug is very specific to binlog being enabled and
      binlog-format being stmt/mixed. Standalone server without
      binlog enabled or with row based binlog-mode works fine.
      
      How standalone server and row based replication work:
      =====================================================
      Standalone server and row based replication mark the
      transactions as read_write only when they are modifying
      non temporary tables as part of their current transaction.
      
      Because of this when code enters commit phase it checks
      if a transaction is read_write or not. If the transaction
      is read_write and global read only mode is enabled those
      transaction will fail with 'server is read only mode'
      error.
      
      In the case of statement based mode at the time of writing
      to binary log a binlog handler is created and it is always
      marked as read_write. In case of temporary tables even
      though the engine did not mark the transaction as read_write
      but the new transaction that is started by binlog handler is
      considered as read_write.
      
      Hence in this case when code enters commit phase it finds
      one handler which has a read_write transaction even when
      we are modifying temporary table. This causes the server
      to throw an error when global read-only mode is enabled.
      
      Fix:
      ====
      At the time of commit in "ha_commit_trans" if a read_write
      transaction is found, we should check if this transaction is
      coming from a handler other than binlog_handler. This will
      ensure that there is a genuine read_write transaction being
      sent by the engine apart from binlog_handler and only then
      it should be blocked.
      818b3a91
  4. 22 Mar, 2016 2 commits
  5. 21 Mar, 2016 1 commit
  6. 04 Mar, 2016 1 commit
  7. 01 Mar, 2016 1 commit
    • Venkatesh Duggirala's avatar
      BUG#17018343 SLAVE CRASHES WHEN APPLYING ROW-BASED BINLOG ENTRIES IN CASCADING · bb32ac1d
      Venkatesh Duggirala authored
      REPLICATION
      
      Problem: In RBR mode, merge table updates are not successfully applied on a cascading
      replication.
      
      Analysis & Fix: Every type of row event is preceded by one or more table_map_log_events
      that gives the information about all the tables that are involved in the row
      event. Server maintains the list in RPL_TABLE_LIST and it goes through all the
      tables and checks for the compatibility between master and slave. Before
      checking for the compatibility, it calls 'open_tables()' which takes the list
      of all tables that needs to be locked and opened. In RBR, because of the
      Table_map_log_event , we already have all the tables including base tables in
      the list. But the open_tables() which is generic call takes care of appending
      base tables if the list contains merge tables. There is an assumption in the
      current replication layer logic that these tables (TABLE_LIST type objects) are always
      added in the end of the list. Replication layer maintains the count of
      tables(tables_to_lock_count) that needs to be verified for compatibility check
      and runs through only those many tables from the list and rest of the objects
      in linked list can be skipped. But this assumption is wrong.
      open_tables()->..->add_children_to_list() adds base tables to the list immediately
      after seeing the merge table in the list.
      
      For eg: If the list passed to open_tables() is t1->t2->t3 where t3 is merge
      table (and t1 and t2 are base tables), it adds t1'->t2' to the list after t3.
      New table list looks like t1->t2->t3->t1'->t2'. It looks like it added at the
      end of the list but that is not correct. If the list passed to open_tables()
      is t3->t1->t2 where t3 is merge table (and t1 and t2 are base tables), the new
      prepared list will be t3->t1'->t2'->t1->t2. Where t1' and t2' are of
      TABLE_LIST objects which were added by add_children_to_list() call and replication
      layer should not look into them. Here tables_to_lock_count  will not help as the
      objects are added in between the list.
      
      Fix: After investigating add_children_list() logic (which is called from open_tables()),
      there is no flag/logic in it to skip adding the children to the list even if the
      children are already included in the table list. Hence to fix the issue, a
      logic should be added in the replication layer to skip children in the list by
      checking whether  'parent_l' is non-null or not. If it is children, we will skip 'compatibility'
      check for that table.
      
      Also this patch is not removing 'tables_to_lock_count' logic for the performance issues
      if there are any children at the end of the list, those can be easily skipped directly by
      stopping the loop with tables_to_lock_count check.
      bb32ac1d
  8. 23 Feb, 2016 3 commits
    • Vicențiu Ciorbaru's avatar
    • Vicențiu Ciorbaru's avatar
      [MDEV-8411] Assertion failed in !table->write_set · de1fa452
      Vicențiu Ciorbaru authored
      The reason for the assertion failure is that the update statement for
      the minimal row image sets only the PK column in the write_set of the
      table to true. On the other hand, the trigger aims to update a different
      column.
      
      Make sure that triggers update the used columns accordingly, when being
      processed.
      de1fa452
    • Daniele Sciascia's avatar
      refs codership/mysql-wsrep#201 · c6659345
      Daniele Sciascia authored
      Fix remaining issues with wsrep_sync_wait and query cache.
      
      - Fixes misplaced call to invalidate query cache in
        Rows_log_event::do_apply_event().
        Query cache was invalidated too early, and allowed old
        entries to be inserted to the cache.
      
      - Reset thd->wsrep_sync_wait_gtid on query cache hit.
        THD->cleanup_after_query is not called in such cases,
        and thd->wsrep_sync_wait_gtid remained initialized.
      c6659345
  9. 10 Feb, 2016 1 commit
  10. 09 Feb, 2016 1 commit
  11. 01 Dec, 2015 1 commit
    • Venkatesh Duggirala's avatar
      Bug#21205695 DROP TABLE MAY CAUSE SLAVES TO BREAK · 2735f0b9
      Venkatesh Duggirala authored
          Problem:
          ========
          1) Drop table queries are re-generated by server
          before writing the events(queries) into binlog
          for various reasons. If table name/db name contains
          a non regular characters (like latin characters),
          the generated query is wrong. Hence it breaks the
          replication.
          2) In the edge case, when table name/db name contains
          64 characters, server is throwing an assert
          assert(M_TBLLEN < 128)
          3) In the edge case, when db name contains 64 latin
          characters, binlog content is interpreted badly
          which is leading replication failure.
      
          Analysis & Fix :
          ================
          1) Parser reads the table name from the query and converts
          it to standard charset(utf8) and stores it in table_name variable.
          When drop table query is regenerated with the same table_name
          variable, it should be converted back to the original charset
          from standard charset(utf8).
      
          2) Latin character takes two bytes for each character. Limit
          of the identifier is 64. SYSTEM_CHARSET_MBMAXLEN is set to '3'.
          So there is a possiblity that tablename/dbname contains 3 * 64.
          Hence assert is changed to
          (M_TBLLEN <= NAME_CHAR_LEN*SYSTEM_CHARSET_MBMAXLEN)
      
          3) db_len in the binlog event header is taking 1 byte.
             db_len is ranged from 0 to 192 bytes (3 * 64).
             While reading the db_len from the event, server
             is casting to uint instead of uchar which is leading
             to bad db_len. This problem is fixed by changing the
             cast type to uchar.
      2735f0b9
  12. 29 Nov, 2015 1 commit
    • Monty's avatar
      Fixes to get all test to run on MacosX Lion 10.7 · c3018b0f
      Monty authored
      This includes fixing all utilities to not have any memory leaks,
      as safemalloc warnings stopped tests from passing on MacOSX.
      
      - Ensure that all clients takes character-set-dir, as the
        libmysqlclient library will use it.
      - mysql-test-run now passes character-set-dir to all external clients.
      - Changed dynstr_free() so that it can be called twice (made freeing code easier)
      - Changed rpl_global_gtid_slave_state to be allocated dynamicly as it
        includes a mutex that needs to be initizlied/destroyed before my_end() is called.
      - Removed rpl_slave_state::init() and rpl_slave_stage::deinit() as
        their job are better handling by constructor and delete.
      - Print alias instead of table_name in check_duplicate_key as
        table_name may have been converted to lower case.
      
      Other things:
      - Fixed a case in time_to_datetime_with_warn() where we where
        using && instead of & in tests
      c3018b0f
  13. 10 Nov, 2015 3 commits
    • Monty's avatar
      MDEV-8426 mysqlbinlog: "Corrupted replication event was detected. · 2f63e2e2
      Monty authored
      Not printing the value" with binlog-row-image=minimal"
      
      Merged Rows_log_event::print_verbose_one_row() and log_event_print_value()
      with MySQL 5.7
      Added flush after writing of Table_map_log_event() to fix wrong order of
      lines in output. This causes a lot of changes in some test results.
      2f63e2e2
    • Monty's avatar
      Ignore MySQL 5.7 log events not relevant for MariaDB · 78771189
      Monty authored
      - XA
      - Transaction_context_event (used by MysQL group replication)
      - View change event (used by MysQL group replication)
      78771189
    • Monty's avatar
      table->write_set was changed if binary logging was used, which caused the · 93d1e5ce
      Monty authored
      changes in query execution plans.
      Fixed by introducing table->rpl_write_set which holds which columns should
      be stored in the binary log.
      
      Other things:
      - Removed some not needed references to read_set and write_set to make
        code really changing read_set and write_set easier to read
        (in opt_range.cc)
      - Added error handling of failed unpack_current_row()
      - Added missing call to mark_columns_needed_for_insert() for DELAYED INSERT
      - Removed not used functions in_read_set() and in_write_set()
      - In rpl_record.cc, removed not used variable error
      93d1e5ce
  14. 22 Oct, 2015 1 commit
  15. 08 Oct, 2015 1 commit
    • Monty's avatar
      MDEV-4487 Allow replication from MySQL 5.6+ when GTID is enabled on the master · a69a6dda
      Monty authored
      MDEV-8685 MariaDB fails to decode Anonymous_GTID entries
      MDEV-5705 Replication testing: 5.6->10.0
      
      - Ignoring GTID events from MySQL 5.6+ (Allows replication from MySQL 5.6+ with GTID enabled)
      - Added ignorable events from MySQL 5.6
      - mysqlbinlog now writes information about GTID and ignorable events.
      - Added more information in error message when replication stops because of wrong information in binary log.
      - Fixed wrong test when write_on_release() should flush cache.
      a69a6dda
  16. 21 Sep, 2015 1 commit
  17. 07 Sep, 2015 1 commit
  18. 04 Sep, 2015 11 commits
  19. 27 Aug, 2015 1 commit
  20. 21 Aug, 2015 2 commits
    • Monty's avatar
      Stage 2 of MDEV-6152: · 1bae0d9e
      Monty authored
      - Added mem_root to all calls to new Item
      - Added private method operator new(size_t size) to Item to ensure that
        we always use a mem_root when creating an item.
      
      This saves use once call to current_thd per Item creation
      1bae0d9e
    • Sergey Vojtovich's avatar
      MDEV-8010 - Avoid sql_alloc() in Items (Patch #1) · 31e365ef
      Sergey Vojtovich authored
      Added mandatory thd parameter to Item (and all derivative classes) constructor.
      Added thd parameter to all routines that may create items.
      Also removed "current_thd" from Item::Item. This reduced number of
      pthread_getspecific() calls from 290 to 177 per OLTP RO transaction.
      31e365ef
  21. 04 Aug, 2015 1 commit
    • Kristian Nielsen's avatar
      MDEV-8302: Duplicate key with parallel replication · 9b9c5e89
      Kristian Nielsen authored
      This bug is essentially another variant of MDEV-7458.
      
      If a transaction conflict caused a deadlock kill of T2 in record_gtid()
      during commit, the code would do a rollback _before_ running
      rgi->unmark_start_commit(). This creates a race where following transactions
      could start too early (before T2 has completed its transaction retry). This
      in turn could lead to replication failure, if there was a conflict that
      caused eg. duplicate key error or similar.
      
      The fix is to remove these rollbacks (in Query_log_event::do_apply_event()
      and Xid_log_event::do_apply_event(). They seem out-of-place; code in
      log_event.cc generally does not roll back on error, this is handled higher
      up.
      
      In addition, because of the extreme difficulty of reproducing bugs like
      MDEV-7458 and MDEV-8302, this patch adds some extra precations to try to
      detect (in debug builds) or prevent (in release builds) similar bugs.
      ha_rollback_trans() will now call unmark_start_commit() if needed (and
      assert in debug build when a caller does rollback without unmark first).
      
      We also add an extra check for thd->killed() so that we avoid doing
      mark_start_commit() if we already have a pending deadlock kill.
      
      And we add a missing unmark_start_commit() call in the error case, found by
      the above assertion.
      9b9c5e89
  22. 31 Jul, 2015 1 commit
  23. 26 Jul, 2015 1 commit
    • Monty's avatar
      Fixed MDEV-8428: Mangled DML statements on 2nd level slave when enabling binlog checksums · f3e578ab
      Monty authored
      Fix was to add a test in Query_log_event::Query_log_event() if we are using
      CREATE ... SELECT and in this case use trans cache, like we do on the master.
      This avoid using (with doesn't have checksum)
      
      Other things:
      - Removed dummy call my_checksum(0L, NULL, 0)
      - More DBUG_PRINT
      - Cleaned up Log_event::need_checksum() to make it more readable (similar as in MySQL 5.6)
      - Renamed variable that was hiding another one in create_table_imp()
      f3e578ab