MySQL: Enable LOAD DATA LOCAL INFILE - mysql

I'm running Mysql 5.5 on Ubuntu 12 LTS. How should I enable LOAD DATA LOCAL INFILE in my.cnf?
I've tried adding local-infile in my config at various places but I'm still getting the "The used command is not allowed with this MySQL version"

From the MySQL 5.5 manual page:
LOCAL works only if your server and your client both have been
configured to permit it. For example, if mysqld was started with
--local-infile=0, LOCAL does not work. See Section 6.1.6, “Security Issues with LOAD DATA LOCAL”.
You should set the option:
local-infile=1
into your [mysql] entry of my.cnf file or call mysql client with the --local-infile option:
mysql --local-infile -uroot -pyourpwd yourdbname
You have to be sure that the same parameter is defined into your [mysqld] section too to enable the "local infile" feature server side.
It's a security restriction.

The my.cnf file you should edit is the /etc/mysql/my.cnf file. Just:
sudo nano /etc/mysql/my.cnf
Then add:
[mysqld]
local-infile
[mysql]
local-infile
The headers [mysqld] and [mysql] are already given, just locate them in the file and add local-infile underneath each of them.
It works for me on MySQL 5.5 on Ubuntu 12.04 LTS.

I solved this problem on MySQL 8.0.11 with the mysql terminal command:
SET GLOBAL local_infile = true;
I mean I logged in first with the usual:
mysql -u user -p*
After that you can see the status with the command:
SHOW GLOBAL VARIABLES LIKE 'local_infile';
It should be ON. I will not be writing about security issued with loading local files into database here.

Replace the driver php5-mysql by the native driver
On debian
apt-get install php5-mysqlnd

in case your flavor of mysql on ubuntu does NOT under any circumstances work and you still get the 1148 error, you can run the load data infile command via command line
open a terminal window
run mysql -u YOURUSERNAME -p --local-infile YOURDBNAME
you will be requested to insert mysqluser password
you will be running MySQLMonitor and your command prompt will be mysql>
run your load data infile command (dont forget to end with a semicolon ; )
like this:
load data local infile '/home/tony/Desktop/2013Mini.csv' into table Reading_Table FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';

See below image...
I've added --local-infile=1 to normal mysql command mysql -u root -p
So total line would be :
mysql --local-infile=1 -u root -p

Also, for other readers, if you are trying to do this in Django AND your server allows local_infile (you can check by typing SHOW VARIABLES via a mysql client) then you can add this to your settings.py file (since python MySQLdb doesn't by default read the .my.cnf file):
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'mydb',
'USER': 'myname',
'PASSWORD': 'mypass',
'HOST': 'myserver',
'PORT': '3306',
'OPTIONS' : {
'local_infile':1,
},
}
}

Add local_infile in both mysql and mysqld section.
[mysql]
local_infile=1
...
[mysqld]
local_infile=1
...
Tested in MySQL 8.x both in Windows and Linux.

I know this is not exactly what the OP is asking, but as this thread is quite old and none of the solutions proposed here worked for me, I decided to share this.
If someone is having trouble enabling local_infile in the version 8 of MySql, this command here did the trick for me:
SET PERSIST local_infile = 1;
It persists the configuration on the "mysqld-auto.cnf" config file and then the change will be remembered after service or server restart.

You have to take care how you establish your mysqli connection. Full credit for this solution goes to Jorge Albarenque, source
In order to fix it I had to:
Add local-infile=1 to the [mysqld] and [mysql] sections of my.cnf (as explained in the comments above)
Use mysqli_real_connect function (PHP documentation).
The catch is that with that function you can explicitly enable the support for LOAD DATA LOCAL INFILE. For example (procedural style):
$link = mysqli_init();
mysqli_options($link, MYSQLI_OPT_LOCAL_INFILE, true);
mysqli_real_connect($link, $host, $username, $password, $database);
or object oriented
$mysqli = mysqli_init();
$mysqli->options(MYSQLI_OPT_LOCAL_INFILE, true);
$mysqli->real_connect($host, $username, $password, $database);

if your csv file located same with db, you need to remove LOCAL in LOAD DATA INFILE,
or you will get the error
The used command is not allowed with this MySQL version

Another way is to use the mysqlimport client program.
You invoke it as follows:
mysqlimport -uTheUsername -pThePassword --local yourDatabaseName tableName.txt
This generates a LOAD DATA statement which loads tableName.txt into the tableName table.
Keep in mind the following:
mysqlimport determines the table name from the file you provide; using all text from the start of the file name up to the first period as the table name. So, if you wish to load several files to the same table you could distinguish them like tableName.1.txt, tableName.2.txt,..., etc, for example.

This went a little weird for me, from one day to the next one the script that have been working since days just stop working. There wasn´t a newer version of mysql or any kind of upgrade but I was getting the same error, so I give a last try to the CSV file and notice that the end of lines were using \n instead of the expected ( per my script ) \r\n so I save it with the right EOL and run the script again without any trouble.
I think is kind of odd for mysql to tell me The used command is not allowed with this MySQL version since the reason was completely different.
My working command looks like this:
LOAD DATA LOCAL INFILE 'file-name' IGNORE INTO TABLE table-name CHARACTER SET latin1 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\"' LINES TERMINATED BY '\r\n' IGNORE 1 LINES.

I used below method, which doesn't require any change in config, tested on mysql-5.5.51-winx64 and 5.5.50-MariaDB:
put 'load data...' in .sql file (ex: LoadTableName.sql)
LOAD DATA INFILE 'D:\\Work\\TableRecords.csv' INTO TABLE tbl1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\r\n' IGNORE 1 LINES (col1,col2);
then:
mysql -uroot -pStr0ngP#ss -Ddatabasename -e "source D:\Work\LoadTableName.sql"

In case if Mysql 5.7 you can use "show global variables like "local_infile" ;" which will give the local infile status ,You can turn it on using "set global local_infile=ON ; ".

I am using xampp v3.2.4 and mysql server 8.0.20.
I added local-infile=1 to [mysql] and [mysqld] in the file "my.ini". The file is located at "C:\xampp\mysql\bin\my.ini".
Then I inserted the data from csv file using the following code LOAD DATA INFILE .... It is important to move LOCAL. Otherwise it won't work.
Thanks for all suggestions above. A combination finally worked out for me.

Ok, something odd is happening here. To make this work, do NOT need to make any configuration changes in /etc/mysql/my.cnf . All you need to do is to restart the current mysql service in terminal:
sudo service mysql restart
Then if I want to "recreate" the bug, I simply restart the apache service:
sudo service apache2 restart
Which can then be fixed again by entering the following command:
sudo service mysql restart
So, it appears that the apache2 is doing something to not allow this feature
when it starts up (which is then reversed/corrected if restart the mysql service).
Valid in Debian based distributions.
service mysqld restart
service httpd restart
Valid in RedHat based distributions

For those of you looking for answers to make LOAD DATA LOCAL INFILE work like me, this might probably work. Well it worked for me, so here it goes. Install percona as your mysql server and client by following the steps from the link. A password will be prompted for during the installation, so provide one that you'll remember and use it later. One the installation is done, reboot your system and test if the server is up and running by going to the terminal and typing mysql -u root -p and then the password. Try running the command LOAD DATA LOCAL INFILE now.. Hope it works :)
BTW I was working on Rails 2.3 with Ruby 1.9.3 on Ubuntu 12.04.

All: Evidently this is working as designed. Please see new ref man dated 2019-7-23, Section 6.1.6, Security Issues with LOAD DATA LOCAL.

Please note that for newer MySQL servers, like version 8.0, this setting is not a boolean value, but ON|OFF as you can read here in the docs: https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_local_infile
If you set it to 1 MySQL will not recognize it and will warn this error on your logfiles:
# /var/log/mysql/mysql.err
2022-04-08T14:45:06.532132Z 0 [Warning] [MY-000076] [Server] option 'local_infile': boolean value '1;' was not recognized. Set to OFF.

Related

Error Code: 2068 while loading csv file into MySql

I am using Amazon RDS MySql for data storage. I am able to load data by specifying the column values, however, when I try to load the data from my local machine to MySql, it fails with
Error: 2068.
LOAD DATA LOCAL INFILE '/Users/priya/Documents/Atlas/data/The_Atlas_0820.csv' INTO TABLE schedule
FIELDS TERMINATED by ','
ENCLOSED by '"'
LINES TERMINATED by '\n' IGNORE 1 LINES (Carrier1, FlightNo1, DupCar1,DupCar2, DupCar3,
DupCar4,DupCar5, DupCar6,DupCar7, DupCar8,DepAirport, ArrAirport);
Error Code: 2068. LOAD DATA LOCAL INFILE file request rejected due to restrictions on access.
I also checked SHOW GLOBAL VARIABLES LIKE 'local_infile'; and it is set to "ON".
If i use Terminal to open a connection with MySql and execute the command there, it works ok.
$ ./mysql -h <hostname> -P 3306 --local_infile=1 -u <username> -p
But how to make it work in MySql Workbench.
It seems that there is a bug in MySQL Workbench for LOAD DATA LOCAL INFILE, check if the workaround in this link works for you:
MySQL Workbench 8.0 restricts usage of LOAD DATA LOCAL INFILE
or there is another solution that seems to work here:
Workbench 8.0.12 no longer allows LOAD DATA LOCAL INFILE
Adding what worked for me here, I was able to find a working solution through the links #Zacca provided, but I had to dig through solutions that didn't work, and I thought I'd repost here in case those links die at some point.
First, if I ran SHOW GLOBAL VARIABLES LIKE 'local_infile'; I can see that INFILE is enabled. However, I was still getting "ERROR CODE 2068"
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| local_infile | ON |
+---------------+-------+
I was able to resolve this by editing the connection string in MySQL workbench by navigating to Home, then:
Edit Connection > Advanced > Copy OPT_LOCAL_INFILE=1 into Others box on a new line
Then restart the connection. After that, LOAD LOCAL INFILE runs without error.
Also, as a side note, before I found this solution, I found I could run the LOAD LOCAL INFILE command from R without issue, which helped me isolate the client as the issue, as opposed to a security/permissions related problem.
The solution that worked for me is from the workarounds shared in the link:
Workbench 8.0.12 no longer allows LOAD DATA LOCAL INFILE as shared by #Zacca.
Steps for Mac:
Create a my.cnf file with the following statements at the path: /etc.
I created my.cnf file using root user.
[client]
port = 3306
[mysqld]
port = 3306
secure_file_priv=''
local-infile = 1
Set the my.cnf file as the default configuration file in MySql Workbench.
Click the Wrench icon next to Instance.
Under configuration file, enter the path to my.cnf file: /etc/my.cnf.
Restart the MySQL server workbench.
Try the following statements in MySQL Workbench:
SHOW VARIABLES LIKE "local_infile"; //Should be ON
SHOW VARIABLES LIKE "secure_file_priv"; //Should have no values (not NULL but blank)
Load the data.
LOAD DATA LOCAL INFILE '<path>/file.csv' INTO TABLE <tablename>
FIELDS TERMINATED by ','
ENCLOSED by '"'
LINES TERMINATED by '\n' IGNORE 1 LINES;
Using LOCAL keyword, loading is successful.
However, without LOCAL keyword, I get access error.
Error Code: 1045. Access denied for user 'admin'#'%' (using password: YES)
After beating my head around this for an hour, I switched back to MySQL Workbench 6.3.
Bliss.

MySQLdump backup script no longer works, getting "mysqldump: unknown variable 'local-infile=0'"

I've recently upgrade a server to Debian 9 and MySQL to the latest version. I have a simple backup script that I run before performing any work on a production site but this time, when running my script, I encounter the following:
mysqldump: unknown variable 'local-infile=0'
Here is my script. What's going on?
#!/bin/bash
# [skipping commentary]
SITE=prod
# Set the directory that the Drupal root is IN, no trailing slashes
DROOT=[website_root]
# Set the directory for storing backups, no trailing slashes
BUD=/$DROOT/notes/backups
# Don't edit; End of defining variables
echo Doing a full back up...
echo Prepare to enter MySQL password...
# tar -czf $BUD/$SITE-files-$(date +'%Y%m%d%H%M%S').tgz $DROOT/docroot
mysqldump -u mysql_user -p drupal > $BUD/$SITE-drupal-$(date +'%Y%m%d%H%M%S').sql
mysqldump -u mysql_user -p civicrm > $BUD/$SITE-civicrm-$(date +'%Y%m%d%H%M%S').sql
ls -lh $BUD
pwd
echo Finished with backups...
MySQL version 10.1.37-MariaDB-0+deb9u1 Debian 9.6
Edit: When I ssh and run mysqldump with correct permissions I get the same issue. Weirdest thing, cron that runs similar process is backing up my databases as ordered.
The best way to solve this is simply to rename the variable to:
loose-local-infile=1
This will allow mysqldump to merely throw a warning, rather than a fatal error.
The suggestion to comment out the variable is not an option if you want LOAD DATA INFILE functionality out of the box, and MySQL 8+ for security reasons requires you to set this variable for both server (mysqld) and client. It is the [client] variable grouping in your config that chokes mysqldump if you don't add the "loose-" prefix to local-infile.
Seems like the new version you install is compiled without support of local-infile parameter. And because package management system (usually) keep your current configuration file you can try to find this parameter in my.ini file and comment it.
This parameter manage LOAD DATA LOCAL functionality. But seems like this have some potential security issues (more here)

How to change the default port of mysql from 3306 to 3360

I want to change the default port number of MySQL server presently it is 3306. I want to change it to 3360.
I have tried:
-- port=3360
But things are not working for me. Please provide query to change port not any configuration. I am using Windows 8 64 bit.
You need to edit your my.cnf file and make sure you have the port set as in the following line:
port = 3360
Then restart your MySQL service and you should be good to go. There is no query you can run to make this change because the port is not a dynamic variable (q.v. here for MySQL documentation showing a table of all system variables).
If you're on Windows, you may find the config file my.ini it in this directory
C:\ProgramData\MySQL\MySQL Server 5.7\
You open this file in a text editor and look for this section:
# The TCP/IP Port the MySQL Server will listen on
port=3306
Then you change the number of the port, save the file.
Find the service MYSQL57 under Task Manager > Services and restart it.
On newer (for example 8.0.0) the simplest solution is (good choice for a scripted start-up for example):
mysqld --port=23306
When server first starts the my.ini may not be created where everyone has stated. I was able to find mine in C:\Documents and Settings\All Users\Application Data\MySQL\MySQL Server 5.6
This location has the defaults for every setting.
# CLIENT SECTION
# ----------------------------------------------------------------------
#
# The following options will be read by MySQL client applications.
# Note that only client applications shipped by MySQL are guaranteed
# to read this section. If you want your own MySQL client program to
# honor these values, you need to specify it as an option during the
# MySQL client library initialization.
#
[client]
# pipe
# socket=0.0
port=4306 !!!!!!!!!!!!!!!!!!!Change this!!!!!!!!!!!!!!!!!
[mysql]
no-beep
default-character-set=utf8
Go to installed mysql path and find bin folder,open my.ini and search 3306 after that change 3306 to 3360
Actually, you can just run the service using /mysqld --PORT 1234, it would force mysql to run on the specified port without change the cnf/ini file.
I just cought a case that cnf didn't work. It was weired... so I just use the cmd line as the shortcut and it works!
try changing the connection port to 8012
open xampp as administrator
Mysql config => my.ini change the port from 3306 to 8012
close and run it again
I hope it will work.
If you are using windows and installed the database as a service, which is the default, you should find your configuration file by opening your services management console.
For instance: win + r and then type services.msc
Look for a service called MySQL or MariaDB.
On the general tab of the properties of this service you can find a path to your mysqld.exe file and the arguments to start the exe. The --defaults-file argument should point to your configuration file.
Edit your configuration file and restart the MySQL service.
In Windows 8.1 x64 bit os, Currently I am using MySQL version :
Server version: 5.7.11-log MySQL Community Server (GPL)
For changing your MySQL port number, Go to installation directory, my installation directory is :
C:\Program Files\MySQL\MySQL Server 5.7
open the my-default.ini Configuration Setting file in any text editor.
search the line in the configuration file.
# port = .....
replace it with :
port=<my_new_port_number>
like my self changed to :
port=15800
To apply the changes don't forget to immediate either restart the MySQL Server or your OS.
Hope this would help many one.
Change my.cnf file and add this line or change it port=3360
at my fedora 34
sudo vi /etc/my.cnf
add This line ==> port=3360
The best way to do this is take backup of required database and reconfigure the server.
Creating A Backup
The mysqldump command is used to create textfile “dumps” of databases managed by MySQL. These dumps are just files with all the SQL commands needed to recreate the database from scratch. The process is quick and easy.
If you want to back up a single database, you merely create the dump and send the output into a file, like so:
mysqldump database_name > database_name.sql
Multiple databases can be backed up at the same time:
mysqldump --databases database_one database_two > two_databases.sql
In the code above, database_one is the name of the first database to be backed up, and database_two is the name of the second.
It is also simple to back up all of the databases on a server:
mysqldump --all-databases > all_databases.sql
After taking the backup, remove mysql and reinstall it. After reinstalling with the desired port number.
Restoring a Backup
Since the dump files are just SQL commands, you can restore the database backup by telling mysql to run the commands in it and put the data into the proper database.
mysql database_name < database_name.sql
In the code above, database_name is the name of the database you want to restore, and database_name.sql is the name of the backup file to be restored..
If you are trying to restore a single database from dump of all the databases, you have to let mysql know like this:
mysql --one-database database_name < all_databases.sql

How can I correct MySQL Load Error

I'm not quite sure a similar question to this was closed by I'm trying to execute the following MySQL program.
mysql -e "load data local infile \
'/tmp/ept_inventory_wasp_export_04292013.csv' into \
table wasp_ept_inv fields terminated by ',' \
lines terminated by '\n' ;"
at the bash command line and get this error
ERROR 1148 (42000) at line 1: The used command is not allowed with this MySQL version
How can I work around this problem?
I am actually running this command from a Python program, but pulled the command out to try fiddling with it at the bash command line.
I've seen how I can modify my.cnf (local-infile), but I do not want that global a change if I can avoid it.
Here's the MySQL version.
mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu (i686) using readline 6.2
The workaround for this is to modify the command line mysql -e to pass in the --local-infile=1 argument like this:
mysql --local-infile=1 -u username -p `
Then run the LOAD DATA LOCAL INFILE command again.
As documented under Security Issues with LOAD DATA LOCAL:
To deal with these problems, we changed how LOAD DATA LOCAL is handled as of MySQL 3.23.49 and MySQL 4.0.2 (4.0.13 on Windows):
By default, all MySQL clients and libraries in binary distributions are compiled with the --enable-local-infile option, to be compatible with MySQL 3.23.48 and before.
If you build MySQL from source but do not invoke configure with the --enable-local-infile option, LOAD DATA LOCAL cannot be used by any client unless it is written explicitly to invoke mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0). See Section 20.6.6.49, “mysql_options()”.
You can disable all LOAD DATA LOCAL statements from the server side by starting mysqld with the --local-infile=0 option.
For the mysql command-line client, enable LOAD DATA LOCAL by specifying the --local-infile[=1] option, or disable it with the --local-infile=0 option. For mysqlimport, local data file loading is off by default; enable it with the --local or -L option. In any case, successful use of a local load operation requires that the server permits it.
If you use LOAD DATA LOCAL in Perl scripts or other programs that read the [client] group from option files, you can add the local-infile=1 option to that group. However, to keep this from causing problems for programs that do not understand local-infile, specify it using the loose- prefix:
[client]
loose-local-infile=1
If LOAD DATA LOCAL is disabled, either in the server or the client, a client that attempts to issue such a statement receives the following error message:
ERROR 1148: The used command is not allowed with this MySQL version
local-infile needs to enabled on both the server and the client. You can accomplish this by adding local-infile = 1 to the appropriate section in each end's my.cnf (Unix) or my.ini (Windows) file. For example, on the client:
[client]
local-infile = 1
You can also enable this at runtime on the server by setting the system variable local_infile:
SET GLOBAL local_infile=1;
However, you still need to enable it on the client. You can do this at runtime by adding a command-line parameter to the mysql command:
mysql --local-infile=1 ...
If you're using Amazon Web Services RDS, you can configure the server setting by editing or creating a Parameter Group. Look for the local_infile parameter. You may need to restart your server after applying the changes.
My guess is that your MySQL server does not have LOAD DATA LOCAL enabled. See this section of MySQL documentation:
If LOAD DATA LOCAL is disabled, either in the server or the client, a client that attempts to issue such a statement receives the following error message:
ERROR 1148: The used command is not allowed with this MySQL version
Here is link to the page I got this from:
http://dev.mysql.com/doc/refman/5.5/en/load-data-local.html

ERROR 2006 (HY000): MySQL server has gone away

I get this error when I try to source a large SQL file (a big INSERT query).
mysql> source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 2
Current database: *** NONE ***
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 3
Current database: *** NONE ***
Nothing in the table is updated. I've tried deleting and undeleting the table/database, as well as restarting MySQL. None of these things resolve the problem.
Here is my max-packet size:
+--------------------+---------+
| Variable_name | Value |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+
Here is the file size:
$ ls -s file.sql
79512 file.sql
When I try the other method...
$ ./mysql -u root -p my_db < file.sql
Enter password:
ERROR 2006 (HY000) at line 1: MySQL server has gone away
max_allowed_packet=64M
Adding this line into my.cnf file solves my problem.
This is useful when the columns have large values, which cause the issues, you can find the explanation here.
On Windows this file is located at: "C:\ProgramData\MySQL\MySQL Server
5.6"
On Linux (Ubuntu): /etc/mysql
You can increase Max Allowed Packet
SET GLOBAL max_allowed_packet=1073741824;
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet
The global update and the my.cnf settings didn't work for me for some reason. Passing the max_allowed_packet value directly to the client worked here:
mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql
In general the error:
Error: 2006 (CR_SERVER_GONE_ERROR) - MySQL server has gone away
means that the client couldn't send a question to the server.
mysql import
In your specific case while importing the database file via mysql, this most likely mean that some of the queries in the SQL file are too large to import and they couldn't be executed on the server, therefore client fails on the first occurred error.
So you've the following possibilities:
Add force option (-f) for mysql to proceed and execute rest of the queries.
This is useful if the database has some large queries related to cache which aren't relevant anyway.
Increase max_allowed_packet and wait_timeout in your server config (e.g. ~/.my.cnf).
Dump the database using --skip-extended-insert option to break down the large queries. Then import it again.
Try applying --max-allowed-packet option for mysql.
Common reasons
In general this error could mean several things, such as:
a query to the server is incorrect or too large,
Solution: Increase max_allowed_packet variable.
Make sure the variable is under [mysqld] section, not [mysql].
Don't afraid to use large numbers for testing (like 1G).
Don't forget to restart the MySQL/MariaDB server.
Double check the value was set properly by:
mysql -sve "SELECT ##max_allowed_packet" # or:
mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"
You got a timeout from the TCP/IP connection on the client side.
Solution: Increase wait_timeout variable.
You tried to run a query after the connection to the server has been closed.
Solution: A logic error in the application should be corrected.
Host name lookups failed (e.g. DNS server issue), or server has been started with --skip-networking option.
Another possibility is that your firewall blocks the MySQL port (e.g. 3306 by default).
The running thread has been killed, so retry again.
You have encountered a bug where the server died while executing the query.
A client running on a different host does not have the necessary privileges to connect.
And many more, so learn more at: B.5.2.9 MySQL server has gone away.
Debugging
Here are few expert-level debug ideas:
Check the logs, e.g.
sudo tail -f $(mysql -Nse "SELECT ##GLOBAL.log_error")
Test your connection via mysql, telnet or ping functions (e.g. mysql_ping in PHP).
Use tcpdump to sniff the MySQL communication (won't work for socket connection), e.g.:
sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings
On Linux, use strace. On BSD/Mac use dtrace/dtruss, e.g.
sudo dtruss -a -fn mysqld 2>&1
See: Getting started with DTracing MySQL
Learn more how to debug MySQL server or client at: 26.5 Debugging and Porting MySQL.
For reference, check the source code in sql-common/client.c file responsible for throwing the CR_SERVER_GONE_ERROR error for the client command.
MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
arg, arg_length))
{
set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
goto end;
}
I solved the error ERROR 2006 (HY000) at line 97: MySQL server has gone away and successfully migrated a >5GB sql file by performing these two steps in order:
Created /etc/my.cnf as others have recommended, with the following contents:
[mysql]
connect_timeout = 43200
max_allowed_packet = 2048M
net_buffer_length = 512M
debug-info = TRUE
Appending the flags --force --wait --reconnect to the command (i.e. mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).
Important Note: It was necessary to perform both steps, because if I didn't bother making the changes to /etc/my.cnf file as well as appending those flags, some of the tables were missing after the import.
System used: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 for osx10.8 (i386)
Just in case, to check variables you can use
$> mysqladmin variables -u user -p
This will display the current variables, in this case max_allowed_packet, and as someone said in another answer you can set it temporarily with
mysql> SET GLOBAL max_allowed_packet=1072731894
In my case the cnf file was not taken into account and I don't know why, so the SET GLOBAL code really helped.
You can also log into the database as root (or SUPER privilege) and do
set global max_allowed_packet=64*1024*1024;
doesn't require a MySQL restart as well. Note that you should fix your my.cnf file as outlined in other solutions:
[mysqld]
max_allowed_packet=64M
And confirm the change after you've restarted MySQL:
show variables like 'max_allowed_packet';
You can use the command-line as well, but that may require updating the start/stop scripts which may not survive system updates and patches.
As requested, I'm adding my own answer here. Glad to see it works!
The solution is increasing the values given the wait_timeout and the connect_timeout parameters in your options file, under the [mysqld] tag.
I had to recover a 400MB mysql backup and this worked for me (the values I've used below are a bit exaggerated, but you get the point):
[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000
Blockquote
I had the same problem but changeing max_allowed_packet in the my.ini/my.cnf file under [mysqld] made the trick.
add a line
max_allowed_packet=500M
now restart the MySQL service once you are done.
A couple things could be happening here;
Your INSERT is running long, and client is disconnecting. When it reconnects it's not selecting a database, hence the error. One option here is to run your batch file from the command line, and select the database in the arguments, like so;
$ mysql db_name < source.sql
Another is to run your command via php or some other language. After each long - running statement, you can close and re-open the connection, ensuring that you're connected at the start of each query.
If you are on Mac and installed mysql through brew like me, the following worked.
cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf
Source: For homebrew mysql installs, where's my.cnf?
add max_allowed_packet=1073741824 to /usr/local/etc/my.cnf
mysql.server restart
I had the same problem in XAMMP
Metode-01: I changed max_allowed_packet in the D:\xampp\mysql\bin\my.ini file like that below:
max_allowed_packet=500M
Finally restart the MySQL service once and done.
Metode-02:
the 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.
I encountered this error when I use Mysql Cluster, I do not know this question is from a cluster usage or not. As the error is exactly the same, so give my solution here.
Getting this error because the data nodes suddenly crash. But when the nodes crash, you can still get the correct result using cmd:
ndb_mgm -e 'ALL REPORT MEMORYUSAGE'
And the mysqld also works correctly.So at first, I can not understand what is wrong. And about 5 mins later, ndb_mgm result shows no data node working. Then I realize the problem. So, try to restart all the data nodes, then the mysql server is back and everything is OK.
But one thing is weird to me, after I lost mysql server for some queries, when I use cmd like show tables, I can still get the return info like 33 rows in set (5.57 sec), but no table info is displayed.
This error message also occurs when you created the SCHEMA with a different COLLATION than the one which is used in the dump. So, if the dump contains
CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
you should also reflect this in the SCHEMA collation:
CREATE SCHEMA myschema COLLATE utf8_unicode_ci;
I had been using utf8mb4_general_ci in the schema, cause my script came from a fresh V8 installation, now loading a DB on old 5.7 crashed and drove me nearly crazy.
So, maybe this helps you saving some frustating hours... :-)
(MacOS 10.3, mysql 5.7)
Add max_allowed_packet=64M to [mysqld]
[mysqld]
max_allowed_packet=64M
Restart the MySQL server.
If it's reconnecting and getting connection ID 2, the server has almost definitely just crashed.
Contact the server admin and get them to diagnose the problem. No non-malicious SQL should crash the server, and the output of mysqldump certainly should not.
It is probably the case that the server admin has made some big operational error such as assigning buffer sizes of greater than the architecture's address-space limits, or more than virtual memory capacity. The MySQL error-log will probably have some relevant information; they will be monitoring this if they are competent anyway.
This is more of a rare issue but I have seen this if someone has copied the entire /var/lib/mysql directory as a way of migrating their DB to another server. The reason it doesn't work is because the database was running and using log files. It doesn't work sometimes if there are logs in /var/log/mysql. The solution is to copy the /var/log/mysql files as well.
For amazon RDS (it's my case), you can change the max_allowed_packet parameter value to any numeric value in bytes that makes sense for the biggest data in any insert you may have (e.g.: if you have some 50mb blob values in your insert, set the max_allowed_packet to 64M = 67108864), in a new or existing parameter-group. Then apply that parameter-group to your MySQL instance (may require rebooting the instance).
For Drupal 8 users looking for solution for DB import failure:
At end of sql dump file there can commands inserting data to "webprofiler" table.
That's I guess some debug log file and is not really important for site to work so all this can be removed. I deleted all those inserts including LOCK TABLES and UNLOCK TABLES (and everything between). It's at very bottom of the sql file. Issue is described here:
https://www.drupal.org/project/devel/issues/2723437
But there is no solution for it beside truncating that table.
BTW I tried all solutions from answers above and nothing else helped.
I've tried all of above solutions, all failed.
I ended up with using -h 127.0.0.1 instead of using default var/run/mysqld/mysqld.sock.
If you have tried all these solutions, esp. increasing max_allowed_packet up to the maximum supported amount of 1GB and you are still seeing these errors, it might be that your server literally does not have enough free RAM memory available...
The solution = upgrade your server to more RAM memory, and try again.
Note: I'm surprised this simple solution has not been mentioned after 8+ years of discussion on this thread... sometimes we developers tend to overthink things.
Eliminating the errors which triggered Warnings was the final solution for me. I also changed the max_allowed_packet which helped with smaller files with errors. Eliminating the errors also sped up the process incredibly.
if none of this answers solves you the problem, I solved it by removing the tables and creating them again automatically in this way:
when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT
then just use this backup with your db and it will remove and recreate the tables you need.
Then you backup just data, and do the same, and it will work.
How about using the mysql client like this:
mysql -h <hostname> -u username -p <databasename> < file.sql