Bug #46640 output from mysqlbinlog command in 5.1 breaks replication
Submitted: 11 Aug 0:54 Modified: 11 Nov 15:45
Reporter: Ryan Huddleston
Status: Closed
Category:Server: RBR Severity:S2 (Serious)
Version:5.1.36 OS:Any
Assigned to: Daogang Qu Target Version:5.1+
Tags: regression
Triage: Triaged: D2 (Serious)

[11 Aug 0:54] Ryan Huddleston 
Description:
We extensively use mysqlbinlog in 5.0 to move database between different servers, Clone a
database then catch the data up (roll-forward). Restore from backups and roll-forward
etc.

The problem is that in 5.1 the mysqbinlog command outputs the "format description BINLOG
statement" at the top of the mysqlbinlog output e.g.:

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#090810 15:14:07 server id 13  end_log_pos 106  Start: binlog v 4, server v 5.1.36-log
created 090810 15:14:07
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
BINLOG '
n42ASg8NAAAAZgAAAGoAAAABAAQANS4xLjM2LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;

This is very dangerous as when I pipe this into another server it overrides the server_id
setting from that server and logs it as the wrong server_id
 
Another side effect of this is we have one server that runs all the mysqlbinlog commands
and the newerer mysqlbinlog binary breaks when piping 5.0 binlogs to 5.0 servers as they
don't understand the "format description BINLOG statement"

How to repeat:
# DB server 1
create database foo;
use foo;
create table foo (foo int) engine=innodb;
flush logs;
insert into foo values (1), (2);
show master status; # grab File

# DB server 2 (in dual master configuration with DB server 3)
create database foo;
use foo;
create table foo (foo int) engine=innodb;
mysqlbinlog --database=foo <binlog file above> | mysql -h <dbserver #2> foo
mysql -h <dbserver #2> foo
mysql> select count(*) from foo; #notice this number is growing rapidly
# drop the foo table before the disk on your server fills up!

Suggested fix:
I'm trying to understand the relationship between the "format description BINLOG
statement" and the server_id. It seems to me that the server_id stored in the "format
description BINLOG statement" should never override the server_id of the server executing
the statements. 

* If the connection reading the SQL statements is not the SQL replication thread then it
should ignore the server_id contained in the "format description BINLOG statement". 
* If the above can't be fixed quickly having an option to override the server_id encoded
in the "format description BINLOG statement" with a new server_id via a command line
option to mysqlbinlog

Additionally:
* Don't output the "format description BINLOG statement" when reading mysql 5.0 binlogs
[11 Aug 8:49] Susanne Ebrecht 
Many thanks for writing a bug report.

Verified as described.
[26 Aug 8:51] Mats Kindahl 
Hi Ryan!

In order to avoid emitting the Format description log event, use the option
--base64-output=never. However, this only works for binary logs not containing  RBR
events, since it will give an error if there are RBR events in the binary log.

Piping output from mysqlbinlog in this manner should not change the server_id, so we will
investigate what is the problem.
[1 Sep 23:39] Ryan Huddleston 
Mats I investigated --base64-output=never but that requires I do binlog_format=STATEMENT
but I can't do this as switching to STATEMENT based replication breaks applications where
'READ-COMMITTED' is used as they get this error:

Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not
safe for binlog mode 'STATEMENT'
[8 Sep 13:36] Kristian Nielsen 
It seems this problem was introduced with the patch for Bug#32407.

This patch makes mysqlbinlog output the format description event, which is
needed to correctly execute BINLOG statements.

However the patch also introduces an unrelated change which makes BINLOG
statements share more of the code path used to execute binlog events in the
slave sql thread. This includes using the server id of the event rather than
that of the running server, as well as other things that seem redundant or
wrong for executing the BINLOG statement.

I added some discussion of the issue here:

    http://askmonty.org/worklog/Server-RawIdeaBin/index.pl?tid=50

Maybe the offending part of the patch for Bug#32407 should be reverted.

By the way, as far as I can see in the code, the server id problem is not
related to the format description event. Rather, _every_ event in BINLOG
statements is applied with the originating server id in MySQL >=5.1.24 (after
patch for Bug#32407).
[8 Sep 14:37] Sven Sandberg 
Kristian, I think you are right, we should not set server_id (or date) when executing
BINLOG statements. I think the fix is to just move the lines

  thd->server_id = ev->server_id; // use the original server id for logging
  thd->set_time();                            // time the query

away from apply_event_and_update_pos and into exec_relay_log_event. This reverts part of
my patch for BUG#32407 (where the lines were moved from exec_relay_log_event to
apply_event_and_update_pos).

Just a remark on your worklog: I don't understand the comment "2. When one applies
'format description binlog statement' at the slave, it will change the slave's server_id
when applied." found under high-level description. I don't think this is true. The slave
sql thread only remembers the server_id so that the event can be logged with the
server_id of the originating server (to make circular replication work). I don't think
the slave server's server_id is changed.

Did you mean "2. When one executes a BINLOG statement containing a
format_description_log_event, it will change the client's server_id and subsequent
statments executed in the same client will be logged with the server_id of the
format_description_log_event"? I think that is part of this bug and it will be solved by
moving the two lines as above.
[8 Sep 14:46] Sven Sandberg 
Hi Ryan,

If mysqlbinlog is from 5.0, it will not output Format_description_events. If mysqlbinlog
is from 5.1, it will output Format_description_events unless you specify
--base64-output=never. The flag --base64-output=never only works on binlogs that do not
contain any row events. So you can use --base64-output=never when you read binlogs from
5.0 servers, and omit --base64-output=never when you read binlogs from 5.1 servers.

I agree that it would be better if mysqlbinlog from 5.1 did not output
Format_description_events when reading a binlog generated by a 5.0 server. But you can
use the fix above until that is fixed.
[9 Sep 11:32] Kristian Nielsen 
Sven,

Thanks for your comments. Yes, agree with your interpretation of the worklog,
thanks for the clarification.

Agree that moving the two lines you suggested will fix the server id
issue. But it seems to me that this would still leave code in
apply_event_and_update_pos() that is redundant in the case of BINLOG statement
execution:

    thd->lex->current_select= 0;
    ev->thd = thd

This is redundant, as it it already done earlier in the execution of a
statement.

    if (!ev->when) ev->when= my_time(0)

I think this is redundant, not 100% sure though.

    ev->update_pos(rli)

This seems confusing to have in the execution of a BINLOG statement. At best
it is probably harmless, as the rli is the "fake" rli constructed for
executing BINLOG statements only. But there seems no point, and it causes
complications for every change in update_pos()-related code, as it must be
carefully checked that these changes have no effect in the case of BINLOG
statement. Why do it at all?

When I checked the update_pos() related code, I found only once action that
seemed to have effect for BINLOG: the setting of
rli->relay_log.description_event_for_exec for the format description
event. But this would in any case be cleaner to do inside
mysql_client_binlog_statement(), keeping the description_event_for_exec as a
local variable, and simplifying the memory management for this one.

That is why I suggest to replace the call of apply_event_and_update_pos() in
mysql_client_binlog_statement() with a direct call to ev->apply_event(), and
explicitly handle description_event_for_exec in the finction. Or am I missing
something?
[9 Sep 12:15] Sven Sandberg 
Kristian, the ev->update_pos() is also needed for BINLOG statements that contain a row
event, becuase it does some cleanup (including flushing row events to binlog and calling
ha_autocommit_or_rollback()). But I think this too is a bit weird to do in
ev->update_pos(), so that should probably also be moved to ev->apply_event().

It seems straightforward to move code freely between update_pos and apply_event, because
they are only called from apply_event_and_update_pos(), and a call to apply_event() is
always followed by a call to update_pos() (unless apply_event failed) and update_pos() is
always preceded by a call to apply_event().

So I agree, we should at least invetigate the possibility to refactor so that we can call
apply_event() directly from mysql_client_binlog_statement.
[9 Sep 17:29] Kristian Nielsen 
Committed a possible fix along the lines discussed above:

    https://lists.launchpad.net/maria-developers/msg00926.html
[25 Sep 10:14] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/84587

3117 Dao-Gang.Qu@sun.com	2009-09-25
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any
case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[28 Sep 7:35] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/84781

3117 Dao-Gang.Qu@sun.com	2009-09-28
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any
case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[29 Sep 7:29] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/84934

3117 Dao-Gang.Qu@sun.com	2009-09-29
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any
case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[29 Sep 14:43] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/84990

3117 Dao-Gang.Qu@sun.com	2009-09-29
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any
case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[2 Oct 8:22] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/85471

3146 Dao-Gang.Qu@sun.com	2009-10-02
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any
case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[9 Oct 5:57] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/86258

3146 Dao-Gang.Qu@sun.com	2009-10-09
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[13 Oct 3:53] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/86620

3162 Dao-Gang.Qu@sun.com	2009-10-13
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/log_event_old.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[13 Oct 10:14] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/86651

3649 Dao-Gang.Qu@sun.com	2009-10-13 [merge]
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/log_event_old.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[14 Oct 3:39] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/86746

3165 Dao-Gang.Qu@sun.com	2009-10-14
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/log_event_old.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[14 Oct 4:02] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/86747

3654 Dao-Gang.Qu@sun.com	2009-10-14 [merge]
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread,
introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong
server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the
running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed
by
      the BINLOG statement, and the server_id of the server executing the statements will

      not be overrided by the server_id stored in the 'format description BINLOG
statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/log_event_old.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in
any case
        makes more sense, and is needed as update_pos() is no longer called when
executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been

        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains
code 
        that is redundant and/or harmful (especially setting thd->server_id).
[21 Oct 21:19] Magnus Blaudd 
Unfortunately  the bug contains two coding errors that turn up as warnings. Please fix
ASAP

sql/log_event.cc: 7544
	suggest parentheses around assignment used as truth value

+    if (error= rows_event_stmt_cleanup(rli, thd))

sql/log_event_old.cc: 1845
	suggest parentheses around assignment used as truth value

+    if (error= trans_commit_stmt(thd))
[22 Oct 8:35] Bugs System 
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (version
source revid:alik@sun.com-20091019135554-s1pvptt6i750lfhv) (merge vers: 6.0.14-alpha)
(pib:13)
[22 Oct 9:07] Bugs System 
Pushed into 5.5.0-beta (revid:alik@sun.com-20091022060553-znkmxm0g0gm6ckvw) (version
source revid:alik@sun.com-20091019131708-bc6pv55x6287a0wc) (merge vers: 5.5.0-beta)
(pib:13)
[23 Oct 5:16] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/87874

3191 Dao-Gang.Qu@sun.com	2009-10-23
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
      
      Added parentheses around assignment used as truth value for suppressing warnings.
[23 Oct 5:31] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/87878

3684 Dao-Gang.Qu@sun.com	2009-10-23 [merge]
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
      
      Added parentheses around assignment used as truth value for suppressing warnings.
[23 Oct 5:39] Daogang Qu 
The warnings were be suppressed.
[4 Nov 10:26] Bugs System 
Pushed into 5.1.41 (revid:joro@sun.com-20091104092152-qz96bzlf2o1japwc) (version source
revid:kristofer.pettersson@sun.com-20091103162305-08l4gkeuif2ozsoj) (merge vers: 5.1.41)
(pib:13)
[5 Nov 18:27] Jon Stephens 
Documented bugfix in the 5.1.41, 5.5.0, and 6.0.14 changelogs:

        A problem with the BINLOG statement in the output from
        mysqlbinlog could break replication; statements could be logged
        with the server ID stored within events by the BINLOG statement
        rather than the ID of the running server. With this fix, the
        server ID of the server executing the statements can no longer
        be overridden by the server ID stored in the binary log format
        description statement.

Closed.
[11 Nov 7:50] Bugs System 
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091110093407-rw5g8dys2baqkt67) (version
source revid:alik@sun.com-20091109080109-7dxapd5y5pxlu08w) (merge vers: 6.0.14-alpha)
(pib:13)
[11 Nov 8:02] Bugs System 
Pushed into 5.5.0-beta (revid:alik@sun.com-20091109115615-nuohp02h8mdrz8m2) (version
source revid:alik@sun.com-20091105092041-sp6eyod7sdlfuj3b) (merge vers: 5.5.0-beta)
(pib:13)
[11 Nov 15:45] Jon Stephens 
Re-closed. See my previous comment.