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
UPDATE FIXED 1/18/15
After we recently updated to MySQL 5.6.27 (from the Ubuntu repo), this option now works. So this appears to have been a problem with the previous version of MySQL.
ORIGINAL QUESTION
With a new upgrade to MySQL (5.6.20), updates and inserts fail unless I set sql-mode to NO_ENGINE_SUBSTITUTION.
Thanks to the documentation, I can run the following from mysql terminal and that fixes the problem (temporarily):
SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';
SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION';`
But the next time MySQL restarts, these settings are lost.
So I have tried to make that permanent by editing /etc/mysql/my.cnf (on my standard server running Ubuntu 12.04.5 LTS), and adding the config settings that the documentation says should be added:
[mysqld]
sql-mode="NO_ENGINE_SUBSTITUTION"
Alternative Syntaxes for Testing
Just for testing purposes, I have also tried the following formats (which do not cause errors when restarting MySQL, but they do not affect the setting).
# dash no quotes
sql-mode=NO_ENGINE_SUBSTITUTION
# underscore no quotes
sql_mode=NO_ENGINE_SUBSTITUTION
# underscore and quotes
sql_mode="NO_ENGINE_SUBSTITUTION"
Nothing works. After restart this setting is lost and I have to run the commands manually again from mysql terminal to make saving work again.
Alternative Locations
I know /etc/mysql/my.cnf is being referenced because we have replication defined in this file, and that is working.
There is not another identical setting in this file that is overwriting it.
I get a list of the config files that are being referenced by running this from the command line:
mysqld --help --verbose
I see a line that reads:
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
This is the default location it "looks" for files, it doesn't mean that it actually found a file there, e.g. my server doesn't have /etc/my.cnf, /usr/etc/my.cnf or ~/.my.cnf.
So it looks like my config in /etc/mysql/my.cnf is the only file mysql is referencing, and therefore this setting is not being overwritten.
Logical Conclusion of Testing
Logically then, it seems the syntax is not correct or is being ignored for some other reason. Any other ideas?
Just to add my configuration to the mix, I'm using MySQL 5.7.8 which has the same strict sql_mode rules by default.
I finally figured the following working in my /etc/mysql/my.conf:
[mysqld]
sql-mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
i.e. dash, not underscore and quotes around the value.
I have NO other my.conf files other than /etc/mysql/my.conf
There are some extra config includes being loaded from /etc/mysql/conf.d/ but they are blank.
And that seems to work for me.
Your server may read a different my.cnf than the one you're editing (unless you specified it when starting mysqld).
From the MySQL Certification Study Guide:
The search order includes two general option files, /etc/my.cnf and
$MYSQL_HOME/my.cnf. The second file is used only if the MYSQL_HOME
environment variable is set. Typically, you seet it to the MySQL
installation directory. (The mysqld_safe script attempts to set
MYSQL_HOME if it is not set before starting the server.) The
option file search order also includes ~/.my.cnf (that is the home
directory). This isn't an especially suitable location for server
options. (Normally, you invoke the server as mysql, or as root
with a --user=mysql option. The user-specific file read by the
server would depend on which login account you invoke it from,
possibly leading to inconsistent sets of options being used.)
Another possibility is of course, that your sql-mode option gets overwritten further down in the same file. Multiple options have to be separated by , in the same line.
P.S.: And you need the quotes, IIRC. Now that you've tried it without quotes, I'm pretty sure, you're editing the wrong file, since MySQL doesn't start when there's an error in the option file.
P.P.S.: Had a look at my config files again, there it's
[mysqld]
sql_mode = "NO_ENGINE_SUBSTITUTION"
and it's working.
It should be:
[mysqld]
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
instead of
[mysqld]
sql_mode="NO_ENGINE_SUBSTITUTION"
then restart mysqld service.
Woks fine for me on ubuntu 16.04.
path: /etc/mysql/mysql.cnf
and paste that
[mysqld]
#
# * Basic Settings
#
sql_mode = "NO_ENGINE_SUBSTITUTION"
For me it was a permission problem.
enter:
mysqld --verbose --help | grep -A 1 "Default options"
[Warning] World-writable config file '/etc/mysql/my.cnf' is ignored.
So try to execute the following, and then restart the server
chmod 644 '/etc/mysql/my.cnf'
It will give mysql access to read and write to the file.
On Linux Mint 18 the default config file that has the sql-mode option set is located here :
/usr/my.cnf
And relevant line is:
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
So You can set there.
If not sure what config file has such option You can search for it:
$ sudo find / -iname "*my.cnf*"
And get a list:
/var/lib/dpkg/alternatives/my.cnf
/usr/my.cnf
/etc/alternatives/my.cnf
/etc/mysql/my.cnf.fallback
/etc/mysql/my.cnf
My problem was that I had spaces in between the options on 5.7.20. Removing them so the line looked like
[mysqld]
sql-mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
The solution is pretty easy... Searched for it for a while and it turns out that you just have to edit 2 config-files:
/usr/my.cnf
/etc/mysql/my.cnf
in both files you'll have to add:
[mysqld]
...
sql_mode=NO_ENGINE_SUBSTITUTION
At least, that's what's working for 5.6.24-2+deb.sury.org~precise+2
For me both keys for sql-mode worked. Whether I used
# dash no quotes
sql-mode=NO_ENGINE_SUBSTITUTION
or
# underscore no quotes
sql_mode=NO_ENGINE_SUBSTITUTION
in the my.ini file made no difference and both were accepted, as far as I could test it.
What actually made a difference was a missing newline at the end of the my.ini file.
So everyone having problems with this or similar problems with my.ini/my.cnf: Make sure there is a blank line at the end of the file!
Tested using MySQL 5.7.27.
If you're using mariadb, you have to modify the mariadb.cnf file located in /etc/mysql/conf.d/.
I supposed the stuff is the same for any other my-sql based solutions.
I am running WHM 10.2.15-MariaDB. To permanently disable strict mode first find out which configuration file our installation prefers. For that, we need the binary’s location:
$ which mysqld
/usr/sbin/mysqld
Then, we use this path to execute the lookup:
$ /usr/sbin/mysqld --verbose --help | grep -A 1 "Default options"
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
We can see that the first favored configuration file is one in the root of the etc folder but that there is a second .cnf file hidden - ~/.my.cnf. Adding the following to the ~/.my.cnf file permanently disabled strict mode for me (needs to be within the mysqld section):
[mysqld]
sql_mode=NO_ENGINE_SUBSTITUTION
I found that adding the line to /etc/my.cnf had no effect at all apart from sending me crazy.
It was making me crazy also until I realized that the paragraph where the key must be is [mysqld] not [mysql]
So, for 10.3.22-MariaDB-1ubuntu1, my solution is, in /etc/mysql/conf.d/mysql.cnf
[mysqld]
sql_mode = "ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
[Fixed]
Server version: 10.1.38-MariaDB - mariadb.org binary distribution
Go to: C:\xampp\mysql\bin
open my.ini in notepad and find [mysqld] (line number 27) then after this line(line no 28) just type: skip-grant-tables
save the file and then reload the phpmyadmin page.It worked for me.
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
I have accessed a clients server (plesk) via ssh to view/edit the my.cnf and php.ini files
if i view them using vi the file seem to be virtualy empty of entries ? see screenshot.
Not sure whether this is an access issue or the files are the right files any help would be appreciated
Thanks
As Rup already mentioned in his comment, the my.cnf file contains only these few lines. It is completely fine, mysql server is able to start also without any config file - in that case it uses the defaults plus whatever is on the commandline.
To see what config files mysqld reads and what defaults it uses, just run:
mysqld --verbose --help
and it will produce report containing for example this:
mysqld Ver 5.0.51a-24-log for debian-linux-gnu on x86_64 ((Debian))
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)
--------------------------------- -----------------------------
help TRUE
...
wait_timeout 3600
To see what values a running MySQL server is using, type
'mysqladmin variables' instead of 'mysqld --verbose --help'.
I'm trying to determine which my.cnf mysql is using. Is there a command or something for mysql or mysqladmin that shows which one is being loaded?
On my linux servers in the startup script (/etc/init.d/mysql) it defines
CONF=/etc/mysql/my.cnf
that it uses to start MySQL daemon
EDIT:
also running
mysqld --verbose --help
shows the following info:
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
So if run as a daemon through init script it will look into /etc/mysql/my.cnf and if started from the command line it will look there only on the second attempt.
the command
SHOW VARIABLES
Will give you a list of variables the current instance of mysql uses.
In the version of mysql I am currently running there is no trace of a my.cnf variable though, so thats not much help
You can always set one of the variables to a different value in each of your my.cnf's, restart the server and use the above command to figure out which configuration it loaded.