服务器上有MYSQL和PHP代码,出现个奇怪的现象一旦有新的页面被打开,连接数据库,MYSQL就会自动重启,但是刷新一下就好。Number of processes running now: 0
110117 15:10:52  mysqld restarted查看日志就是/tmp/mysql.sock之类的问题,请问大概是哪里出现问题了?用netstat查看,有时会出现好多个mysql.sock,数据库就连不上了,但是通过命令行还是可以登录,为什么呢?

解决方案 »

  1.   

    这个是错误日志中的一段:
    ----------------------------------Number of processes running now: 0
    110117 16:14:44  mysqld restarted
    110117 16:14:44  InnoDB: Started; log sequence number 0 44233
    110117 16:14:44 [Note] Recovering after a crash using mysql-bin
    110117 16:14:44 [Note] Starting crash recovery...
    110117 16:14:44 [Note] Crash recovery finished.
    110117 16:14:44 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
    Version: '5.2.0-falcon-alpha-log'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Server (GPL)
    110117 16:14:44 [Note] SCHEDULER: Loaded 0 events
    mysqld got signal 6;
    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=16777216
    read_buffer_size=258048
    max_used_connections=2
    max_connections=500
    threads_connected=1
    It is possible that mysqld could use up to
    key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 398380 K
    bytes of memory
    Hope that's ok; if not, decrease some variables in the equation.thd: 0x8ffed80
    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=0xb0f581b8, backtrace may not be correct.
    Stack range sanity check OK, backtrace follows:
    0x8228e50
    0xb35402
    0x41dda591
    0x41e0e18b
    0x41e15efd
    0x41e19550
    0x858b58d
    0x824034e
    0x8240065
    0x823f6bd
    0x41f233db
    0x41e7d06e
    New value of fp=(nil) failed sanity check, terminating stack trace!
    Please read http://dev.mysql.com/doc/mysql/en/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=621
    The manual page at http://www.mysql.com/doc/en/Crashing.html contains
    information that should help you find out what is causing the crash.
      

  2.   

    这个是重启的时候报告的错误:-----------------------mysql> *** glibc detected *** /usr/local/mysql/bin/mysqld: free(): invalid pointer: 0x09037d50 ***
    ======= Backtrace: =========
    /lib/libc.so.6[0x41e15efd]
    /lib/libc.so.6(cfree+0x90)[0x41e19550]
    /usr/local/mysql/bin/mysqld(free_root+0x89)[0x858b58d]
    /usr/local/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2ae)[0x824034e]
    /usr/local/mysql/bin/mysqld(_Z10do_commandP3THD+0x81)[0x8240065]
    /usr/local/mysql/bin/mysqld(handle_one_connection+0x26d)[0x823f6bd]
    /lib/libpthread.so.0[0x41f233db]
    /lib/libc.so.6(clone+0x5e)[0x41e7d06e]
    ======= Memory map: ========
      

  3.   

    MYSQL什么版本,硬件情况如何
      

  4.   

    版本:Ver 14.13 Distrib 5.2.0-falcon-alpha, for pc-linux-gnu (i686) using readline 5.0
    硬件:双至强CPU,2G内存,73G SCSI硬盘
    配置文件节选:
    [mysqld]
    port            = 3306
    socket          = /tmp/mysql.sock
    skip-locking
    set-variable = max_connections=500
    key_buffer = 16M
    max_allowed_packet = 16M
    table_cache = 64
    sort_buffer_size = 512K
    net_buffer_length = 8K
    read_buffer_size = 256K
    read_rnd_buffer_size = 512K
    myisam_sort_buffer_size = 8M# close query_cache
    query_cache_type = 0# mysql server has gone away
    wait_timeout = 2880000代码在本地测试机上测试通过,没出现这样的问题,放上去之后出现的,不知道什么原因,本地测试机配置非常低
      

  5.   

    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.问题可能出在这里 
      

  6.   

    千万不要拿alpha版用于生产环境。至少要一个正式release版
      

  7.   

    根据经验!可能是有死缓存信息!方法是清空!看看有没有死的进程Id,清空所有缓存,如/tmp等文件夹
      

  8.   

    我没听说过这个linux和mysql5.2。
    也没见过这句话set-variable = max_connections=500
    重启linux试试,不行的话建议重装其他发行版linux和mysql。
      

  9.   


    alpha版 是啥意思啊?
      

  10.   


    alpha版就是未经正式发布的试用版。mysqld got signal 6;
    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.这段出错的原因说的比较含糊。即可能是某二进制库文件的问题,也可能是硬件问题,或者是不适当的编译,或者是配置。总之无法判断。不过你把本机所有的日志文件全删掉(包括数据文件,不过这样数据库就等同于重装了),也许能解决这个问题。