The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

MySQL failure after 5.6.16 upgrade

Discussion in 'Database Discussions' started by Timmy J, Apr 4, 2014.

  1. Timmy J

    Timmy J Registered

    Joined:
    Apr 4, 2014
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    I performed an unattended upgrade to MySQL 5.6.16 and now MySQL fails to start.

    The mysql service is listed as “down” in the Service Status page inside WHM and I’m receiving regular emails from the service monitor indicating that mysql has failed and that a restart is being attempted automagically.

    Creating new accounts is problematic and presents mysql related errors and CPHulk isn’t working without mysql either.
    To make matters worse I can’t connect via ssh and receive a “connection refused” message when attempting. Port 22 is open in the firewall which is managed by the csf v6.47 plugin and my ip address whitelisted, my IP is also allowed in the host access control list and is set up as a recognized ip for root. :confused:

    I have tried a few simple things to resolve as follows:

    - Restart MySQL Service
    When restarting the MySQL service from inside WHM it hangs on the Restarting Service modal screen for a couple of mins before displaying the following:
    Waiting for mysql to restart......finished.
    mysql has failed, please contact the sysadmin (result was "mysql is not running").

    - Rebooting the server. Service still fails to start

    - Performed the unattended MySQL upgrade again. No errors are reported however I haven’t trawled through the 5800 lines of results produced during this process and wouldn’t know what to look for.

    The server is a newly provisioned VPS with two accounts setup but no sites currently hosted and no databases inside either of the accounts. I uploaded some test files to one of the accounts and they’re accessible through the browser and ftp without any problems. The Cpanels for both accounts are also functioning correctly except for the MySQL functions.

    WHM version is 11.42.0 (build 23) running on Cloudlinux 6.5 x86_64 xenpv

    Thanks in advance for any help or adive
     
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,723
    Likes Received:
    660
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello :)

    You will first need to ensure that SSH access is possible. You may have to contact your data center to have them check why it's not accessible. You could have accidentally disabled SSH access or configured it on an alternate port.

    Once SSH is accessible, review the MySQL error log (/var/lib/mysql/$hostname.err) to see what is output when you attempt to start MySQL.

    Thank you.
     
  3. Timmy J

    Timmy J Registered

    Joined:
    Apr 4, 2014
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    Cheers for the response Michael. I've gained console access via a vnc app. Here's the last few lines of the error log output:

    Code:
    2014-04-05 14:01:09 176282 [ERROR] /usr/sbin/mysqld: unknown variable 'table_cache=1024'
    2014-04-05 14:01:09 176282 [ERROR] Aborting
    2014-04-05 14:06:10 178001 [ERROR] /usr/sbin/mysqld: unknown variable 'table_cache=1024'
    2014-04-05 14:06:10 178001 [ERROR] Aborting
    2014-04-05 14:11:11 178684 [ERROR] /usr/sbin/mysqld: unknown variable 'table_cache=1024'
    2014-04-05 14:11:11 178684 [ERROR] Aborting
    2014-04-05 14:16:12 179399 [ERROR] /usr/sbin/mysqld: unknown variable 'table_cache=1024'
    2014-04-05 14:16:12 179399 [ERROR] Aborting
    2014-04-05 14:21:13 180104 [ERROR] /usr/sbin/mysqld: unknown variable 'table_cache=1024'
    2014-04-05 14:21:13 180104 [ERROR] Aborting
    2014-04-05 14:26:14 180793 [ERROR] /usr/sbin/mysqld: unknown variable 'table_cache=1024'
    2014-04-05 14:26:14 180793 [ERROR] Aborting
    2014-04-05 14:31:15 181504 [ERROR] /usr/sbin/mysqld: unknown variable 'table_cache=1024'
    2014-04-05 14:31:15 181504 [ERROR] Aborting
    
     
  4. Timmy J

    Timmy J Registered

    Joined:
    Apr 4, 2014
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    Looks like table_cache isn't supported in 5.6 but table_cache=1024 is specified in /etc/my.cnf
    Why would it have been left in there after running the upgrade through whm? and what do I replace it with?
    Could this mean there are other incorrect or less than optimal values in the config for 5.6?
     
  5. Timmy J

    Timmy J Registered

    Joined:
    Apr 4, 2014
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    Update

    Swapped 'table_cache' with 'table_open_cache' in the config and it seems to have solved the problem.

    Does my.cnf not get altered as part of the upgrade process?

    SSH connection is also solved. The data centre configured it to use an obscure port but didn't think it was necessary to let me know.

    Also came across another issue in that there was an incorrect mysql password configured for modsec in /etc/cron.hourly/modsecparse.pl
    Easy to fix but what could have caused it? Has my data centre used a poorly configured image to set up the VPS?
     
  6. cPanelPeter

    cPanelPeter Technical Analyst III
    Staff Member

    Joined:
    Sep 23, 2013
    Messages:
    569
    Likes Received:
    15
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Twitter:
    Hello,

    No, it does not get altered as it can be configured accordingly by each admin/user. Whenever an update to MySQL happens, you should check the /var/lib/mysql/hostname.err file for issues and if necessary, backup your /etc/my.cnf file and start with a clean one that has no modifications to it. If MySQL starts, then slowly add each section back and see if/when/where it fails.
     
Loading...

Share This Page