BUG#49259: Slave I/O thread could not register on master

The slave thread changed the format of the information it used to
connect to the master after patch for BUG 13963.  This resulted
in old master getting confused, thence rejecting the slave
connection attempt.

In particular, patch for BUG 13963 removed the rpl_recovery_rank
variable which was, at that time, packed together with the rest
of the information which the slave would use to register itself
on the master. Based on this data, the master would then assert
that the number of bytes received in the connection command was
consistent to what it was expecting. 

Therefore, given that a slave, patched with the aforementioned
patch, would not pack the four bytes related to the
rpl_recovery_rank variable, the old master would reject the
connection attempt. It would assume that the data was
inconsistent (fewer bytes than it was expecting) and return 
an error.

We fix this by faking an rpl_recovery_rank variable when
registering the slave on the master. In practice this reverts a
small part of patch for BUG 13963, the one related to the slave
connecting to the master.

sql/repl_failsafe.cc:
  Added bypassing of removed rpl_recovery_rank variable information in
  packet. This should also make more sense when old servers connect
  to a new master (ie, master with patch for BUG 13963). If this was not
  done, the new master could interpert information an old slave sends as
  master_id, when in fact it could be the rpl_recovery_rank data.
sql/slave.cc:
  Faking a rpl_recovery_rank so that we can register as a slave in
  an old master.

0 files changed, 0 insertions, 0 deletions