An error occurred fetching the project authors.
  1. 14 Dec, 2007 2 commits
    • sven@riska.(none)'s avatar
      BUG#32407: Impossible to do point-in-time recovery from older binlog · 5cc348a6
      sven@riska.(none) authored
      Problem: it is unsafe to read base64-printed events without first
      reading the Format_description_log_event (FD).  Currently, mysqlbinlog
      cannot print the FD.
      
      As a side effect, another bug has also been fixed: When mysqlbinlog
      --start-position=X was specified, no ROLLBACK was printed. I changed
      this, so that ROLLBACK is always printed.
      
      This patch does several things:
      
       - Format_description_log_event (FD) now print themselves in base64
         format.
      
       - mysqlbinlog is now able to print FD events.  It has three modes:
          --base64-output=auto    Print row events in base64 output, and print
                                  FD event.  The FD event is printed even if
                                  it is outside the range specified with
                                  --start-position, because it would not be
                                  safe to read row events otherwise. This is
                                  the default.
      
          --base64-output=always  Like --base64-output=auto, but also print
                                  base64 output for query events.  This is
                                  like the old --base64-output flag, which
                                  is also a shorthand for
                                  --base64-output=always
      
          --base64-output=never   Never print base64 output, generate error if
                                  row events occur in binlog.  This is
                                  useful to suppress the FD event in binlogs
                                  known not to contain row events (e.g.,
                                  because BINLOG statement is unsafe,
                                  requires root privileges, is not SQL, etc)
      
       - the BINLOG statement now handles FD events correctly, by setting
         the thread's rli's relay log's description_event_for_exec to the
         loaded event.
      
         In fact, executing a BINLOG statement is almost the same as reading
         an event from a relay log.  Before my patch, the code for this was
         separated (exec_relay_log_event in slave.cc executes events from
         the relay log, mysql_client_binlog_statement in sql_binlog.cc
         executes BINLOG statements).  I needed to augment
         mysql_client_binlog_statement to do parts of what
         exec_relay_log_event does.  Hence, I did a small refactoring and
         moved parts of exec_relay_log_event to a new function, which I
         named apply_event_and_update_pos.  apply_event_and_update_pos is
         called both from exec_relay_log_event and from
         mysql_client_binlog_statement.
      
       - When a non-FD event is executed in a BINLOG statement, without
         previously executing a FD event in a BINLOG statement, it generates
         an error, because that's unsafe.  I took a new error code for that:
         ER_NO_FORMAT_DESCRIPTION_EVENT_BEFORE_BINLOG_STATEMENTS.
      
         In order to get a decent error message containing the name of the
         event, I added the class method char*
         Log_event::get_type_str(Log_event_type type), which returns a
         string name for the given Log_event_type.  This is just like the
         existing char* Log_event::get_type_str(), except it is a class
         method that takes the log event type as parameter.
      
         I also added PRE_GA_*_ROWS_LOG_EVENT to Log_event::get_type_str(),
         so that names of old rows event are properly printed.
      
       - When reading an event, I added a check that the event type is known
         by the current Format_description_log_event. Without this, it may
         crash on bad input (and I was struck by this several times).
      
       - I patched the following test cases, which all contain BINLOG
         statements for row events which must be preceded by BINLOG
         statements for FD events:
          - rpl_bug31076
      
      While I was here, I fixed some small things in log_event.cc:
      
       - replaced hard-coded 4 by EVENT_TYPE_OFFSET in 3 places
      
       - replaced return by DBUG_VOID_RETURN in one place
      
       - The name of the logfile can be '-' to indicate stdin.  Before my
         patch, the code just checked if the first character is '-'; now it
         does a full strcmp().  Probably, all arguments that begin with a -
         are already handled somewhere else as flags, but I still think it
         is better that the code reflects what it is supposed to do, with as
         little dependencies as possible on other parts of the code.  If we
         one day implement that all command line arguments after -- are
         files (as most unix tools do), then we need this.
      
      I also fixed the following in slave.cc:
      
       - next_event() was declared twice, and queue_event was not static but
         should be static (not used outside the file).
      5cc348a6
    • sven@riska.(none)'s avatar
      BUG#26395: if crash during autocommit update to transactional table on master, slave fails · ab396c1d
      sven@riska.(none) authored
      Now, every transaction (including autocommit transactions) starts with
      a BEGIN and ends with a COMMIT/ROLLBACK in the binlog.
      Added a test case, and updated lots of test case result files.
      ab396c1d
  2. 13 Dec, 2007 1 commit
  3. 12 Dec, 2007 2 commits
    • aelkin@dl145j.mysql.com's avatar
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug#31552 Replication breaks when deleting rows from out-of-sync table · d8d6db6f
      aelkin/elkin@koti.dsl.inet.fi authored
          without PK
      Bug#31609 Not all RBR slave errors reported as errors
      bug#32468 delete rows event on a table with foreign key constraint fails
      
      The first two bugs comprise idempotency issues.
      First, there was no error code reported under conditions of the bug
      description although the slave sql thread halted.
      Second, executions were different with and without presence of prim key in
      the table.
      Third, there was no way to instruct the slave whether to ignore an error
      and skip to the following event or to halt.
      Fourth, there are handler errors which might happen due to idempotent
      applying of binlog but those were not listed among the "idempotent" error
      list.
      
      All the named issues are addressed.
      Wrt to the 3rd, there is the new global system variable, changeble at run
      time, which controls the slave sql thread behaviour.
      The new variable allows further extensions to mimic the sql_mode
      session/global variable.
      To address the 4th, the new bug#32468 had to be fixed as it was staying
      in the way.
      d8d6db6f
  4. 05 Dec, 2007 1 commit
    • mats@kindahl-laptop.dnsalias.net's avatar
      BUG#31583 (5.1-telco-6.1 -> 5.1.22. Slave returns Error in unknown event): · eca01720
      mats@kindahl-laptop.dnsalias.net authored
      In the patch for BUG#21842, the code for handling old rows events were
      refactored.  There were a bug in the refactored code (possibly introduced
      after the patch for BUG#21842) that caused caused the refactored old events
      to read a columns bitmap after image even though there is no such bitmap
      for old events. As a result, the reading got out of sync, and started reading
      invalid data.
      
      This patch removes all trace of the after image column bitmap from the refactored
      old events and removes functions that are no longer needed because they are empty. 
      eca01720
  5. 28 Nov, 2007 1 commit
  6. 23 Nov, 2007 1 commit
  7. 13 Nov, 2007 2 commits
  8. 12 Nov, 2007 1 commit
  9. 09 Nov, 2007 1 commit
    • mats@capulet.net's avatar
      BUG#31793 (log event corruption causes crash): · a432d3de
      mats@capulet.net authored
      When running mysqlbinlog on a 64-bit machine with a corrupt relay log,
      it causes mysqlbinlog to crash. In this case, the crash is caused
      because a request for 18446744073709534806U bytes is issued, which
      apparantly can be served on a 64-bit machine (speculatively, I assume)
      but this causes the memcpy() issued later to copy the data to segfault.
      
      The request for the number of bytes is caused by a computation
      of data_len - server_vars_len where server_vars_len is corrupt in such
      a sense that it is > data_len. This causes a wrap-around, with the
      the data_len given above.
      
      This patch adds a check that if server_vars_len is greater than
      data_len before the substraction, and aborts reading the event in
      that case marking the event as invalid. It also adds checks to see
      that reading the server variables does not go outside the bounds
      of the available space, giving a limited amount of integrity check.
      a432d3de
  10. 07 Nov, 2007 2 commits
  11. 30 Oct, 2007 1 commit
    • mats@kindahl-laptop.dnsalias.net's avatar
      BUG#19958 (RBR idempotency issue for UPDATE and DELETE): · 9cc4b8dd
      mats@kindahl-laptop.dnsalias.net authored
      The rpl_trigger test case indicated a problem with idempotency support when run
      under row-based replication, which this patch fixes.
      
      However, despite this, the test is not designed for execution under row-based
      replication and hence rpl_trigger.test is not executed under row-based
      replication.
      
      The problem is that the test expects triggers to be executed when the slave
      updates rows on the slave, and this is (deliberately) not done with row-based
      replication.
      9cc4b8dd
  12. 29 Oct, 2007 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #27571 asynchronousity in setting mysql_`query`::error and · 27436f0b
      aelkin/elkin@koti.dsl.inet.fi authored
                 Query_log_event::error_code
      
      A query can perform completely having the local var error of mysql_$query
      zero, where $query in insert, update, delete, load,
      and be  binlogged with error_code e.g KILLED_QUERY while there is no
      reason do to so.
      That can happen because Query_log_event consults thd->killed flag to
      evaluate error_code.
      
      Fixed with implementing a scheme suggested and partly implemented at
      time of bug@22725 work-on. error_status is cached immediatly after the
      control leaves the main rows-loop and that instance always corresponds
      to `error' the local of mysql_$query functions. The cached value
      is passed to Query_log_event constructor, not the default thd->killed
      which can be changed in between of the caching and the constructing.
      27436f0b
  13. 25 Oct, 2007 1 commit
  14. 24 Oct, 2007 1 commit
  15. 20 Oct, 2007 1 commit
    • mats@kindahl-laptop.dnsalias.net's avatar
      Bug#31702 (Missing row on slave causes assertion failure under row-based replication): · 24ea15a2
      mats@kindahl-laptop.dnsalias.net authored
      When replicating an update pair (before image, after image) under row-based
      replication, and the before image is not found on the slave, the after image
      was not discared, and was hence read as a before image for the next row.
      Eventually, this lead to an after image being read outside the block of rows
      in the event, causing an assertion to fire.
      
      This patch fixes this by reading the after image in the event that the row
      was not found on the slave, adds some extra debug assertion to catch future
      errors earlier, and also adds a few non-debug checks to prevent reading
      outside the block of the event.
      24ea15a2
  16. 19 Oct, 2007 2 commits
  17. 18 Oct, 2007 1 commit
    • davi@moksha.com.br's avatar
      Bug#21557 entries in the general query log truncated at 1000 characters. · dd135211
      davi@moksha.com.br authored
      The general log write function (general_log_print) uses printf style
      arguments which need to be pre-processed, meaning that the all arguments
      are copied to a single buffer and the problem is that the buffer size is
      constant (1022 characters) but queries can be much larger then this.
      
      The solution is to introduce a new log write function that accepts a
      buffer and it's length as arguments. The function is to be used when
      a formatted output is not required, which is the case for almost all
      query write-to-log calls.
      
      This is a incompatible change with respect to the log format of prepared
      statements.
      dd135211
  18. 13 Oct, 2007 1 commit
  19. 11 Oct, 2007 1 commit
    • mats@kindahl-laptop.dnsalias.net's avatar
      BUG#29549 (Endians: test failures on Solaris): · c4298a3f
      mats@kindahl-laptop.dnsalias.net authored
      Refactoring code to add parameter to pack() and unpack() functions with
      purpose of indicating if data should be packed in little-endian or
      native order. Using new functions to always pack data for binary log
      in little-endian order. The purpose of this refactoring is to allow
      proper implementation of endian-agnostic pack() and unpack() functions.
      
      Eliminating several versions of virtual pack() and unpack() functions
      in favor for one single virtual function which is overridden in
      subclasses.
      
      Implementing pack() and unpack() functions for some field types that
      packed data in native format regardless of the value of the
      st_table_share::db_low_byte_first flag.
      
      The field types that were packed in native format regardless are:
      Field_real, Field_decimal, Field_tiny, Field_short, Field_medium,
      Field_long, Field_longlong, and Field_blob.
      
      Before the patch, row-based logging wrote the rows incorrectly on
      big-endian machines where the storage engine defined its own
      low_byte_first() to be FALSE on big-endian machines (the default
      is TRUE), while little-endian machines wrote the fields in correct
      order. The only known storage engine that does this is NDB. In effect,
      this means that row-based replication from or to a big-endian
      machine where the table was using NDB as storage engine failed if the
      other engine was either non-NDB or on a little-endian machine.
      
      With this patch, row-based logging is now always done in little-endian
      order, while ORDER BY uses the native order if the storage engine
      defines low_byte_first() to return FALSE for big-endian machines.
      
      In addition, the max_data_length() function available in Field_blob
      was generalized to the entire Field hierarchy to give the maximum
      number of bytes that Field::pack() will write.
      c4298a3f
  20. 04 Oct, 2007 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #29309 Incorrect "Seconds_Behind_Master" value in SHOW SLAVE STATUS after FLUSH LOGS · 501cce2b
      aelkin/elkin@koti.dsl.inet.fi authored
      Report claims that Seconds_behind_master behaves unexpectedly. 
      
      Code analysis shows that there is an evident flaw in that treating of FormatDescription event is wrong
      so  that after FLUSH LOGS on slave the Seconds_behind_master's calculation slips and incorrect
      value can be reported to SHOW SLAVE STATUS. 
      Even worse is that the gap between the correct and incorrect deltas grows with time.
      
      Fixed with prohibiting changes to rpl->last_master_timestamp by artifical events (any kind of).
      suggestion as comments is added how to fight with lack of info on the slave side by means of
      new heartbeat feature coming.
      
      The test can not be done ealily fully determistic.
      501cce2b
  21. 24 Sep, 2007 1 commit
  22. 20 Sep, 2007 1 commit
  23. 14 Sep, 2007 1 commit
  24. 07 Sep, 2007 1 commit
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #28430 Failure in replication of innodb partitioned tables on row/mixed format. · a60f7988
      holyfoot/hf@mysql.com/hfmain.(none) authored
      In the ha_partition::position() we don't calculate the number
      of the partition of the record, but use m_last_part value instead,
      relying on that it's previously set by some other call like ::write_row().
      Delete_rows_log_event::do_exec_row() calls find_and_fetch_row(),
      where we used position() + rnd_pos() call for the InnoDB-based PARTITION-ed
      table as there HA_PRIMARY_KEY_REQUIRED_FOR_POSITION enabled.
      
      fixed by introducing new handler::rnd_pos_by_record() method to be
      used for random record-based positioning
      a60f7988
  25. 28 Aug, 2007 2 commits
  26. 27 Aug, 2007 2 commits
  27. 26 Aug, 2007 1 commit
    • rafal@quant.(none)'s avatar
      BUG#21842 (Cluster fails to replicate to innodb or myisam with err 134 · f8b64e17
      rafal@quant.(none) authored
      using TPC-B):
       
      Problem: A RBR event can contain incomplete row data (only key value and
      fields which have been changed). In that case, when the row is unpacked
      into record and written to a table, the missing fields get incorrect NULL
      values leading to master-slave inconsistency.
       
      Solution: Use values found in slave's table for columns which are not given
      in the rows event. The code for writing a single row uses the following 
      algorithm: 
      
      1. unpack row_data into table->record[0],
      2. try to insert record,
      3. if duplicate record found, fetch it into table->record[0],
      4. unpack row_data into table->record[0],
      5. write table->record[0] into the table.
      
      Where row_data is the row as stored in the data area of a rows event. 
      Thus:
      
      a) unpacking of row_data happens at the time when row is written into 
       a table,
      
      b) when unpacking (in step 4), only columns present in row_data are 
       overwritten - all other columns remain as they were found in the table.
       
      Since all data needed for the above algorithm is stored inside 
      Rows_log_event class, functions which locate and write rows are turned 
      into methods of that class.
      
      replace_record()     -> Rows_log_event::write_row()
      find_and_fetch_row() -> Rows_log_event::find_row()
      
      Both methods take row data from event's data buffer - the row being 
      processed is pointed by m_curr_row. They unpack the data as needed into 
      table's record buffers record[0] or record[1]. When row is unpacked, 
      m_curr_row_end is set to point at next row in the data buffer.
      
      Other changes introduced in this changeset:
      
      - Change signature of unpack_row(): don't report errors and don't
      setup table's rw_set here. Errors can happen only when setting default 
      values in prepare_record() function and are detected there.
       
      - In Rows_log_event and derived classes, don't pass arguments to
      the execution primitives (do_...() member functions) but use class
      members instead.
      
      - Move old row handling code into log_event_old.cc to be used by 
      *_rows_log_event_old classes.
      
      Also, a new test rpl_ndb_2other is added which tests basic replication 
      from master using ndb tables to slave storing the same tables using 
      (possibly) different engine (myisam,innodb).
        
      Test is based on existing tests rpl_ndb_2myisam and rpl_ndb_2innodb. 
      However, these tests doesn't work for various reasons and currently are 
      disabled (see BUG#19227).
        
      The new test differs from the ones it is based on as follows:
        
      1. Single test tests replication with different storage engines on slave 
      (myisam, innodb, ndb).
        
      2. Include file extra/rpl_tests/rpl_ndb_2multi_eng.test containing 
      original tests is replaced by extra/rpl_tests/rpl_ndb_2multi_basic.test 
      which doesn't contain tests using partitioned tables as these don't work 
      currently. Instead, it tests replication to a slave which has more or 
      less columns than master.
        
      3. Include file include/rpl_multi_engine3.inc is replaced with 
      include/rpl_multi_engine2.inc. The later differs by performing slightly 
      different operations (updating more than one row in the table) and 
      clearing table with "TRUNCATE TABLE" statement instead of "DELETE FROM" 
      as replication of "DELETE" doesn't work well in this setting.
        
      4. Slave must use option --log-slave-updates=0 as otherwise execution of 
      replication events generated by ndb fails if table uses a different 
      storage engine on slave (see BUG#29569).
      f8b64e17
  28. 16 Aug, 2007 4 commits
  29. 14 Aug, 2007 1 commit
  30. 13 Aug, 2007 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris · e53a73e2
      monty@mysql.com/nosik.monty.fi authored
      Faster thr_alarm()
      Added 'Opened_files' status variable to track calls to my_open()
      Don't give warnings when running mysql_install_db
      Added option --source-install to mysql_install_db
      
      I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
      index_read()      -> index_read_map()
      index_read_idx()  -> index_read_idx_map()
      index_read_last() -> index_read_last_map()
      e53a73e2