We have a 4.0.4-beta master and slave. The slaving process starts correctly, but randomly (and frequently) has issues.
When the server starts, it will slave, but eventually will hit one of two conditions: - Duplicate key insert error (we re-sync'd the slave by hand during the install, copying databases by hand, etc, so they're known good) - Signal 8. The database will hit Signal 8, die, and be restarted. Immediately upon restarting, it dies, and restarts, ad naseum. The Dupkicate Key insert doesn't have any decent or recognizable accompanying errors, however the signal 8 leaves the following in the logs: 021003 18:04:03 mysqld restarted /usr/local/libexec/mysqld: ready for connections 021003 18:04:03 Slave I/O thread: connected to master '[EMAIL PROTECTED]:3306', replication started in log 'dbmaster1-bin.002' at position 110748 mysqld got signal 8; 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=402649088 read_buffer_size=1044480 sort_buffer_size=1048568 max_used_connections=0 max_connections=2500 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1308888 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x82d4d00 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=0x5c190f98, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80940d7 0x81798fb 0x8095aa5 0x8056129 0x8057109 0x804b7d2 0x80b513a 0x80cd4ad 0x809f16d 0x80a2d8c 0x80db5a5 0x81183c6 0x8117147 0x8177394 0x81aa79a 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 0x82d0ba6 = UPDATE /* sess_read:update timestamp */ admin.login SET login.last_modified = NOW(), login.mumbojumbo = FLOOR(RAND()*99999999) WHERE login.uid IN( 0, 27 ) AND login.session = 'fb103efea43b37b049cb1d54f400724d' thd->thread_id=2 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 2 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 I have run a backtrace, and came up with the following: 0x80940d7 _Z15handle_segfaulti + 503 0x81798fb sem_timedwait + 95 0x8095aa5 rnd + 53 0x8056129 _ZN13Item_func_mul3valEv + 41 0x8057109 _ZN15Item_func_floor7val_intEv + 41 0x804b7d2 _ZN4Item13save_in_fieldEP5Field + 226 0x80b513a _Z11fill_recordR4ListI4ItemES2_ + 106 0x80cd4ad _Z12mysql_updateP3THDP13st_table_listR4ListI4ItemES6_PS4_P8st_orderm15enum_duplicates13thr_lock_type + 2093 0x809f16d _Z21mysql_execute_commandv + 4829 0x80a2d8c _Z11mysql_parseP3THDPcj + 300 0x80db5a5 _ZN15Query_log_event10exec_eventEP17st_relay_log_info + 293 0x81183c6 _Z22process_io_create_fileP14st_master_infoP21Create_file_log_event + 166 0x8117147 _Z10next_eventP17st_relay_log_info + 423 0x8177394 pthread_handle_free + 72 0x81aa79a __nss_lookup_function + 686 Reverting the slave to 4.0.3 fixed the instability AFAICT (it's only been reverted for a brief period). The master has remained at 4.0.4 Let me know if you need further info. Thanks -- Shane Allen <[EMAIL PROTECTED]> --------------------------------------------------------------------- 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
