From: sasha
Date: October 27 2000 7:09pm
Subject: Re: Problems wit LOAD TABLE xyz FROM MASTER
List-Archive: http://lists.mysql.com/internals/68
Message-Id: <39F9D2E0.CECA8AB8@mysql.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

3.23.27 replication-wise is identical to 3.23.26, so LOAD TABLE FROM MASTER
should work the same. Do you have a way of repeating the problem? 

Another possiblity ( I would have to check the code to be sure), is that your
change to ignore the errors could leave some state variables in an inconsistent
state. Ok, I've taken a look at the code - found a couple of problems:

 * each time you hit the slave error there was a small memory leak - about the
size of the query + a bit of overhead. With the slave thread aborting on error,
this was not as bad, although still a bug. If it did not abort, then you leak
about 100-200 bytes for every bad query. I have now fixed this.

 * more serious problem - every time you hit the bad query, glob_mi structure,
which keeps track of the position of the slave thread in the master ( you can
see most of it with SHOW SLAVE STATUS) is not being updated. This is correct
behaviour - if the query could not be run, we exit the slave, notify sysadmin,
and when he fixes the conflict and restarts the slave thread, we will try this
query again. However, if you really want to ignore the error, you need to do

  mi->inc_pos(event_len);
  flush_master_info(mi);

in exec_event() before you return in the case when error is detected as well -
otherwise, when you restart the slave, it will start reading from the wrong
position. This is probably why you had that strange error with the slave
deciding to re-do one replication log - the offset was wrong, and it missed the
log rotation event.

-- 
MySQL Development Team
   __  ___     ___ ____  __ 
  /  |/  /_ __/ __/ __ \/ /   Sasha Pachev <sasha@stripped>
 / /|_/ / // /\ \/ /_/ / /__  MySQL AB, http://www.mysql.com/
/_/  /_/\_, /___/\___\_\___/  Provo, Utah, USA
       <___/