1. 30 Jan, 2008 5 commits
  2. 29 Jan, 2008 3 commits
    • sven@riska.(none)'s avatar
      BUG#32434: Replication doesn't work between 5.2.1-a_drop6p9-log and 5.1.22-ndb-6.3.6-telco · dd913eaa
      sven@riska.(none) authored
      Problem: When slave reads format_description_log_event, it checks if the
      master is a version that uses an old binlog format. See also BUG#27779.
      Not all possible server_versions were listed.
      Fix: Check for all server_versions which use the old binlog_format.
      dd913eaa
    • hezx@mail.hezx.com's avatar
      update test result · 7572a9e3
      hezx@mail.hezx.com authored
      7572a9e3
    • hezx@mail.hezx.com's avatar
      BUG#26489 Corruption in relay logs · e4f37eab
      hezx@mail.hezx.com authored
      Here is the scenario that causes the failure.(by Mats)
      
      1. The to-be corrupt log event (let's call it X), is split into two
         packets B and C on the network level (net_write_buff()). The parts
         are X = (x',x''). The part x' ends up in packet B and part x''
         ends up in packet C. Prior to the corrupt event X, the event Y has
         been written successfully, but has been split into two packets as
         well, which we call (y',y'').
      2. The master sends packet A = (y'',x') to the slave, increases the
         packet sequence number, the slave receives the packet, but fails
         to reply before the master gets a timeout.
      3. Since the master got a timeout, it reports failure, and aborts
         sending the binary log by exiting mysql_binlog_send(). However, it
         leaves the buffer intact, still holding y'' (but not x', since the
         write_pos is not increased).
      4. After exiting mysql_binlog_send(), the master does a
         disconnection of the client thread, which involves sending an
         error message e to the client (i.e., the slave).
      5. In this case, net_write_buff() is used again, but this time the
         old contents of the packet is used so that the new packet is
         D = (y'',e). Note that this will use a new packet sequence number,
         since the packet number was increased in step 2.
      6. The slave receives the tail y'' of the Y log event, concatenates
         this with x' (which it already received), and writes the event
         (x',y'') it to the relay log since it hasn't noticed anything is
         amiss.
      7. It then tries to read more bytes, which is either e (if the length
         given for X just happened to match the length given for Y, or just
         plain garbage because the slave is out of sync with what is
         actually sent.
      8. After a while, the SQL thread tries to execute the event (x',y''),
         which is very likely to be just nonsense.
      
      The problem can be fixed by not resetting net->error after the call of 
      mysql_binlog_send, so the error message will not be sent and the connection
      will be closed.
      e4f37eab
  3. 25 Jan, 2008 1 commit
    • hezx@mail.hezx.com's avatar
      BUG#33862 completely failed DROP USER statement gets replicated · 750c4022
      hezx@mail.hezx.com authored
      The problem is when create/rename/drop users, the statement was logged regardless of error, even if no data has been changed, the statement was logged.
      
      After this patch, create/rename/drop users don't write the binlog if the statement makes no changes, if the statement does make any changes, log the statement with possible error code.
      
      This patch is based on the patch for BUG#29749, which is not pushed
      750c4022
  4. 22 Jan, 2008 1 commit
  5. 21 Jan, 2008 2 commits
  6. 15 Jan, 2008 1 commit
  7. 14 Jan, 2008 5 commits
  8. 11 Jan, 2008 3 commits
  9. 10 Jan, 2008 1 commit
    • sven@riska.(none)'s avatar
      BUG#27779: Slave cannot read old rows log events. · 617ea4d6
      sven@riska.(none) authored
      Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and
      slave is mysql-5.1-new-rpl. The reason is that, in
      mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in
      mysql-5.1-new-rpl.
      Fix (in mysql-5.1-new-rpl):
       (1) detect that the server that generated the events uses the old
      format, by checking the server version of the format_description_log_event
      This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha,
      mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd.
       (2) if the generating server is old, map old event types to new event
      types using a permutation array.
      
      I've also added a test case which reads binlogs for four different
      versions.
      617ea4d6
  10. 06 Jan, 2008 6 commits
  11. 02 Jan, 2008 2 commits
  12. 31 Dec, 2007 1 commit
  13. 25 Dec, 2007 1 commit
  14. 24 Dec, 2007 4 commits
  15. 23 Dec, 2007 1 commit
  16. 22 Dec, 2007 1 commit
  17. 21 Dec, 2007 2 commits
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Merge aelkin@bk-internal.mysql.com:/home/bk/mysql-5.0-rpl · 7801f290
      aelkin/elkin@koti.dsl.inet.fi authored
      into  koti.dsl.inet.fi:/home/elkin/MySQL/TEAM/FIXES/5.0/bug33435-load_data_read_buffer_size
      7801f290
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      BUG#30435 loading large LOAD DATA INFILE breaks slave with · 0ca3250e
      aelkin/elkin@koti.dsl.inet.fi authored
                read_buffer_size set on master
      BUG#33413 show binlog events fails if binlog has event size of close
                to max_allowed_packet
      
      
      The size of Append_block replication event was determined solely by
      read_buffer_size whereas the rest of replication code deals with
      max_allowed_packet.
      When the former parameter was set to larger than the latter there were
      two artifacts: the master could not read events from binlog;
      show master events did not show.
      
      Fixed with 
      - fragmenting the used io-cached buffer into pieces each size of less
        than max_allowed_packet (bug#30435)
      - incrementing show-binlog-events handling thread's max_allowed_packet
        with the max estimated for the replication header size
      0ca3250e