-
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;
Neeraj Bisht authoredProblem:- 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