I have a configuration under MySQL 4.0.5a using many slaves and one master
under Linux 2.4.18.

The slaves always crash when using the command "load data infile" to
populate a table on the master (the table exists on the slaves).

Maybe this could help:
- The master and the slaves are bind on a specific IP. 
- I did not have the problem when I was not using the "bind-address" option
in the my.cnf file.

Here is the log file of one of the slaves after the crash:

/MYSQL_BIN/mysqld: ready for connections
030210 14:22:33  Slave I/O thread: connected to master
'repli@provisioning-aut-db01:3305',  replication started in log
'bwinf0001-bin.004' at position 31144001
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose
the problem, but since we have already crashed, something is definitely
wrong
and this may fail.

key_buffer_size=10481664
read_buffer_size=131072
sort_buffer_size=1048568
max_used_connections=1
max_connections=2000
threads_connected=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections =
2314220 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x870e360
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbfc3f288, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x808258a
0x828dec8
0x80c4d11
0x80c5bd3
0x81014a1
0x8102551
0x828b9ee
0x82bceca
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow
instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil)  is invalid pointer
thd->thread_id=15

Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 15 did to cause the crash.  In some cases of really
bad corruption, the values shown above may be invalid.

The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 9
030212 15:00:04  mysqld restarted
030212 15:00:07  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 3 1885444325
InnoDB: Doing recovery: scanned up to log sequence number 3 1885444470
030212 15:00:07  InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
96 97 98 99 
InnoDB: Apply batch completed
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 17894355, file name bwinf0001-bin.005
030212 15:00:08  InnoDB: Flushing modified pages from the buffer pool...
030212 15:00:08  InnoDB: Started
/MYSQL_BIN/mysqld: ready for connections

Could anyone help me with that problem ?

Marc.


---------------------------------------------------------------------
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

Reply via email to