This dreaded MySQL error and subsequent Warning is due, except in rare cases, to a lack of resources available to MySQL required for the operation of your Drupal installation. Allowing the necessary resources to MySQL resolves this issue most of the time. See http://drupal.org/node/259580 and http://dev.mysql.com/doc/refman/5.0/en/gone-away.html about the causes and solutions for this error message.

Comments

vishnuvp’s picture

vishnuvp commented

Raising the MySQL memory limit is effective the solution to this problem. The reason why it's not working in many cases was that MySQL was not reading the values from my.ini file due to some permission issues.

To solve the issue, increase the max_allowed_packet value in my.ini file and ensure that the file is being read by the server.

MySQL searches for the my.ini file in the Windows folder and then in the MySQL folder and its bin folder. If it does not find one, the pre-compiled values are used for all variables. I'm unsure about the location of my.ini file in Linux systems.

Alternatively, the value can be raised through MySQL command line using the command

SET GLOBAL  max_allowed_packet = new_value;

But this is valid only for a particular session and it reverts back to the old settings once the session ends.

The reason behind the issue is that Drupal caches the menu_router table and is rebuilt with a single query during a module page visit or clearing of the cache. The menu_router table contains all paths used in the site and the number of rows of the table increases upon addition of a new path. This happens while installing a new module or creating a new view. As the size of the portal increase the menu_router table will grow enormously and caching it through a single INSERT query will be so heavy. In my case, the INSERT query was slightly more than 2MB. If the max_allowed_packet is not enough to handle such a request, the MySQL server will go away giving error 2006.

To avoid such issues, make sure that unused modules are UNINSTALLED (not only removed from the sites/all/modules folder) through the modules page and deleted from the sites/all/modules folder, and unused views are deleted from the system.

Another option would be to use a separate cache mechanism like Memcached or MongoDB. This is an excellent choice but comes with an overhead of using related servers.