Jon, ----- Original Message ----- From: "Jon Frisby" <[EMAIL PROTECTED]> To: "'Heikki Tuuri'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, November 09, 2002 12:17 AM Subject: RE: Replication and temp tables...
> Hrm, upon further digging it seems that this may be the offending query: > > # at 416149583 > #021107 16:50:31 server id 1 log_pos 416149583 Intvar > SET INSERT_ID=6437606; > # at 416149611 > #021107 16:50:31 server id 1 log_pos 416149583 Query thread_id=19890708 > exec_time=0 error_code=0 > SET TIMESTAMP=1036716631; > INSERT INTO click (offer_id, user_id, points, expected_revenue, > actual_revenue, status, interaction_id, category_id, when_clicked, > when_updated, manualapproval, isautoimpression, campaign_id, > sequence_log_id) VALUES(294, 5729550, 100, 19, NULL, "Clicked", 35, 11, > NOW(), NULL, 0, 0, 0, NULL); > # at 416149939 > #021107 16:50:31 server id 1 log_pos 416149583 Intvar > SET INSERT_ID=27770130; > # at 416149967 > #021107 16:50:31 server id 1 log_pos 416149583 Query thread_id=19890710 > exec_time=0 error_ > > This doesn't appear to be any different than the tens of thousands of > other inserts into that table that happen each day... if this repeats, then the way to find the bug is to build locally: shell> CFLAGS="-g -O3" CXXFLAGS="-g -O3" ./configure --with-innodb shell> make and run the slave mysqld inside gdb: shell> gdb mysqld You may need to make gdb to ignore certain signals: gdb >handle SIGUSR1 nostop noprint gdb >handle SIGUSR2 nostop noprint gdb >handle SIGWAITING nostop noprint gdb >handle SIGLWP nostop noprint gdb >handle SIGPIPE nostop gdb >handle SIGALRM nostop gdb >handle SIGHUP nostop gdb >handle SIGTERM nostop noprint gdb >handle SIG32 nostop noprint then: gdb> run When it crashes, gdb> bt full gdb> print *someinterestingvariable gdb> print someotherinterestingvariable ... > -JF Regards, Heikki > > -----Original Message----- > > From: Heikki Tuuri [mailto:Heikki.Tuuri@;innodb.com] > > Sent: Friday, November 08, 2002 12:22 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Replication and temp tables... > > > > > > Jon, > > > > ----- Original Message ----- > > From: ""Jon Frisby"" <[EMAIL PROTECTED]> > > Newsgroups: mailing.database.mysql > > Sent: Thursday, November 07, 2002 9:39 PM > > Subject: Replication and temp tables... > > > > > > > Using 4.0.2 for both server and client, replicating the > > following query > > > seems to have caused a crash on the client: > > > > > > CREATE TEMPORARY TABLE tmp1 ( > > > day DATE NOT NULL, > > > campaign_id INT NOT NULL, > > > > > > clicks INT, > > > clicked FLOAT, > > > approved FLOAT, > > > users_raw INT, > > > users_coreg INT, > > > users_fullreg INT, > > > visitors INT, > > > > > > PRIMARY KEY (day, campaign_id) > > > ) TYPE=InnoDB; > > > > > > > > > The error log (w/ symbols resolved) is: > > > > > > 021107 8:51:32 Slave SQL thread initialized, starting > > replication in > > > log 'db1-bin.085' at position 113214771, relay log > > './db3-relay-bin.001' > > > position: 25762057 > > > 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=268431360 > > > record_buffer=2093056 > > > sort_buffer=1048568 > > > max_used_connections=0 > > > max_connections=50 > > > threads_connected=1 > > > It is possible that mysqld could use up to > > > key_buffer_size + (record_buffer + > > sort_buffer)*max_connections = 415539 > > > K > > > bytes of memory > > > Hope that's ok; if not, decrease some variables in the equation. > > > > > > thd=0x85261b0 > > > 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 init_signals__Fv + 16 > > > 0x82de908 _end + 239148 > > > 0x82cb534 _end + 160344 > > > 0x80e9a58 register_slave__FP3THDPUcUi + 228 > > > 0x80af595 > > exec_event__21Create_file_log_eventP17st_relay_log_info + 537 > > > 0x80b04f4 __15Query_log_eventP3THDPCcb + 160 > > > 0x80ebf71 nisam_open + 1837 > > > 0x80ece8f _nisam_search + 79 > > > 0x82dbf1c _end + 228416 > > > 0x831193a _end + 448094 > > > 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 > > > > > > > > > Any ideas on what might be causing this? > > > > using a temporary InnoDB table inside LOCK TABLES caused an assertion > > failure in versions < 4.0.4. But I do not see how the slave > > would use it > > inside LOCK TABLES, and there is no assertion printout either. > > > > There have been quite a lot of bug fixes since July 10, when 4.0.2 was > > released. Some of them might fix the problem. > > > > Can you repeat the crash if you manually create temporary > > tables on the > > master? > > > > > -JF > > > > Best regards, > > > > Heikki Tuuri > > Innobase Oy > > --- > > InnoDB - transactions, hot backup, and foreign key support for MySQL > > See http://www.innodb.com, download MySQL-Max from > http://www.mysql.com > > sql query --------------------------------------------------------------------- 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
