This seems to have not gotten through... Perhaps the spam filter ate it? (sql, query)
-JF > -----Original Message----- > From: Jon Frisby [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 15, 2002 4:27 PM > To: [EMAIL PROTECTED] > Subject: MySQL 4.0.2 replication going bonkers? > > > 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
