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

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

Related

MacOS Can't start MySQL Server

I have MacOS Sierra. I have installed MySQL Server which has been working, however, after a reboot of the Mac Book, I cannot start the MySQL Server.
I have tried changing the port from 3306 to 3307 in the my.cnf file.
Question
I would appreciate any help on how to start the MySQL Server, and also have it so it starts automatically on MacOS Boot up.
(I am new to Mac, so apologies if this is a basic question).
UPDATE
Looking for error logs, I can't find anything with todays (2/2/2017) timestamp.
Nothing in the data dir:
No files with "mysql" have been modified since I've tried to start the MySQL Server (2/2/2017 after 09:00).
I suggest using Terminal commands.
Start MySQL
sudo /usr/local/mysql/support-files/mysql.server start
Stop MySQL
sudo /usr/local/mysql/support-files/mysql.server stop
Restart MySQL
sudo /usr/local/mysql/support-files/mysql.server restart
In my case, I had inadvertently transferred ownership of entire /usr/local directory to myself, which resulted in snatching-away of write permission of /usr/local/mysql-5.7.20-macos10.12-x86_64/data directory from the daemon user called "_mysql".
Restoring the ownership fixed the issue.
After a discussion with Richard, the following solves the issue:
my.cnf:
[client]
port = 3306
socket = /tmp/mysql.sock
[mysqld]
port = 3306
socket = /tmp/mysql.sock
datadir = /usr/local/mysql-5.7.17-macos10.12-x86_64/data
tmpdir = /tmp
Essentially, although we'd added the relevant stanza's to the my.cnf file, we'd still missed the section heading. Adding the [mysqld] section allowed mysql to start.
After installing Mysql 8.0.12 on MacOS High Sierra, Mysql server would not start up. I tried several suggestions like removing mysql and reinstalling it, rebooting the computer and changing file permissions, all to no avail. I finally got it to work by removing /etc/my.cnf.
In my case, ownership of the msyql directory had somehow changed to admin:admin. I use ares suggestion to run mysqld from the terminal:
sudo /usr/local/mysql/support-files/mysql.server start
Which showed a permissions error writing to a msyql file.
I fixed with this command:
sudo chown -R _mysql:wheel /usr/local/mysql/data
from this post:
What user should own /usr/local/mysql on Mac?
In my case, First time, after installing Mysql, Mac needs a restart.
So restarting Mac, after installation, fixed the issue for me.
MacOS doesn't come with a my.cnf file. Default settings will suffice the needs for basic usage. Once we need to override them, it makes sense to have a custom configurations.
This solution works for me.
You have to open the activity monitor up and search for mysqld service. Once selected, just click the delete button located in the up left part and you will see the memory goes down. After that, you can verify your mysql server status from System Preferences and the service is up.
With this solution you don't have to restart your machine and get to work fast.
My problem was that due to an incorrect restart of my machine, a database was corrupted. According to their docs doing a forced InnoDB Recovery did the trick:
/etc/my.cnf
innodb_force_recovery = 2
My problem was that I installed MySQL a while ago with Homebrew (forgot I did) and then went the more manual route, so I think the two installs were fighting each other. I wiped my Mac of both with the help of this walkthrough: https://gist.github.com/vitorbritto/0555879fe4414d18569d
Note: Where it says to use subl - that's Sublime, use whatever editor you like.
I was able to get things to work with a fresh install after that.
I had this same issue on Monterey. Make sure you're selecting the correct download according to your processor architecture.
I ran into same problem with following .err log.
MacOS: Catalina 10.15.7.
MySQL version: 5.7.19.
2021-08-19T02:17:26.6NZ mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
2021-08-19T02:17:27.303813Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2021-08-19T02:17:27.318280Z 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled
2021-08-19T02:17:27.335112Z 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.7.19) starting as process 2828 ...
2021-08-19T02:17:27.421394Z 0 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
2021-08-19T02:17:27.428986Z 0 [ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!
2021-08-19T02:17:27.429541Z 0 [ERROR] Aborting
2021-08-19T02:17:27.429688Z 0 [Note] Binlog end
2021-08-19T02:17:27.432786Z 0 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete
And I found adding --user=root to Ares's answer will start mysql server successfully.
sudo /usr/local/mysql/support-files/mysql.server start --user=root
Ref.: MySQL Server Command User Options

cannot find mysql slow query log file on mac

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.

Binary log error in mysql

When I am trying to check binary log:
SHOW BINARY LOGS;
I get this error:
ERROR 1381 (HY000): You are not using binary logging.
How to resolve this? Can anybody help?
Set the log-bin variable in your MySQL configuration file, then restart MySQL.
An example my.cnf (on Linux/unix) or my.ini (on Windows) would look like:
[client]
...
[mysqld]
...
log-bin=mysql-bin
---
Once restarted, MySQL automatically creates a new binary log (does so upon every restart).
You may also wish to look at the following variables:
server-id = 1
expire_logs_days = 4
sync_binlog = 1
Read details on the MySQL documentation. If you're after replication setup (a primary reason for using binary logs), check out Replication configuration checklist.
Line
log-bin=mysql-bin
must placed above lines:
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
You will need to activate binary logging at startup
Add the following lines in /etc/my.cnf under the [mysqld] section
[mysqld]
log-bin=mysql-bin
expire-logs-days=7
Then, run this
service mysql restart
The next time you login to mysql, you will see a binary log listing and will rotate out after 7 days.
The default location of the binary logs will be /var/lib/mysql or where datadir is defined. If you specify a folder before the binlog name, then that folder is the location.
For example
[mysqld]
log-bin=/var/log/mysql-bin
expire-logs-days=7
UPDATE 2012-07-12 02:20 AM EDT
Please restart mysql as follows and tell us if binary logging in on
service mysql restart --log-bin=mysql-bin
To enable the binary log, start the server with the --log-bin[=base_name] option.
If no base_name value is given, the default name is the value of the pid-file option (which by default is the name of host machine) followed by -bin.
If the basename is given, the server writes the file in the data directory unless the basename is given with a leading absolute path name to specify a different directory. It is recommended that you specify a basename.
Or you can directly use:
log-bin=mysql-bin
and then restart your mysql service. Then binary file will be generated. If you are using lampp on Linux machine then you will find this file in /lampp/var/mysql/mysql-bin.000001
FWIW, I had the same issue after I tried to set up my.cnf.master and my.cnf.slave files and symlink them to my.cnf for master and slave, respectively. The idea was to be able to switch the machine from master to slave and back easily.
It turned out that mysqld simply did not handle the symlink as expected. Hard-linking the file worked (ln my.cnf.master my.cnf). Careful if you do something like this, as overwriting one of the hard-linked filenames could break the link and create two separate files instead (depending on the method of rewriting employed by the software you use for it).
I've found logging will silently fail to happen even if my.cnf config is right, so you can also try re-creating your log folder.
This may be necwssary if the logs are in an odd state. (In my case, I had simply ceased logging in my.cnf and then re-enabled it, but nothing happened, probably because the existing files were not the latest updates?).
Something like this should work:
sudo service mysql stop
sudo mv /var/log/mysql /tmp/mysqlold # or rm -fr if you're brave
mkdir /var/log/mysql
chown -R mysql:mysql /var/log/mysql
sudo service mysql start
Obligatory warning: Obviously, take care when deleting anything on a database server. This will destroy/disrupt/corrupt any replication using this database as master (though you can resume replication as a slave). That said, I believe this should be safe insofar as it doesn't delete the database itself.
I went out of my mind with this issue on a MySQL 5.5 master running Debian. None of the above worked. Finally, I rebooted the server and logging was enabled.
Remove section [mysqld_safe] and replace with [mysqld].
It works for me.

Why is the my.cnf file on the server incomplete or has very few entries?

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'.

Locating current mysql my.cnf

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.