1. 09 Oct, 2019 11 commits
  2. 08 Oct, 2019 4 commits
    • Marko Mäkelä's avatar
      Merge 5.5 into 10.1 · d95f96ad
      Marko Mäkelä authored
      d95f96ad
    • Sachin Setiya's avatar
      MDEV-20574 Position of events reported by mysqlbinlog is wrong with encrypted... · 27664ef2
      Sachin Setiya authored
      MDEV-20574 Position of events reported by mysqlbinlog is wrong with encrypted binlogs, SHOW BINLOG EVENTS reports the correct one.
      
      Analysis
      
      Mysqlbinlog output for encrypted binary log
      #Q> insert into tab1 values (3,'row 003')
      #190912 17:36:35 server id 10221  end_log_pos 980 CRC32 0x53bcb3d3  Table_map: `test`.`tab1` mapped to number 19
      # at 940
      #190912 17:36:35 server id 10221  end_log_pos 1026 CRC32 0xf2ae5136     Write_rows: table id 19 flags: STMT_END_F
      
      Here we can see Table_map_log_event ends at 980 but Next event starts at 940.
      And the reason for that is we do not send START_ENCRYPTION_EVENT to the slave
      
      Solution:-
      Send Start_encryption_log_event as Ignorable_log_event to slave(mysqlbinlog),
      So that mysqlbinlog can update its log_pos.
      Since Slave can request multiple FORMAT_DESCRIPTION_EVENT while master does not
      have so We only update slave master pos when master actually have the
      FORMAT_DESCRIPTION_EVENT. Similar logic should be applied for START_ENCRYPTION_EVENT.
      
      Also added the test case when new server reads the data from old server which
      does not send START_ENCRYPTION_EVENT to slave.
      
      Master Slave Upgrade Scenario.
      When Slave is updated first, Slave will have extra logic of handling
      START_ENCRYPTION_EVENT But master willnot be sending START_ENCRYPTION_EVENT.
      So there will be no issue.
      When Master is updated first, It will send  START_ENCRYPTION_EVENT to
      slave , But slave will ignore this event in queue_event.
      27664ef2
    • sachin's avatar
      MDEV-16239 Many test in rpl suite fails · 1e0f09ca
      sachin authored
      Fix rpl_skip_error test.
        We cant reset Slave_skipped_errors(even with FLUSH STATUS), So instead
      of absolute slave_skipped_errors we look for delta of slave_skipped_errors
      Fix rpl.rpl_binlog_errors and binlog_encryption.rpl_binlog_errors
        We create the $load_file and $load_file2 but we never remove them.
      Fix rpl_000011.test
        Instead of real value use delta value , Since flush status wont flush
      LONGLONG variable.
      Fix rpl_row_find_row_debug
        Instead of searching whole log_error_ file we will use search_pattern_in_file
      which runs pattern search only on latest test run , instead of full file.
      Fix rpl_ip_mix rpl_ip_mix2
        We should call reset slave all because we also want to reset master_host
      otherwise show slave status wont be empty and making repeat N a failure.
      Fix rpl_rotate_logs
        First we have to remove master.info file (cleanup) and second we have to
      call reset slave all because if we do not call reset slave all then we wont
      read master.info file beacuse we already have master config in memory.
      And this makes start slave to pass , which shoud fail becuase its permision
      is 000
      Fix circular_serverid0 test
        The reason is that ++dbug_rows_event_count == 2 in queue_event does
      not take --repeat into account. So I have reseted the dbug_rows_event_count
      in if body.
      1e0f09ca
    • Sachin's avatar
      MDEV-20591 Wrong Number of rows in mysqlbinlog output · 01bf9f8c
      Sachin authored
      calc_field_event_length should accurately calculate the size of BLOB type
      fields, Instead of returning just the bytes taken by length it should return
      length bytes + actual length.
      01bf9f8c
  3. 07 Oct, 2019 2 commits
  4. 04 Oct, 2019 1 commit
  5. 03 Oct, 2019 1 commit
  6. 02 Oct, 2019 3 commits
  7. 01 Oct, 2019 5 commits
  8. 30 Sep, 2019 5 commits
    • Robert Bindar's avatar
      MDEV-20647 Fix and enable SphinxSE tests · 576a5f09
      Robert Bindar authored
      576a5f09
    • Alexey Botchkov's avatar
      MDEV-19628 JSON with starting double quotes key is not valid. · 6c2724fc
      Alexey Botchkov authored
      Make the skip_key a bit faster.
      6c2724fc
    • Alexey Botchkov's avatar
      MDEV-19628 JSON with starting double quotes key is not valid. · 6ac2a355
      Alexey Botchkov authored
      First character of the key name is just skipped, so the escapement
      wasn't handled properly.
      6ac2a355
    • Marko Mäkelä's avatar
      Fix -Wunused for CMAKE_BUILD_TYPE=RelWithDebInfo · 46b78526
      Marko Mäkelä authored
      For release builds, do not declare unused variables.
      
      unpack_row(): Omit a debug-only variable from WSREP diagnostic message.
      
      create_wsrep_THD(): Fix -Wmaybe-uninitialized for the PSI_thread_key.
      46b78526
    • Sujatha's avatar
      MDEV-20645: Replication consistency is broken as workers miss the error... · 9b80f930
      Sujatha authored
      MDEV-20645: Replication consistency is broken as workers miss the error notification from an earlier failed group.
      
      Analysis:
      ========
      In general if there are three groups.
      1 - Inserts 32 which fails due to local entry '32' on slave.
      2 - Inserts 33
      3 - Inserts 34
      
      Each group considers itself as a waiter and it waits for prior group 'waitee'.
      This is done in 'register_wait_for_prior_event_group_commit'. If there is no
      other parallel group being scheduled then no waitee will be there.
      
      Let us assume 3 groups are being scheduled in parallel.
      
      3-> waits for 2-> waits for->1
      
      '1' upon completion it checks is there any registered subsequent waiter. If
      so it wakes up the subsequent waiter with its execution status. This execution
      status is stored in wakeup_error.
      
      If '1' failed then it sends corresponding wakeup_error to 2. Then '2' aborts
      and it propagates error to '3'.  So all further commits are aborted.  This
      mechanism works only when all transactions reach a stage where they are
      waiting for their prior commit to complete.
      
      In case of optimistic following scenario occurs.
      
      1,2,3 are scheduled in parallel.
      
      3 - Reaches group_commit_code waits for 2 to complete.
      1 - errors out sets stop_on_error_sub_id=1.
      
      When a group execution results in error its corresponding sub_id is set to
      'stop_on_error_sub_id'. Any new groups queued for execution will check if
      their sub_id is > stop_on_error_sub_id.  If it is true their execution will be
      skipped as prior group execution failed.  'skip_event_group=1' will be set.
      Since the execution of SQL thread is about to stop we just skip execution of
      all the following event groups.  We still do all the normal waiting and wakeup
      processing between the event groups as a simple way to ensure that everything
      is stopped and cleaned up correctly.
      
      Upon error '1' transaction checks for registered waiters. Since no one is
      there it simply goes away.
      
      2 - Starts the execution. It checks do I have a waitee.
      
      Since wait_commit_sub_id == entry->last_committed_sub_id no waitee is set.
      
      Secondly: 'entry->stop_on_error_sub_id' is set by '1'st execution.  Now
      'handle_parallel_thread' code checks if the current group 'sub_id' is greater
      than the 'sub_id' set within 'stop_on_error_sub_id'.
      
      Since the above is true 'skip_event_group=true' is set.  Simply call
      'wait_for_prior_commit' to wakeup all waiters.  Group '2' didn't had any
      waitee and its execution is skipped.  Hence its wakeup_error=0.It sends a
      positive wakeup signal to '3'. Which commits. This results in a missed
      transaction. i.e 33 is missed and 34 is committed.
      
      Fix:
      ===
      When a worker learns that an earlier transaction execution has failed, and it
      should not proceed for further execution, it should mark its own execution
      status as failed so that it alerts its followers to abort as well.
      9b80f930
  9. 27 Sep, 2019 8 commits