We recently set up a 4.0.2 slave, which worked fine -- we loaded our data snapshot (taken via mysqldump) and were able to perform complex queries without problems...
However, as soon as we tried to get this machine to act as a slave to a 4.0.1 server it crashed. Immediately upon executing "SLAVE START", we get messages like this in the error log: 020714 01:32:03 mysqld started 020714 1:32:05 InnoDB: Started /usr/sbin/mysqld-max: ready for connections 020714 8:00:28 Slave SQL thread initialized, starting replication in log 'server2-bin.035' at position 579285542, relay log './db1-relay-bin.001' position: 4 020714 8:00:29 Slave I/O thread: connected to master '[EMAIL PROTECTED]:3306', replication started in log 'server2-bin.035' at position 579285542 ERROR: 1146 Table 'test.response' doesn't exist 020714 8:00:30 Slave: error 'Table 'test.response' doesn't exist' on query 'INSERT INTO response SET connect_time=0.073868989944458, page_time=1.53695404529572, site_id='Apt'', error_code=1146 020714 8:00:30 Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'server2-bin.035' position 579285542 020714 8:00:30 Slave SQL thread exiting, replication stopped in log 'server2-bin.035' at position 579285542 020714 8:00:54 Error reading packet from server: (server_errno=1159) 020714 8:00:54 Slave I/O thread killed while reading event 020714 8:00:54 Slave I/O thread exiting, read up to log 'server2-bin.035', position 579993154 020714 8:01:58 /usr/sbin/mysqld-max: Normal shutdown 020714 8:01:58 InnoDB: Starting shutdown... 020714 8:02:05 InnoDB: Shutdown completed 020714 8:02:06 /usr/sbin/mysqld-max: Shutdown Complete 020714 08:02:06 mysqld ended 020714 08:02:16 mysqld started 020714 8:02:17 InnoDB: Started /usr/sbin/mysqld-max: ready for connections 020714 8:02:34 Slave SQL thread initialized, starting replication in log 'FIRST' at position 0, relay log './db1-relay-bin.001' position: 4 ERROR: 1146 Table 'test.response' doesn't exist 020714 8:02:34 Slave: error 'Table 'test.response' doesn't exist' on query 'INSERT INTO response SET connect_time=0.073868989944458, page_time=1.53695404529572, site_id='Apt '', error_code=1146 020714 8:02:34 Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'FIRST' position 0 020714 8:02:34 Slave SQL thread exiting, replication stopped in log 'FIRST' at position 0 020714 8:02:34 Slave I/O thread: connected to master '[EMAIL PROTECTED]:3306', replication started in log 'server2-bin.035' at position 579993154 020714 8:03:02 Error reading packet from server: (server_errno=1159) 020714 8:03:02 Slave I/O thread killed while reading event 020714 8:03:02 Slave I/O thread exiting, read up to log 'server2-bin.035', position 579993478 020714 8:03:25 /usr/sbin/mysqld-max: Normal shutdown 020714 8:03:25 InnoDB: Starting shutdown... 020714 8:03:28 InnoDB: Shutdown completed 020714 8:03:28 /usr/sbin/mysqld-max: Shutdown Complete 020714 08:03:28 mysqld ended 020714 08:03:36 mysqld started 020714 8:03:38 InnoDB: Started /usr/sbin/mysqld-max: ready for connections 020714 8:04:02 Slave SQL thread initialized, starting replication in log 'FIRST' at position 0, relay log './db1-relay-bin.001' position: 4 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=67104768 record_buffer=16773120 sort_buffer=16777208 max_used_connections=0 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 3341931 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x85204a0 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=0xbfe3f248, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80722d8 0x82de908 0x82cb534 0x80e9a58 0x80af595 0x80b04f4 0x80ebf71 0x80ece8f 0x82dbf1c 0x831193a 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=3 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 3 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: 0 020714 08:04:02 mysqld restarted 020714 8:04:04 InnoDB: Started /usr/sbin/mysqld-max: ready for connections 020714 8:04:16 Slave SQL thread initialized, starting replication in log 'FIRST' at position 5600514, relay log './db1-relay-bin.001' position: 51184 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=67104768 record_buffer=16773120 sort_buffer=16777208 max_used_connections=0 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 3341931 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x85204a0 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=0xbfe3f248, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80722d8 0x82de908 0x82cb534 0x80e9a58 0x80af595 0x80b04f4 0x80ebf71 0x80ece8f 0x82dbf1c 0x831193a 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=3 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 3 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: 0 Configuration-wise, we've increased the various memory pools somewhat, but that's it. Also, we rely heavily on InnoDB tables and have about 32GB allocated to the InnoDB tablespace (on the slave). Any ideas? -JF --------------------------------------------------------------------- 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
