Diana Soares wrote:
>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.
>
We tried that among many other things. It turns out that their is some
kind of problem related to temporary tables. MySQL AB is investigating.
>
>
>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.
>>
>>
>
>
>
---------------------------------------------------------------------
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