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:
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.6 OS:Any
Assigned to: CPU Architecture:Any

[18 Dec 2013 20:57] Julien Duponchelle

The documentation about MySQL replication protocol mention an option: BINLOG_DUMP_NON_BLOCK

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.
[20 Dec 2013 23:15] Sveta Smirnova
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.
[9 Jan 2014 13:56] Sveta Smirnova
In the internal discussion we found that BINLOG_DUMP_NON_BLOCK flag was removed by mistake, therefore re-classifying this bug to "Server: Replication".
[9 Jul 2014 10:56] Jon Stephens
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.


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

[6 Aug 2014 17:45] Laurynas Biveinis
$ 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
  Bug#18000079 - binlog_dump_non_block disappeared in mysql 5.6
  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.
  So in order to test the bug, We are introducing a new option
  (available only for debug builds):
  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;
[7 Aug 2014 5:12] Laurynas Biveinis
$ 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
  Bug#18000079 - binlog_dump_non_block disappeared in mysql 5.6
  Fixing post push pb2 Werror build failure
[7 Aug 2014 5:41] Laurynas Biveinis
$ 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
  	--Mysqlbinglog can't able to check whether it is a 
  	  debug build or not with have_debug.inc. So used