Hi, just sending a reply in case that someone else has the same problem. I solved the problem by decreasing the key-buffer from 320M to 288M.
On Wed, 2002-07-03 at 12:24, Diana Soares wrote: > Hi, > > I have 2 machine dual-processor Pentium III, with 1G of memory. > They have the same software, same architecture, with one-way replication > beetween. Versions: > > [root@localhost tmp]# mysql -V > mysql Ver 11.18 Distrib 3.23.51, for pc-linux-gnu (i686) > [root@localhost tmp]# cat /etc/redhat-release > Red Hat Linux release 7.3 (Valhalla) > > Since i've installed mysql 3.23.51 (mysql binaries) that i'm having some > problems, the worst is the slave's mysqld crashes all days. What > happens: > > Every day, a cron job in the slave starts at 3:30AM to generate some > reports. The maximum load is about 2.0. Mysqld daemon crashes and > restarts itself. > > All queries in this cron job are done in the master. The slave only > replicates... I don't understand why the slave keeps crashing. The > master logs are clean, with no error at all, the reports are ok. > > > * The log error at the slave: > > 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 agaist 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=335540224 > record_buffer=2093056 > sort_buffer=2097144 > max_used_connections=1 > max_connections=150 > threads_connected=0 > It is possible that mysqld could use up to > key_buffer_size + (record_buffer + sort_buffer)*max_connections = 941474 > K > bytes of memory > Hope that's ok, if not, decrease some variables in the equation > > 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... > Stack range sanity check OK, backtrace follows: > 0x806edf4 > 0x811fd28 > 0x81050f3 > 0x810410f > 0x8103df9 > 0x80b5f04 > 0x809524c > 0x80943b7 > 0x80940c3 > 0x808cf67 > 0x80760ce > 0x8079a8c > 0x80cfb31 > 0x80d1249 > Stack trace seems successful - bottom reached > ... > Trying to get some variables. > Some pointers may be invalid and cause the dump to abort... > thd->query at 0x8287e59 = CREATE TEMPORARY TABLE IF NOT EXISTS tmp_uv > SELECT campaign_id , user, count(user) as views FROM Log_Impr_all > WHERE campaign_id IN (9) GROUP BY campaign_id , user HAVING views>0 > thd->thread_id=18 > ... > > > * Stack resolved: > > 0x806edf4 handle_segfault__Fi + 428 > 0x811fd28 pthread_sighandler + 184 > 0x81050f3 _hp_movelink + 11 > 0x810410f _hp_write_key + 595 > 0x8103df9 heap_write + 73 > 0x80b5f04 write_row__7ha_heapPc + 72 > 0x809524c end_update__FP4JOINP13st_join_tableb + 440 > 0x80943b7 sub_select__FP4JOINP13st_join_tableb + 255 > 0x80940c3 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 415 > 0x808cf67 > >mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP13select_result > + 4055 > 0x80760ce mysql_execute_command__Fv + 2570 > 0x8079a8c mysql_parse__FP3THDPcUi + 216 > 0x80cfb31 exec_event__FP3THDP6st_netP14st_master_infoi + 1133 > 0x80d1249 handle_slave__FPv + 2309 > > > (i don't understand what this means..) > Thank you for reading this, i hope someone can give me a light. -- Diana Soares --------------------------------------------------------------------- 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
