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