1. 15 Sep, 2007 1 commit
  2. 14 Sep, 2007 2 commits
  3. 07 Sep, 2007 1 commit
  4. 04 Sep, 2007 1 commit
  5. 30 Aug, 2007 1 commit
  6. 29 Aug, 2007 5 commits
  7. 28 Aug, 2007 1 commit
  8. 27 Aug, 2007 5 commits
  9. 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
  10. 22 Aug, 2007 5 commits
  11. 21 Aug, 2007 2 commits
  12. 20 Aug, 2007 4 commits
  13. 17 Aug, 2007 4 commits
  14. 16 Aug, 2007 7 commits