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.
Related
I can see that variables inside /etc/mycnf file are different from the variables that i see through 'show variables' command, how is this possible? how can i fix this?
For example the output given by the following command: show variables like '%data%'; gives different variables output with respect to the ndf file.
Be sure to have it in the correct, corresponding section of the my.cnf configuration file once you are convinced you have it inside the correct my.cnf file, or the one with the highest priority.
My example case was I had it previously under various sections [mariadb], [mysqld], [mysql], [client-server] , whereas my setting log_slow_queries needed to be under the section name [server] which was not even there, I just figured it out by trial and error.
To be pretty sure the given file is the correct one to use, try to add a setting log_slow_queries under the [mysql] field and it will complain as it's the server setting and the [mysql] section is for the client configurations, but if it will complain with an error you know that .cnf file is used and when it's tested via a CLI client, the server error are usually suppressed and quite often not available even in the logs .
Or you can find out exactly which files are read by mysql/mariadb server by issuing this command
mysqladmin --help | grep -A1 'Default options'
or
strace mysql ";" 2>&1 | grep cnf
or
mysqld --help --verbose | grep my.cnf
command journalctl -xe for investigating a few recent related errors with mysql service
I am running on Ubuntu and I've modified /etc/mysql/my.cnf with the following:
pastie of my.cnf and i've chown it to mysql:mysql and chmoded it to 777. No matter what I try when I run a few queries nothing gets logged. What am I doing wrong? I have also tried commenting out general_log_file and general_log and use log = and its its the same thing.
update: i did restart mysql after changes.
update: here is the mysql variables: http://pastie.org/5517087
I suggest you to check the following:
1) Make sure that you restarted the service and that no errors appear during the restart, either on the command prompt, or in the mysql error log file
2) In your my.cnf you are using:
general_log_file = /var/www/logs/mysql-query.log
make sure that the user mysqld (or whatever your mysql service is running as), has the proper permissions to write this folder. The /var/www/ folder is usually intended for apache usage, not mysql usage, so I would suggest /var/log/ or /var/log/mysqld
3) Make sure that the my.cnf you are editing, is the one your mysqld is really running. In many cases when you are using some other software (like cpanel, plesk, etc), the default folders are not used and the configs being used are somewhere else. You can search around your system for other my.cnf using:
locate my.cnf
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.
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'.