>
>But it happens more likely if You load more tables
>at once with a script, e.g.
>
>drop table one
>drop table two
>drop table three
>load table one from master
>load table two from master
>load table three from master
>
>> >load table first,second,...,last from master
>> >
>> >this command should load all these tables at once
>> >from the master, so that we can keep the critical
>> >and joined tables together.
>>
>> This would be possible in 3.23 - we can implement SLAVE SYNC, which will
lock
>> all the tables on the master, suck them in, unlock, and update MASTER_POS
to
>> the position at the time of the lock. The downside of this method is, of
>> course, the fact that you will have a lock for a long time, but this can be
>> reduced by a local snapshot, then release of the lock, then download
snapshot
>> over the net.
>
>that's what I meant.
>Even a lock of the master may
>
>> What errors make your remote slave stop? Can you provide some diagnostic
>> messages from the log when that happens?
>
>I'll try to fetch them.
>[...]
>001228 18:14:12 Slave: connected to master '...', replication started in
log
> 'mysqllog.007' at position 73
>ERROR: 1016 Can't open file: 'antz.MYD'. (errno: 144)
>001228 18:14:51 Slave: error running query '...'
>001228 18:14:51 Error running query, slave aborted. Fix the problem,
> and re-start the slave thread with mysqladmin start-slave - log
> 'mysqllog.007' position 73
>[...]
>then follows a lot of db-repair but this does not fix the problem.
Apparently, LOAD TABLE FROM MASTER is buggy - until we get it cleaned up, use
mysqlhotcopy to copy the tables instead. I'll be doing a thorough code
examination shortly.
>
>
>
>> >Then we would need a command to reset synchronisation
>> >on ONE slave, not on all slaves, i.e. to tell THIS slave,
>> >that it is now in sync (because we did those load tables
>> >before) and that he should now start synchronisation at
>> >the current MASTER position.
>>
>> A slave has no knowledge of other slave, and the master does not know
>> anything about slaves until they connect. So all syncing has to be
initiated
>> by the slaves themselves.
>
>yes, but in the documentation is mentioned, to do a
>"reset master" and a "reset slave" on all slaves :-/
The only reason for that is that you did "reset master", which wipes out all
binary logs. In that case, all slaves need to be instructed that the master
has started afresh. It is possible to add another slave to the already
running replication with the following trick:
* lock all table on the master for read ( FLUSH TABLES WITH READ LOCK)
* SHOW MASTER to get the the current log and the current position
* quickly copy all the tables to a local directory ( can be remote, but local
is better to minimize downtime)
* UNLOCK TABLES on the master
* copy all the backed up tables to the slave
* start the slave with --skip-slave-start
* CHANGE MASTER TO MASTER_LOG_POS=remembered_pos,
MASTER_LOG_FILE=remembered_log_file;
* SLAVE START
We do have plans to automate all of that with one command - SLAVE SYNC in
3.23 branch. In 4.0 it will be even better - master tables will not be
locked.
>
>> 3.23.30 has only one minor bugfix in replication. So probably those bugs
that
>> you are hitting are still hiding in the bushes. It would be great if you
guys
>> helped us catch them.
>
>of course, but You will do better, if I have the latest version ;-)
One thing that is nice about 3.23.30 and later on x86 Linux is that if mysqld
by any change gets SIGSEGV, you will see a backtrace in the error log. If it
gets stuck and becomes unresponsive, you can kill it with signal 11 and you
will at least know where it had gotten stuck. But fortunately, the things are
not that bad for you it seems, mysqld is running, the slave thread just keeps
hitting glitches.
--
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
