General error 2006 mysql server has gone away nextcloud

There are several causes for this error.

MySQL/MariaDB related:

• wait_timeout — Time in seconds that the server waits for a connection to become active before closing it.
• interactive_timeout — Time in seconds that the server waits for an interactive connection.
• max_allowed_packet — Maximum size in bytes of a packet or a generated/intermediate string. Set as large as the largest BLOB, in multiples of 1024.

Example of my.cnf:

[mysqld]
# 8 hours
wait_timeout = 28800
# 8 hours
interactive_timeout = 28800
max_allowed_packet = 256M

Server related:

• Your server has full memory — check info about RAM with free -h

Framework related:

• Check settings of your framework. Django for example use CONN_MAX_AGE (see docs)

How to debug it:

• Check values of MySQL/MariaDB variables.
  • with sql: SHOW VARIABLES LIKE '%time%';
  • command line: mysqladmin variables
• Turn on verbosity for errors:
  • MariaDB: log_warnings = 4
  • MySQL: log_error_verbosity = 3
• Check docs for more info about the error

answered Feb 21, 2019 at 9:48

Error: 2006 (CR_SERVER_GONE_ERROR)

Message: MySQL server has gone away

Generally you can retry connecting and then doing the query again to solve this problem — try like 3-4 times before completely giving up.

I’ll assuming you are using PDO. If so then you would catch the PDO Exception, increment a counter and then try again if the counter is under a threshold.

If you have a query that is causing a timeout you can set this variable by executing:

SET @@GLOBAL.wait_timeout=300;
SET @@LOCAL.wait_timeout=300;  -- OR current session only

Where 300 is the number of seconds you think the maximum time the query could take.

Further information on how to deal with Mysql connection issues.

EDIT: Two other settings you may want to also use is net_write_timeout and net_read_timeout.

answered Oct 29, 2011 at 23:22

It was RAM problem for me.

I was having the same problem even on a server with 12 CPU cores and 32 GB RAM. I researched more and tried to free up RAM. Here is the command I used on Ubuntu 14.04 to free up RAM:

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

And, it fixed everything. I have set it under cron to run every hour.

crontab -e

0 * * * * bash /root/ram.sh;

And, you can use this command to check how much free RAM available:

free -h

And, you will get something like this:

             total       used       free     shared    buffers     cached
Mem:           31G        12G        18G        59M       1.9G       973M
-/+ buffers/cache:       9.9G        21G
Swap:         8.0G       368M       7.6G

answered Mar 26, 2017 at 5:38

In my case it was low value of open_files_limit variable, which blocked the access of mysqld to data files.

I checked it with :

mysql> SHOW VARIABLES LIKE 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 1185  |
+------------------+-------+
1 row in set (0.00 sec)

After I changed the variable to big value, our server was alive again :

[mysqld]
open_files_limit = 100000

answered Sep 8, 2016 at 14:31

This generally indicates MySQL server connectivity issues or timeouts.
Can generally be solved by changing wait_timeout and max_allowed_packet in my.cnf or similar.

I would suggest these values:

wait_timeout = 28800

max_allowed_packet = 8M

answered Jun 29, 2018 at 14:35

There is an easier way if you are using XAMPP.
Open the XAMPP control panel, and click on the config button in mysql section.

Now click on the my.ini and it will open in the editor. Update the max_allowed_packet to your required size.

Then restart the mysql service. Click on stop on the Mysql service click start again. Wait for a few minutes.

Then try to run your Mysql query again. Hope it will work.

answered May 5, 2019 at 5:44

It’s always a good idea to check the logs of the Mysql server, for the reason why it went away.

It will tell you.

answered Jun 30, 2018 at 18:06

MAMP 5.3, you will not find my.cnf and adding them does not work as that max_allowed_packet is stored in variables.

One solution can be:

1. Go to http://localhost/phpmyadmin
2. Go to SQL tab
3. Run SHOW VARIABLES and check the values, if it is small then run with big values

4. Run the following query, it set max_allowed_packet to 7gb:

   set global max_allowed_packet=268435456;

For some, you may need to increase the following values as well:

set global wait_timeout = 600;
set innodb_log_file_size =268435456;

answered May 9, 2019 at 20:47

This might be a problem of your .sql file size.

If you are using xampp. Go to the xampp control panel -> Click MySql config -> Open my.ini.

Increase the packet size.

max_allowed_packet = 2M -> 10M

answered Jan 10, 2018 at 11:43

The unlikely scenario is you have a firewall between the client and the server that forces TCP reset into the connection.

I had that issue, and I found our corporate F5 firewall was configured to terminate inactive sessions that are idle for more than 5 mins.

Once again, this is the unlikely scenario.

answered May 23, 2017 at 18:36

I found the solution to «#2006 — MySQL server has gone away» this error.
Solution is just you have to check two files

1. config.inc.php
2. config.sample.inc.php

Path of these files in windows is

C:wamp64appsphpmyadmin4.6.4

In these two files the value of this:

$cfg['Servers'][$i]['host']must be 'localhost' .

In my case it was:

$cfg['Servers'][$i]['host'] = '127.0.0.1';

change it to:

"$cfg['Servers'][$i]['host']" = 'localhost';

Make sure in both:

1. config.inc.php
2. config.sample.inc.php files it must be ‘localhost’.

And last set:

$cfg['Servers'][$i]['AllowNoPassword'] = true;

Then restart Wampserver.

To change phpmyadmin user name and password

You can directly change the user name and password of phpmyadmin through config.inc.php file

These two lines

$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '';

Here you can give new user name and password.
After changes save the file and restart WAMP server.

answered Jun 10, 2017 at 8:18

answered Jun 16, 2017 at 15:58

I also encountered this error. But even with the increased max_allowed_packet or any increase of value in the my.cnf, the error still persists.

What I did is I troubleshoot my database:

• I checked the tables where the error persists
• Then I checked each row
• There are rows that are okay to fetch and there are rows where the error only shows up
• It seems that there are value in these rows that is causing this error
• But even by selecting only the primary column, the error still shows up (SELECT primary_id FROM table)

The solution that I thought of is to reimport the database. Good thing is I have a backup of this database. But I only dropped the problematic table, then import my backup of this table. That solved my problem.

My takeaway of this problem:

• Always have a backup of your database. Either manually or thru CRON job
• I noticed that there are special characters in the affected rows. So when I recovered the table, I immediately changed the collation of this table from latin1_swedish_ci to utf8_general_ci
• My database was working fine before then my system suddenly encountered this problem. Maybe it also has something to do with the upgrade of the MySQL database by our hosting provider. So frequent backup is a must!

answered May 3, 2021 at 1:49

Just in case this helps anyone:

I got this error when I opened and closed connections in a function which would be called from several parts of the application.
We got too many connections so we thought it might be a good idea to reuse the existing connection or throw it away and make a new one like so:

public static function getConnection($database, $host, $user, $password){
    if (!self::$instance) {
        return self::newConnection($database, $host, $user, $password);
    } elseif ($database . $host . $user != self::$connectionDetails) {
        self::$instance->query('KILL CONNECTION_ID()');
        self::$instance = null;
        return self::newConnection($database, $host, $user, $password);
    }
    return self::$instance;
}

Well turns out we’ve been a little too thorough with the killing and so the processes doing important things on the old connection could never finish their business.
So we dropped these lines

self::$instance->query('KILL CONNECTION_ID()');
self::$instance = null;

and as the hardware and setup of the machine allows it we increased the number of allowed connections on the server by adding

max_connections = 500

to our configuration file. This fixed our problem for now and we learned something about killing mysql connections.

answered Jun 26, 2018 at 12:10

This error happens basically for two reasons.

1. You have a too low RAM.
2. The database connection is closed when you try to connect.

You can try this code below.

# Simplification to execute an SQL string of getting a data from the database
def get(self, sql_string, sql_vars=(), debug_sql=0):
    try:            
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()
    except (AttributeError, MySQLdb.OperationalError):
        self.__init__()
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()

It mitigates the error whatever the reason behind it, especially for the second reason.

If it’s caused by low RAM, you either have to raise database connection efficiency from the code, from the database configuration, or simply raise the RAM.

answered Sep 21, 2018 at 10:54

For me it helped to fix one’s innodb table’s corrupted index tree. I localized such a table by this command

mysqlcheck -uroot --databases databaseName 

result

mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE ...

as followed I was able to see only from the mysqld logs /var/log/mysqld.log which table was causing troubles.

FIL_PAGE_PREV links 2021-08-25T14:05:22.182328Z 2 [ERROR] InnoDB: Corruption of an index tree: table `database`.`tableName` index `PRIMARY`, father ptr page no 1592, child page no 1234'

The mysqlcheck command did not fix it, but helped to unveil it.
Ultimately I fixed it as followed by a regular mysql command from a mysql cli

OPTIMIZE table theCorruptedTableNameMentionedAboveInTheMysqld.log

answered Aug 25, 2021 at 16:04

• • #1

  Hey there!

  For a couple of weeks (and I believe since a minor update, but not sure about it) I have the problem, that my Nextcloud sync doesn’t work properly. I have to users on nextcloud. One with just about 10G of data and another with over 500G of data (mainly photos and music). I use the nextcloud windows client to sync all the data from my OMV server to my local desktop. Since the above mentioned update it stops always at the same file and gives out an error message in the sync client: «[file name and path] — server replied: internal server error». If I look closer in the error logs, it writes «SQLSTATE[HY000]: General error: 2006 MySQL server has gone away». I have googled this and found quite a few «solutions» which I tried out. A lot of changes in my.cnf later I still haven’t found the solution to this problem. I should state, that the 10G of data gets synced fine (even while the sync client shows the error for the 500G-account). Has anyone experienced similar things? Please ask me to show any configuration or error log files you need to help me find a solution.

  Thank you!
  Alex

  (During one of my problem solving trials I killed my former SLC-USB-stick where OMV was installed. OMV wouldn’t boot anymore. I have now bought a SSD of similar size and to my surprise, after cloning it with CloneZilla, the SSD booted OMV without problems! Only the above error is still there. Maybe this is important to know. Is my database possibly corrupted because it was on a slowly dying USB-stick? Is there anything I can do to repair it?)

• • #2

  No one has a solution for this problem or an idea, what I could do next?

• • Offizieller Beitrag

  • #3

  OMV wouldn’t boot anymore. I have now bought a SSD of similar size and to my surprise, after cloning it with CloneZilla, the SSD booted OMV without problems! Only the above error is still there. Maybe this is important to know. Is my database possibly corrupted because it was on a slowly dying USB-stick? Is there anything I can do to repair it?

  When you use clonezilla to clone a bad usb stick to a new stick, you copy the corrupt data to the new one. I recommend wipe the new stick and re-installing. There is no good way to find the corruption unless you have a good backup of the old stick.

• • #4

  Thank you ryecoaaron!!

  This was exactly the kind of idea I had needed! I threw away my obviously corrupted databases using the DROP-command from here: https://docs.nextcloud.com/ser…/maintenance/restore.html
  After that I reinstalled the configuration of Nextcloud by deleting [pathtoNextcloud]/config/config.php and opening my Nextcloud-instance.

  I recreated all users and did a file-scan with «sudo -u www-data php occ files:scan [username]» for each user. Doing it for all users with «scan-all» would have worked too, I guess, but I wanted to start with the username, which had the least amount of files…

  And now I have a working database again. I tried so hard finding the right configuration settings in my.cnf and all along it was the corrupt database. Which is weird, since it still synced some files…

  Thanks again!

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.