cannot find mysql slow query log file on mac - mysql

I am trying to enable slow_query_log on mysql, but I could not find it on my mac.
I read in MySQL 5.7 Documentation that"
By default, the server writes files for all enabled logs in the data directory.
When I write show variables like '%slow_query%'; in mysql shell, I see the following:
but I can't see McBook-Pro-6-slow.log in the data directory. Here is all I can see in the data directory:
Could someone let me know why I can't see the slow log file?
In order to enable the slow_query_log, I've read here that I should add slow-query-log=1 to my.cnf. Here, my problem is that I am not sure where is mysql config file on my Mac. I've found a my-default.cnf in usr/local/mysql/support-files/ and another my.cnf file in /etc. Which one should I modify??
Thanks,

Refer to this Stackoverflow question MySQL 'my.cnf' location? which pertains to Mac OS. As you can see the permutations of locations are numerous usually compounded by different distros and MAMP XAMP WAMP bundles and Home Brew. It is not uncommon to have 2 mysql daemons on a box and not even know it.
Which is why in comments I suggested looking at the output of select ##basedir for the location of the my.ini (Windows) or my.cnf (Linux/Mac). That is not to suggest a configuration file is going to be there, but that is where it should be if one were to exist. Without it, baked-in default values are used. Often there is a stub, a suggested file, named differently (like my-default), awaiting your tweaks and a rename or copy to the appropriate file name of my.ini or my.cnf.
There is also a system variable named slow_query_log_file and its value visible if set thru SELECT ##slow_query_log_file;. For me right now it has a value of GUYSMILEY-slow.log because I did not set it in my ini (Windows) and it defaults to computername+"-slow.log".
That is the filename without the path. Where the file actually is written to is in the datadir seen with the output of select ##datadir;.
On my system this means (via ##basedir)
C:\Program Files\MySQL\MySQL Server 5.6\my.ini
would have a setting that ends up in a slowlog file written to in this absolute path (helped by ##datadir):
C:\ProgramData\MySQL\MySQL Server 5.6\data\GUYSMILEY-slow.log
and a fragment inside that log file might show something like this:
Ini and cnf changes require a MySQL daemon restart. In that configuration file a section similar to (my 5.6)
[mysqld]
basedir=C:\\Program Files\\MySQL\\MySQL Server 5.6\\
datadir=C:\\ProgramData\\MySQL\\MySQL Server 5.6\\Data\\
port=3306
log_warnings = 2
and (my 5.7)
[mysqld]
basedir=C:\\Program Files\\MySQL\\MySQL Server 5.7\\
datadir=C:\\ProgramData\\MySQL\\MySQL Server 5.7\\Data\\
port=3307
log_error_verbosity=2
the above is used within the [mysqld] section to play with settings. What I suggest is playing with this section with an innocuous setting like log_error_verbosity (5.7.2 and up) or similar, save it. Restart the deamon and determine if the variable (as Rick James would call settings because most really aren't dynamically settable). So a sanity check of select ##log_error_verbosity (5.7.2 and up) can confirm it the change is picked up. If it is, bingo, you are doing it right.
The Manual Page Server System Variables depicts the variables (settings) and whether or not they can be dynamically set/changed after the config file load via commands. Dynamic changes are reverted upon daemon restart.
How one would dynamically change a variable might look like:
SET GLOBAL log_error_verbosity=2;
Again, only certain variables are available in certain MySQL versions, such as the above, not available in older versions.
Also note multiple versions of MySQL running concurrently on a server. On mine i have 5.6.31 and 5.7.14. To access a different one via command line tools, use something like the -P 3307 switch to point at the one running on port 3307. Note the uppercase P as opposed to lowercase (which would mean prompt for password).
Determine if multiple instances are running. I use port checks such as
sudo netstat -tulpn (Linux)
netstat -aon | more (Windows, the top part, State=LISTENING)
Unfortunately these types of changes and trial and error take time and are very frustrating. Sorry I do not have a quick and easy answer for all cases.
Addendum
Notes here related to comments. In the below, w-x-y-z is a redacted IP Address.
On a Linux box (amazon ec2 redhat btw):
select ##slow_query_log;
-- 0 (so it is turned off)
SELECT ##slow_query_log_file;
-- /var/lib/mysql/ip-w-x-y-z-slow.log
select ##version;
-- 5.7.14
set global slow_query_log=1;
Error Code: 1227. Access denied; you need (at least one of) the SUPER privilege(s) for this operation 0.094 sec
(ok I was in MySQL Workbench as a dummied down user, off to do it as root via MySQL cmd line ...
mysql> set global slow_query_log=1;
Query OK, 0 rows affected (0.01 sec)
mysql> select ##slow_query_log;
+------------------+
| ##slow_query_log |
+------------------+
| 1 |
+------------------+
1 row in set (0.00 sec)
btw Workbench user can confirm the above `1`
at shell as linux user:
[ec2-user#ip-w-x-y-z ~]$ cd /var/lib/mysql
[ec2-user#ip-w-x-y-z mysql]$ sudo ls -la
(there were many files, only one needed to show you below)
-rw-r-----. 1 mysql mysql 179 Sep 19 01:47 ip-w-x-y-z-slow.log
[ec2-user#ip-w-x-y-z mysql]$ sudo vi ip-w-x-y-z-slow.log
(Header stub, the entire contents, no slow queries yet, log seen below):
/usr/sbin/mysqld, Version: 5.7.14 (MySQL Community Server (GPL)). started with:
Tcp port: 3306 Unix socket: /var/lib/mysql/mysql.sock
Time Id Command Argument

SHOW VARIABLES LIKE 'log_output'; to verify that it is set to FILE or FILE,TABLE.

Related

setting LOCAL_INFILE in config file MySQL 8

I'm going through the MySQL documentation tutorial. It's really great so far, but I've run into a problem. The step where the tut explains how to load initial table data from a file doesn't work.
Below are the steps I have taken which include a deep dive into documentation and trying many answers to similar questions (linked), all to no avail.
I googled the error and found in the docs that loading local data is
a security risk so it has to be enabled. I tried this answer
and this answer, which was to use the following when logging
into MySQL:
# neither of these worked:
mysql -u [username] -p --local-infile
mysql -u [username] -p --local-infile=1
mysql --local-infile -u [username] -p
Maybe when I log in with this option, I'm just setting it on the client side and not the server? I really don't know the difference.
Next, I dug into the documentation a little more and read about the
"local_infile" variable. There is even a section in the documents
titled Enabling or Disabling Local Data Loading Capability,
where it talks about a system variable called local_infile but
doesn't say a damned thing about how to enable or disable it.
So I next read the documentation about server system variables
and how to look at what I've got going on using:
mysqld --verbose --help
Which printed out a massive amount of text, but I found a line that said:
Default options are read from the following files in the given order:
C:\Windows\my.ini C:\Windows\my.cnf C:\my.ini C:\my.cnf C:\Program Files\MySQL\MySQL Server 8.0\my.ini C:\Program Files\MySQL\MySQL Server 8.0\my.cnf
I figured I could find my local_infile variable in one of those .ini or .cnf files and change it to 1 or True or whatever... However, exactly none of those files exist in any of those locations.
Using this answer, or more specifically the comments on the
answer, I found this file: mysql.conf.sample which has a few
variables listed in it but not local_infile, nor the host of
others that were listed in the print out from mysqld --verbose
--help. To this file I added the lines
[mysqld]
local_infile=1
No luck there.
SET GLOBAL local_infile='ON' and then SHOW GLOBAL VARIABLES LIKElocal_infile` results in:
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| local_infile | ON |
+---------------+-------+
It was OFF before. But guess what, I still can't load two rows into a database from a text file. Shocker.
I found a blog post that said that config files could be located in the directory %PROGRAMDATA%/MySQL/MySQL Server 8.0 as a my.ini. Sure enough, that's where it was. I added local-infile=1 under [mysql] and [mysqld]. It still didn't work, so I tried local-infile and local-infile=ON (I have seen all of these used in various accepted answers). None of them worked.
So, as is the norm, documentation absolutely sucks, and I'm lost. But at least I've done my due diligence of searching the docs, so the pedantics of SO are satisfied and I can ask my question:
How do I enable loading local data by default?
This is on windows.
I had same problem. Cannot find a way to turn that local_infile option on. Solution is to use batch files to start mysqld. I use standalone apache/mysql system which starts from where ever directory you extract the zip.
Keys are:
To have non blocking batch to start mysqld.
First set environment varibles how ever you want but especially note that in that batch you better add mysql bin directory to %path% environment variable.
call ".\..\..\set_roots.bat"
Then start mysqld as parallel process. Again use "call" command:
call start "MYSQL" mysqld --defaults-file=%my_ini% --port=%mysql_port% --standalone --console --log-timestamps=SYSTEM --explicit_defaults_for_timestamp --verbose
Use timer to wait so that mysqld is ready to take queries
timeout /t 5
Now that mysqld has started we can execute mysql commands at the end of original batch.
Example:
mysql -u root -p%rootpw% -e "SET GLOBAL local_infile = 'ON';"
Note: Leave no space between -p and actual password and it does not ask input

How to turn on/off MySQL strict mode in localhost (xampp)?

I want to know how to check whether MySQL strict mode is on or off in localhost(xampp).
If on then for what modes and how to off.
If off then how to on.
I already followed http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-full and https://mariadb.com/kb/en/mariadb/sql_mode/ and other related sites too. But I didn't get an exact answer for my question.
->STRICT_TRANS_TABLES is responsible for setting MySQL strict mode.
->To check whether strict mode is enabled or not run the below sql:
SHOW VARIABLES LIKE 'sql_mode';
If one of the value is STRICT_TRANS_TABLES, then strict mode is enabled, else not.
In my case it gave
+--------------+------------------------------------------+
|Variable_name |Value |
+--------------+------------------------------------------+
|sql_mode |STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION|
+--------------+------------------------------------------+
Hence strict mode is enabled in my case as one of the value is STRICT_TRANS_TABLES.
->To disable strict mode run the below sql:
set global sql_mode='';
[or any mode except STRICT_TRANS_TABLES. Ex: set global sql_mode='NO_ENGINE_SUBSTITUTION';]
->To again enable strict mode run the below sql:
set global sql_mode='STRICT_TRANS_TABLES';
To Change it permanently in ubuntu do the following
in the ubuntu command line
sudo nano /etc/mysql/my.cnf
Then add the following
[mysqld]
sql_mode=
First, check whether the strict mode is enabled or not in mysql using:
SHOW VARIABLES LIKE 'sql_mode';
If you want to disable it:
SET sql_mode = '';
or any other mode can be set except the following.
To enable strict mode:
SET sql_mode = 'STRICT_TRANS_TABLES';
You can check the result from the first mysql query.
Check the value with
SELECT ##GLOBAL.sql_mode;
then clear the ##global.sql_mode by using this command:
SET ##GLOBAL.sql_mode=''
To change it permanently in Windows (10), edit the my.ini file. To find the my.ini file, look at the path in the Windows server. E.g. for my MySQL 5.7 instance, the service is MYSQL57, and in this service's properties the Path to executable is:
"C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqld.exe" --defaults-file="C:\ProgramData\MySQL\MySQL Server 5.7\my.ini" MySQL57
I.e. edit the my.ini file in C:\ProgramData\MySQL\MySQL Server 5.7\. Note that C:\ProgramData\ is a hidden folder in Windows (10). My file has the following lines of interest:
# Set the SQL mode to strict
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
Remove STRICT_TRANS_TABLES, from this sql-mode line, save the file and restart the MYSQL57 service. Verify the result by executing SHOW VARIABLES LIKE 'sql_mode'; in a (new) MySQL Command Line Client window.
(I found the other answers and documents on the web useful, but none of them seem to tell you where to find the my.ini file in Windows.)
In my case, I need to add:
sql_mode="STRICT_TRANS_TABLES"
under [mysqld] in the file my.ini located in C:\xampp\mysql\bin.
You can check the local and global value of it with:
SELECT ##SQL_MODE, ##GLOBAL.SQL_MODE;
I want to know how to check whether MySQL strict mode is on or off in
localhost(xampp).
SHOW VARIABLES LIKE 'sql_mode';
If result has "STRICT_TRANS_TABLES", then it's ON. Otherwise, it's OFF.
If on then for what modes and how to off.
If off then how to on.
For Windows,
Go to C:\Program Files\MariaDB XX.X\data
Open the my.ini file.
*On the line with "sql_mode", modify the value to turn strict mode ON/OFF.
Save the file
**Restart the MySQL service
Run SHOW VARIABLES LIKE 'sql_mode' again to see if it worked;
*3.a. To turn it ON, add STRICT_TRANS_TABLES on that line like this: sql_mode=STRICT_TRANS_TABLES. *If there are other values already, add a comma after this then join with the rest of the value.
*3.b. To turn it OFF, simply remove STRICT_TRANS_TABLES from value. *Remove the additional comma too if there is one.
**6. To restart the MySQL service on your computer,
Open the Run command window (press WINDOWS + R button).
Type services.msc
Click OK
Right click on the Name MySQL
Click Restart
on Debian 10
I start mysql from ./opt/lampp/xampp start
I do strace ./opt/lampp/sbin/mysqld and see that my.cnf is there:
stat("/opt/lampp/etc/my.cnf", {st_mode=S_IFREG|0644, st_size=5050, ...}) = 0
openat(AT_FDCWD, "/opt/lampp/etc/my.cnf", O_RDONLY|O_CLOEXEC) = 3
hence, I add sql_mode config to /opt/lampp/etc/my.cnf instead of /etc/mysql/my.cnf
on server console:
$ mysql -u root -p -e "SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';"
Today I was trying to set the sql_mode=TRADITIONAL permanently but all efforts were in vain not because there are wrong answers but due to the way xampp configured the mysqld startup script. Let me explain in detail.
Of course you all try our best before coming to SO, so do I. I followed the comments in A:\xampp\mysql\bin\my.ini (given below):
# You can copy this file to
# A:/xampp/mysql/bin/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is A:/xampp/mysql/data) or
# ~/.my.cnf to set user-specific options.
So I tried A:/xampp/mysql/bin/my.cnf, A:/xampp/mysql/data/my.cnf but it wasn't even reading those files. Hours wasted in creating .cnf files in above locations. Worst part was it wasn't even working if I edit those my.ini files (i.e A:/xampp/mysql/bin/my.ini and A:/xampp/mysql/data/my.ini)
Then I checked all the folders to know how that control panel works and found thta xampp uses the mysql_start.bat script to start the msql deamon. Here is the bat file contents:
#echo off
cd /D %~dp0
echo Diese Eingabeforderung nicht waehrend des Running beenden
echo Please dont close Window while MySQL is running
echo MySQL is trying to start
echo Please wait ...
echo MySQL is starting with mysql\bin\my.ini (console)
mysql\bin\mysqld --defaults-file=mysql\bin\my.ini --standalone
if errorlevel 1 goto error
goto finish
:error
echo.
echo MySQL konnte nicht gestartet werden
echo MySQL could not be started
pause
:finish
Here we can clearly see that it is explicitly using the argument --defaults-file to tell MySQL daemon from where to read the files. Now I hope you have plenty of ideas to fix this.
Note: I've already added A:/xampp/mysql/bin to my PATH.
Now we have several options as I've mentioned below:
Add the exact path to the --defaults-file (i.e. --defaults-file=mysql\bin\my.cnf)
You can just ommit the flag and let mysqld read from default locations (can see those using mysql --help) Now you've 2 options:
either edit those default my.ini files or
follow the comments to create my.cnf files according to your installation
directory.
I just deleted that --defaults-file flag and let it run with MySQL's default configuration instead of xampp's. By the was I also have to change A:\xampp\mysql\data\my.ini from this:
[mysqld]
datadir=C:/xampp/mysql/data
[client]
to
[mysqld]
datadir=A:\xampp\mysql\data
[client]
to update the data directory. After that I just created a my.conf file in A:\xampp\mysql\data (data dir). with sql_mode option in it. It also worked with my.cnf in the A:\xampp\mysql\bin.
I have attached some screenshots for better understanding:
Updated data dir in A:\xampp\mysql\data\my.ini:
(option 1) Add my.cnf in A:\xampp\mysql\data:
(option 2) Add my.cnf in A:\xampp\mysql\bin:
You may found another solution too. Hope you are able to fix whatever issue you have regarding those config files.
For ubuntu :
Once you are connected to your VPS via SSH, please try connecting to your mysql with "root"
user: mysql -u root -p
Enter "root" user password and you will be in the mysql environment (mysql>), then simply check what is sql_mode, with the following command:
SHOW VARIABLES LIKE 'sql_mode';
Basically, you will see the table as your result, if the table has a value of STRICT_TRANS_TABLES, it means that this option is enabled, so you need to remove the value from this table with the following command:
set global sql_mode='';
This will set your table's value to empty and disable this setting. Like this:
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sql_mode | |
+---------------+-------+
Please make sure to perform these commands within the MySQL environment and not simply via SSH. I think this moment was missed in the article provided below and the author assumes that the reader understands it intuitively.

What is the correct location of mysql.sock file on linux

I have a mysql.sock file located at:
/tmp/mysql.sock
But the my.cnf is pointing to this location:
socket=/var/lib/mysql/mysql.sock
Is this correct?
The socket declaration should be located under [mysqld] in your my.cnf. If you have declared it there and still pointing to another place such as tmp, then your my.cnf file that you have been editing is not being read when mysql starts or there is another my.cnf overriding the one you have been editing. The case may also be that there is a second Socket declaration in the same my.cnf file that is overriding the one you expect to be read at start by mysql.
You can check its absolute path by logging into mysql and running:
mysql> show variables like 'socket';
+-----------------------------------------+-------------------------------+
| Variable_name | Value |
+-----------------------------------------+-------------------------------+
| socket | /yourpath/mysql.sock |
+-----------------------------------------+-------------------------------+
1 rows in set (0.00 sec)
There is no right or wrong place on linux for saving sockets, except on external devices which are unmounted at any time or folders which are emptied from time to time. You need to configure where you want to place it.
For the MySQL console client there is something more to consider: The client seems to use the socket configuration value provided in [client] instead of [mysqld]. If you have a multiple MySQL server setup like i have (4.1, 5.5, 5.7), you probably want to use a "--defaults-extra-file" option with the socket written in the [client] part for each different server. The socket needs to be the same as the one defined in the my.cnf [mysqld] part used on the server.
Here is an example defaults-extra-file.cnf, remember to change the user, password and socket to your needs - and keep it on access rights 400 (there is a password stored after all):
[client]
user = guardian
password = I-4m.Gr00t!
host = localhost
socket = /var/run/mysqld/mysqld-5.6.sock
This only applies though if you are using "localhost" as the value for "host". If you have multiple local addresses (127.0.0.2, 127.0.0.3), you need to leave the config variable for "host" on "localhost" to use the configured socket. Otherwise the client will connect to the server using TCP.
This was tested on my Debian 9.5 Server with MySQL 4.1.22, 5.5.49 and 5.7.19 and their respective clients.

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

Mysql: modification in my.cnf doesn't take effect

I've updated the my.cnf file of my database with the following line: max_connections=200. I stopped and started the mysql service after that so that the changes would take effect.
But for some reason this change doesn't affect the database because if I run:
mysql> select ##max_connections
it shows that the max number of connections is 100.
Obviously there is some place else that manages this value. Where can I find it or what did I do wrong?
Thank you for your reply.
Make sure the max_connections in under the [mysqld] section:
Ex:
[mysqld]
socket=/path/to/mysql.sock
datadir=/var/lib/mysql
max_connections=200
[client]
#mysql-client settings here..
Try running mysqld --verbose --help to see which configuration file is actually read by mysqld and which parameters and values are used.
The output will look like this:
mysqld Ver 5.0.51a-24-log for debian-linux-gnu on x86_64 ((Debian))
Copyright (C) 2000 MySQL AB, by Monty and others
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license
Default options are read from the following files in the given order:
/etc/mysql/my.cnf ~/.my.cnf /usr/etc/my.cnf
The following groups are read: mysql_cluster mysqld server mysqld-5.0
Variables (--variable-name=value)
and boolean options {FALSE|TRUE} Value (after reading options)
--------------------------------- -----------------------------
...
To see what values a running MySQL server is using, type
'mysqladmin variables' instead of 'mysqld --verbose --help'.
Changes to mysqld are not necessarily reflected in the mysql client! I changed a global variable assignment in my.cnf, restarted the service, and queried it in the mysql client. It returned the old value. When queried from a script, however, the value was in fact changed!
It may have to do with 'how' the mysql server is being shutdown and restarted. On my system if I use the mysqld daemon service to shutdown mysql (e.g. service mysqld stop), I get a shutdown notice, but a ps shows mysql is still running. Using a similar 'service mysqld restart', some of the changes to the my.cnf file get accepted, but many don't.
The other method of shutting down mysql is to use mysqladmin -u user -pPass shutdown. I noticed when I used this method, mysql was shutdown completely (no left overs in ps), and when I restarted the mysql server, all the changes to the my.cnf file were accepted.
If mysql starts as a Window service, check the 'Path to executable' setting on the windows service. (Services -> MYSQL56 -> Properties).
If the --defaults-file option is passed in, it could point to a completely different .ini file in a location that is NOT showing with 'mysqld --verbose --help'.
If you remove the --defaults-file option from the service startup parameters, it will go through the list of ini files as listed with mysqld --verbose --help.
Putting my.cnf in /etc/my.cnf and restarting mysql has resolved the issue for me. I'm using mac os. Mysql version is 5.6.41