Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Mysql is not working
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Mysql is not working

How to fix this issue.
Waiting for mysql to restart...............................................................finished.
mysql has failed, please contact the sysadmin (result was "mysql is not running").

Thanks

Comments

  • Switch it off at the wall, turn it back on again.

  • Check your error logs?

    tail -f /var/log/mysql.err
    
  • Hire a system administrator, I would guess this is relating to changes you made from the other thread you had ( http://lowendtalk.com/discussion/34049/whm-is-not-upgrading-now#latest )

    Thanked by 1netomx
  • @Silvenga said:
    Check your error logs?

    > tail -f /var/log/mysql.err
    > 

    tail: cannot open `/var/log/mysql.err' for reading: No such file or directory

  • The log file is /var/lib/mysql/<hostname>.err

  • @wych said:
    Hire a system administrator...

    this.

  • @noosVPS said:
    The log file is /var/lib/mysql/<hostname>.err

    This is error file.

    140908 11:04:01 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
    2014-09-08 11:04:01 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
    2014-09-08 11:04:01 26954 [Note] Plugin 'FEDERATED' is disabled.
    2014-09-08 11:04:01 26954 [Note] InnoDB: Using atomics to ref count buffer pool pages
    2014-09-08 11:04:01 26954 [Note] InnoDB: The InnoDB memory heap is disabled
    2014-09-08 11:04:01 26954 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    2014-09-08 11:04:01 26954 [Note] InnoDB: Compressed tables use zlib 1.2.3
    2014-09-08 11:04:01 26954 [Note] InnoDB: Using Linux native AIO
    2014-09-08 11:04:01 26954 [Note] InnoDB: Using CPU crc32 instructions
    2014-09-08 11:04:01 26954 [Note] InnoDB: Initializing buffer pool, size = 128.0M
    2014-09-08 11:04:01 26954 [Note] InnoDB: Completed initialization of buffer pool
    2014-09-08 11:04:01 26954 [Note] InnoDB: Highest supported file format is Barracuda.
    2014-09-08 11:04:01 26954 [Note] InnoDB: Log scan progressed past the checkpoint lsn 6923856396
    2014-09-08 11:04:01 26954 [Note] InnoDB: Database was not shutdown normally!
    2014-09-08 11:04:01 26954 [Note] InnoDB: Starting crash recovery.
    2014-09-08 11:04:01 26954 [Note] InnoDB: Reading tablespace information from the .ibd files...
    2014-09-08 11:04:02 26954 [Note] InnoDB: Restoring possible half-written data pages
    2014-09-08 11:04:02 26954 [Note] InnoDB: from the doublewrite buffer...
    InnoDB: Doing recovery: scanned up to log sequence number 6923861060
    2014-09-08 11:04:02 26954 [Note] InnoDB: Starting an apply batch of log records to the database...
    InnoDB: Progress in percent: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
    InnoDB: Apply batch completed
    2014-09-08 11:04:02 26954 [Note] InnoDB: 128 rollback segment(s) are active.
    2014-09-08 11:04:02 26954 [Note] InnoDB: Waiting for purge to start
    2014-09-08 11:04:02 7f2beb5fe700 InnoDB: Assertion failure in thread 139826609252096 in file trx0purge.cc line 699
    InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no
    InnoDB: We intentionally generate a memory trap.
    InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
    InnoDB: If you get repeated assertion failures or crashes, even
    InnoDB: immediately after the mysqld startup, there may be
    InnoDB: corruption in the InnoDB tablespace. Please refer to
    InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
    InnoDB: about forcing recovery.
    15:04:02 UTC - 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=8388608
    read_buffer_size=131072
    max_used_connections=0
    max_threads=151
    thread_count=0
    connection_count=0
    It is possible that mysqld could use up to
    key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68245 K bytes of memory
    Hope that's ok; if not, decrease some variables in the equation.

    Thread pointer: 0x0
    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_bottom = 0 thread_stack 0x40000
    /usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8c8af5]
    /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65ffb4]
    /lib64/libpthread.so.0(+0xf710)[0x7f2c2285a710]
    /lib64/libc.so.6(gsignal+0x35)[0x7f2c21505635]
    /lib64/libc.so.6(abort+0x175)[0x7f2c21506e15]
    /usr/sbin/mysqld[0xa25d16]
    /usr/sbin/mysqld[0xa268c4]
    /usr/sbin/mysqld[0xa27206]
    /usr/sbin/mysqld[0xa17f8a]
    /lib64/libpthread.so.0(+0x79d1)[0x7f2c228529d1]
    /lib64/libc.so.6(clone+0x6d)[0x7f2c215bb86d]
    The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
    information that should help you find out what is causing the crash.
    140908 11:04:02 mysqld_safe mysqld from pid file /var/lib/mysql/fastest.csofts.net.pid ended
    140908 11:05:14 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
    2014-09-08 11:05:15 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
    2014-09-08 11:05:15 1379 [Note] Plugin 'FEDERATED' is disabled.
    2014-09-08 11:05:15 1379 [Note] InnoDB: Using atomics to ref count buffer pool pages
    2014-09-08 11:05:15 1379 [Note] InnoDB: The InnoDB memory heap is disabled
    2014-09-08 11:05:15 1379 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    2014-09-08 11:05:15 1379 [Note] InnoDB: Compressed tables use zlib 1.2.3
    2014-09-08 11:05:15 1379 [Note] InnoDB: Using Linux native AIO
    2014-09-08 11:05:15 1379 [Note] InnoDB: Using CPU crc32 instructions
    2014-09-08 11:05:15 1379 [Note] InnoDB: Initializing buffer pool, size = 128.0M
    2014-09-08 11:05:15 1379 [Note] InnoDB: Completed initialization of buffer pool
    2014-09-08 11:05:15 1379 [Note] InnoDB: Highest supported file format is Barracuda.
    2014-09-08 11:05:15 1379 [Note] InnoDB: Log scan progressed past the checkpoint lsn 6923856396
    2014-09-08 11:05:15 1379 [Note] InnoDB: Database was not shutdown normally!
    2014-09-08 11:05:15 1379 [Note] InnoDB: Starting crash recovery.
    2014-09-08 11:05:15 1379 [Note] InnoDB: Reading tablespace information from the .ibd files...
    2014-09-08 11:05:15 1379 [Note] InnoDB: Restoring possible half-written data pages
    2014-09-08 11:05:15 1379 [Note] InnoDB: from the doublewrite buffer...
    InnoDB: Doing recovery: scanned up to log sequence number 6923861070
    2014-09-08 11:05:15 1379 [Note] InnoDB: Starting an apply batch of log records to the database...
    InnoDB: Progress in percent: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
    InnoDB: Apply batch completed
    2014-09-08 11:05:15 1379 [Note] InnoDB: 128 rollback segment(s) are active.
    2014-09-08 11:05:15 1379 [Note] InnoDB: Waiting for purge to start
    2014-09-08 11:05:15 7f8e235fe700 InnoDB: Assertion failure in thread 140248455571200 in file trx0purge.cc line 699
    InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no
    InnoDB: We intentionally generate a memory trap.
    InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
    InnoDB: If you get repeated assertion failures or crashes, even
    InnoDB: immediately after the mysqld startup, there may be
    InnoDB: corruption in the InnoDB tablespace. Please refer to
    InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
    InnoDB: about forcing recovery.
    15:05:15 UTC - 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=8388608
    read_buffer_size=131072
    max_used_connections=0
    max_threads=151
    thread_count=0
    connection_count=0
    It is possible that mysqld could use up to
    key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68245 K bytes of memory
    Hope that's ok; if not, decrease some variables in the equation.

    Thread pointer: 0x0
    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_bottom = 0 thread_stack 0x40000
    /usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8c8af5]
    /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65ffb4]
    /lib64/libpthread.so.0(+0xf710)[0x7f8e59ec9710]
    /lib64/libc.so.6(gsignal+0x35)[0x7f8e58b74635]
    /lib64/libc.so.6(abort+0x175)[0x7f8e58b75e15]
    /usr/sbin/mysqld[0xa25d16]
    /usr/sbin/mysqld[0xa268c4]
    /usr/sbin/mysqld[0xa27206]
    /usr/sbin/mysqld[0xa17f8a]
    /lib64/libpthread.so.0(+0x79d1)[0x7f8e59ec19d1]
    /lib64/libc.so.6(clone+0x6d)[0x7f8e58c2a86d]
    The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
    information that should help you find out what is causing the crash.
    140908 11:05:15 mysqld_safe mysqld from pid file /var/lib/mysql/fastest.csofts.net.pid ended
    140908 11:10:41 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
    2014-09-08 11:10:42 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
    2014-09-08 11:10:42 9339 [Note] Plugin 'FEDERATED' is disabled.
    2014-09-08 11:10:42 9339 [Note] InnoDB: Using atomics to ref count buffer pool pages
    2014-09-08 11:10:42 9339 [Note] InnoDB: The InnoDB memory heap is disabled
    2014-09-08 11:10:42 9339 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    2014-09-08 11:10:42 9339 [Note] InnoDB: Compressed tables use zlib 1.2.3
    2014-09-08 11:10:42 9339 [Note] InnoDB: Using Linux native AIO
    2014-09-08 11:10:42 9339 [Note] InnoDB: Using CPU crc32 instructions
    2014-09-08 11:10:42 9339 [Note] InnoDB: Initializing buffer pool, size = 128.0M
    2014-09-08 11:10:42 9339 [Note] InnoDB: Completed initialization of buffer pool
    2014-09-08 11:10:42 9339 [Note] InnoDB: Highest supported file format is Barracuda.
    2014-09-08 11:10:42 9339 [Note] InnoDB: Log scan progressed past the checkpoint lsn 6923856396
    2014-09-08 11:10:42 9339 [Note] InnoDB: Database was not shutdown normally!
    2014-09-08 11:10:42 9339 [Note] InnoDB: Starting crash recovery.
    2014-09-08 11:10:42 9339 [Note] InnoDB: Reading tablespace information from the .ibd files...
    2014-09-08 11:10:42 9339 [Note] InnoDB: Restoring possible half-written data pages
    2014-09-08 11:10:42 9339 [Note] InnoDB: from the doublewrite buffer...
    InnoDB: Doing recovery: scanned up to log sequence number 6923861080
    2014-09-08 11:10:42 9339 [Note] InnoDB: Starting an apply batch of log records to the database...
    InnoDB: Progress in percent: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
    InnoDB: Apply batch completed
    2014-09-08 11:10:42 9339 [Note] InnoDB: 128 rollback segment(s) are active.
    2014-09-08 11:10:42 9339 [Note] InnoDB: Waiting for purge to start
    2014-09-08 11:10:42 7f7883fff700 InnoDB: Assertion failure in thread 140155587393280 in file trx0purge.cc line 699
    InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no
    InnoDB: We intentionally generate a memory trap.
    InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
    InnoDB: If you get repeated assertion failures or crashes, even
    InnoDB: immediately after the mysqld startup, there may be
    InnoDB: corruption in the InnoDB tablespace. Please refer to
    InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
    InnoDB: about forcing recovery.
    15:10:42 UTC - 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=8388608
    read_buffer_size=131072
    max_used_connections=0
    max_threads=151
    thread_count=0
    connection_count=0
    It is possible that mysqld could use up to
    key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68245 K bytes of memory
    Hope that's ok; if not, decrease some variables in the equation.

    Thread pointer: 0x0
    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_bottom = 0 thread_stack 0x40000
    /usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8c8af5]
    /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65ffb4]
    /lib64/libpthread.so.0(+0xf710)[0x7f78bb18c710]
    /lib64/libc.so.6(gsignal+0x35)[0x7f78b9e37635]
    /lib64/libc.so.6(abort+0x175)[0x7f78b9e38e15]
    /usr/sbin/mysqld[0xa25d16]
    /usr/sbin/mysqld[0xa268c4]
    /usr/sbin/mysqld[0xa27206]
    /usr/sbin/mysqld[0xa17f8a]
    /lib64/libpthread.so.0(+0x79d1)[0x7f78bb1849d1]
    /lib64/libc.so.6(clone+0x6d)[0x7f78b9eed86d]
    The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
    information that should help you find out what is causing the crash.
    140908 11:10:42 mysqld_safe mysqld from pid file /var/lib/mysql/fastest.csofts.net.pid ended

    Tell me what should i do now?

  • csofts said: Tell me what should i do now?

    Hire a sys admin

  • noosVPSnoosVPS Member
    edited September 2014

    GIANT_CRAB said: Hire a sys admin

    +1.

    @csofts If you have not been able to read through this log which you pasted here and understand the possible causes, then you need an admin to look after this issue.

  • Use pastebin.

    Thanked by 1Falzo
  • afraid to ask, but... how exactly did you "upgrade" your mysql-version? (regarding to the other thread)

    via apt, yum or whatever system this might be or... copying some binaries from here to there?

    I suppose you didn't compile anything by yourself, don't you?

  • mikhomikho Member, Host Rep

    Run the update again.
    Read the logs from the update.
    Find the error, repair, restart

  • Dude, pastebin?

  • Pastebin or pre tag would be appreciated.

    Try re-install, if not then hire a sysadmin.

  • didn't read through the clusterfuck of error log....Is your MySQL disk/partion full?

  • mikhomikho Member, Host Rep

    InnoDB: Assertion failure in thread 139826609252096 in file trx0purge.cc line 699 InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html

    Could be that one or more Innodb databases are corrupt because of a dirty shutdown.

    Theres an option to force recovery (possible data loss) when starting mysqld.

  • @MikHo said:
    Run the update again.
    Read the logs from the update.
    Find the error, repair, restart

    Now i again using 11.40 WHm version .Mysql is not upgrading.

  • @csofts said:
    Now i again using 11.40 WHm version .Mysql is not upgrading.

    You may want to consider hiring someone to fix this for you if you lack the ability to do so.

  • noosVPS said: The log file is

    What distribution is that on?

  • You have an answer in your message.

    said: please contact the sysadmin

  • @csofts said:
    Now i again using 11.40 WHm version .Mysql is not upgrading.

    Hire someone to fix it for you, LET is not a support desk.

    Also if your cPanel licence is valid you may be better off asking them for help than here.

  • His website says Live Support 24/7 Hours 365 Days

  • Hello,
    I have 4 years + epxerience in development . I have already asked from Cpanel Sysadmin. this said to me you can't upgrade this.here is wrong something else.you need to rebuilt this server. now i have rebuilt new server and move all backup to new server. This website is for Help and Share Problem each other.

    Thanks
    Regards
    Junaid

  • @Jono20201 said:
    You may want to consider hiring someone to fix this for you if you lack the ability to do so.

    Yes i hired on odesk.com but Sysadmin said to me that something is wrong else there.we can't upgrade this. so you need to rebuilt new server. now every thing ok i have rebuilt this and move backup and upgrade everything.

  • xDutchyxDutchy Member
    edited September 2014

    Development != SysAdmin

    I have +/- 1 / 1.5 years of experience with Linux, but wouldnt trust myself running a (shared)production environment, let alone with little to no Linux experience

  • @xDutchy said:
    Development != SysAdmin

    I have +/- 1 / 1.5 years of experience with Linux, but wouldnt trust myself running a (shared)production environment, let alone with little to no Linux experience

    You are right but i know very well about sysadmin. i have resolved this issue myself.

  • @csofts said:
    You are right but i know very well about sysadmin. i have resolved this issue myself.

    You know, cPanel has their own support team, And they most likely would know how to fix it...

  • @csofts said:
    You are right but i know very well about sysadmin.

    Sure you do. So why is it you posted here again?

    @csofts said:
    i have resolved this issue myself.

    In a timely fashion of course.

Sign In or Register to comment.