Skip to content
  • Neeraj Bisht's avatar
    fdcc19cf
    Bug#18000079 - binlog_dump_non_block disappeared in mysql 5.6 · fdcc19cf
    Neeraj Bisht authored
    
    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;
    fdcc19cf
    Bug#18000079 - binlog_dump_non_block disappeared in mysql 5.6
    Neeraj Bisht authored
    
    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;
Loading