MySQL Bugs: #71178: BINLOG_DUMP_NON_BLOCK disapear in MySQL 5.6

Bug #71178	BINLOG_DUMP_NON_BLOCK disapear in MySQL 5.6
Submitted:	18 Dec 2013 20:57	Modified:	9 Jul 2014 10:56
Reporter:	Julien Duponchelle	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	5.6	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	BINLOG_DUMP_NON_BLOCK

Description:
Hi,

The documentation about MySQL replication protocol mention an option: BINLOG_DUMP_NON_BLOCK
http://dev.mysql.com/doc/internals/en/com-binlog-dump.html

I check the source code this options disappear in MySQL 5.6 and MySQL 5.7 but exists in MySQL 5.5.

The problem is you can not write a client who exit when the binlog is finished. Some of my users of 
https://github.com/noplay/python-mysql-replication use it for consuming all the event starting at a position and exit when they are synchronize with the server.

For you it's a bug? Or a deprecated feature?

How to repeat:
Consume the replication stream with the option BINLOG_DUMP_NON_BLOCK enable. With MySQL the client receive EOF when all event  have been send. But with MySQL 5.6 the client never receive EOF.

Suggested fix:
Two options:
- Add the option BINLOG_DUMP_NON_BLOCK to MySQL 5.6
- Remove the mention of BINLOG_DUMP_NON_BLOCK in http://dev.mysql.com/doc/internals/en/com-binlog-dump.html and http://dev.mysql.com/doc/internals/en/com-binlog-dump-gtid.html.

Thank you for the report.

Verified as described, but I think suggested fix can confuse users more. I prefer to simply update internals manual with a note that BINLOG_DUMP_NON_BLOCK does not exist in 5.6 and up anymore.

In the internal discussion we found that BINLOG_DUMP_NON_BLOCK flag was removed by mistake, therefore re-classifying this bug to "Server: Replication".

Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

Documented fix in the MySQL 5.6.20 and 5.7.5 changelogs, as follows:

    Client applications should be able to set the
    BINLOG_DUMP_NON_BLOCK flag in the initial handshake packet
    (COM_BINLOG_DUMP). Clients connecting to a server issuing a 
    COM_BINLOG_DUMP with the flag unset do not get an EOF when 
    the server has sent the last event in the binary log, which 
    causes the connection to block. This flag, which was removed in 
    error in MySQL 5.6.5, is now restored in the current release.

    As part of this fix, a new --connection-server-id option is
    added to mysqlbinlog. This option can be used to test a MySQL
    server for the presence of this issue.

Closed.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

$ bzr log -n0 -r 5951
------------------------------------------------------------
revno: 5951
committer: Neeraj Bisht <neeraj.x.bisht@oracle.com>
branch nick: 5.6
timestamp: Wed 2014-05-21 16:27:56 +0530
message:
Bug#18000079 - binlog_dump_non_block disappeared in mysql 5.6

Problem:-
Before 5.6.5 or so, it was possible for a client(like Mysql-connector) to
set the BINLOG_DUMP_NON_BLOCK flag in the initial handshake
packet (COM_BINLOG_DUMP). Then this was (wrongly) removed, and the current
patch adds it back. As such, clients connecting to a server issuing a
COM_BINLOG_DUMP with the flag not set will not get an EOF when the server
has sent the last event in the binary log. The connection will block.

In all versions, it is possible to get the same behaviour by setting
server_id=0(while is the default value of server_id).
A slave server never sets the flag and never sets server_id=0, because it never
needs non-blocking behaviour.
Mysqlbinlog never sets the flag. If it needs the non-blocking behaviour,
it sets server_id=0.

In order to test the patch, we need mysqlbinlog to set the flag when it needs
non-blocking behaviour. However, since mysqlbinlog also sets server_id=0,
*just changing it to allow* setting the flag in mysqlbinlog will not verify the bug
in an unpatched server.

Currently it is possible to set the server_id used by mysqlbinlog, but only
if *blocking* behaviour is requested (using mysqlbinlog --stop-never-slave-server-id=X),
and then the value 0 is not allowed.

Solution:-

So in order to test the bug, We are introducing a new option
(available only for debug builds):
--connection-server-id=NUMBER
When mysqlbinlog is run in blocking mode:
- default is 1
- range is 1..maxint
When mysqlbinlog is run in non-blocking mode:
- default is 0
- range is 0..maxint
The difference in default value is needed for backward compatibility.
The difference in range is needed since 0 forces non-blocking mode regardless of the flag.

With this in place, we can verify the bug in a non-patched server by running mysqlbinlog
in non-blocking mode and set connection-server-id=1.

NOTES:- A few remarks about this flag and also about the clients shipped with the server
that make use of COM_BINLOG_DUMP.

- An IO thread never issues (and has never issued)
COM_BINLOG_DUMP with the flag set;

- Mysqlbinlog will set the flag always, unless --stop-never is specified.

- The dump thread falls back to non-blocking behavior if the
connecting client states that it has server_id=0;

$ bzr log -n0 -r 5959
------------------------------------------------------------
revno: 5959
committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com>
branch nick: mysql-5.6
timestamp: Fri 2014-05-23 10:42:55 +0530
message:
  Bug#18000079 - binlog_dump_non_block disappeared in mysql 5.6
  
  Fixing post push pb2 Werror build failure

$ bzr log -n0 -r 5973
------------------------------------------------------------
revno: 5973
committer: Neeraj Bisht <neeraj.x.bisht@oracle.com>
branch nick: 5.6
timestamp: Thu 2014-06-05 18:06:08 +0530
message:
  Bug#18000079 - BINLOG_DUMP_NON_BLOCK DISAPPEARED IN MYSQL 5.6
  
  	--Mysqlbinglog can't able to check whether it is a 
  	  debug build or not with have_debug.inc. So used 
  	  mysqlbinlog_have_debug.inc.