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
Related
I've a Galera Cluster Installation with three nodes. As requirement my MariaDB installation must be in different path that default, and user cannot be mysql. So I've moved all mysql data path and I've created a new user and group to manage the mysql service.
MariaDB service is working fine, but I've noticed that a mysql-slow.log has been created with permissions to mysql:root for a third program installation that monitor queries. Opening mysql.err I've found the following error:
[ERROR] Could not use mysql-slow.log for logging (error 13).Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
So I've made chown myuser:mygroup mysql-slow.log and restart the service, but there still having same permissions. Then I've set in my.cnf the slow_query_log=1, in order to try that the myuser create the file at start, but the wrong permission still there also after remove the files and restart.
All the files, in my mariadb data path, are not managed by mysql:mysql user, in my installation are managed by myuser:mygroup so when the mysql-slow.log is created the permissions mysql:root are assigned so I have not permission to write there with myuser:mygroup and if I assign them manually there is not effect because are override with mysql:root after mysql restart.
Somebody knows if there are any way to set by default the user and group owners of the mysql-slow.log file when created?
Thanks.
Regards,
Sergio
Fix the permissions:
chmod 666 mysql-slow.log
See what your script is doing; perhaps it needs fixing, too.
I have a LAMP stack setup. Occasionally, I get the following error message when I open some page from the browser:
Error creating the connection!: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
I think the server was configured correctly. The problem happens about every two months. Every time when I reboot the Linux server, or restart mysql, the problem was gone. I want to fix this problem permanently. Can anyone give me some idea?
Much appreciated.
EDIT
The problem occurs again and I checked the mysqld.sock file, it was not there. Do you have any idea how to fix the problem? – Ryan Jul 23 at 16:24
If your file my.cnf (usually in the /etc/mysql/ folder) is correctly configured with
socket=/var/run/mysqld/mysqld.sock
modified
#bind-address = 127.0.0.1
to
bind-address = localhost
you can check if mysql is running with the following command:
mysqladmin -u root -p status
try changing your permission to mysql folder. If you are working locally, you can try:
sudo chmod -R 755 /var/run/mysqld/
And then restart the mysql.
Good luck.
Could it be the log file getting too large and rebooting flushes it. See this in docs on server maintenance and logfiles. Also see discussion at digital ocean. Appears to be confirmed by discussion at serverfault
You could try change the permission of your MySQL sock file like this:
chmod 777 '/var/run/mysqld/mysqld.sock'
It is a test to see if whatever user mysqld is using, it will acess your mysqld.sock file. So, reboot your MySQL and change the permission of mysqld.sock. And you need to check that if your sock folder can be accessed through any mysqld process.
If the mysqld.sock file doesn't exist, that is to say your config file is not correct.Check your mysql config file in /etc/mysql/my.conf, find the socket config just as Vanya Avchyan says.
I think the socket config is /var/run/mysqld/mysqld.sock, but in fact your mysql process runs in other place sock file.
I used to met that problem, the real socket file exists in /tmp/mysqld.sock.
So run
sudo find / -name 'mysqld.sock'
to find the real sock file and change my.conf to this real place, restart your mysql. May have work.
I am trying to change one of the mysql variables.
[mysqld]
ft_min_word_len=2
On the external server, I was able to change this in my.cnf. However, I cannot for the life of me find this file on my computer. I also cannot find my.ini (I am on windows). I can find my-huge.ini and various other sizes.
QUESTIONS
Might it be called something else?
Do I have to make it? Or, is there a way to change this option without opening the file?
Since ft_min_word_len already has a value, it must be SOMEWHERE!
I tried
mysqld --help
but it does not tell me anything really. I tried:
mysqld --help --verbose
It says very much and whatever is at the start, I cannot see. It won't let me print to any files: "access is denied"
Edit: I looked for it using
dir /s my.ini
I have a little surprise for you. You said you found my-huge.ini. The folder where my-huge.ini resides is the folder my.ini should be. If my.ini is not in the same folder, THEN my.ini SIMPLY DOES NOT EXIST. Consequently, mysqld.exe is running on pure defaults for all configuration settings.
Whenever MySQL was installed as a service, there was no my.ini created. Over the years, I have noticed that after an MSI installation of MySQL, the file mysqld.exe (which is in the bin folder) looks to the parent directory for the my.ini.
Let's say you found my-huge.ini in c:/wamp/bin/mysql/mysqlVERSIONNUMBER
Just create the my.ini in that place as well. Then, restart the mysql service. Open a DOS Window using Run as Administrator and run the following:
C:\> cd c:\wamp\bin\mysql\mysqlVERSIONNUMBER
C:\> echo "[mysqld]" > my.ini
C:\> echo "ft_min_word_len=2" >> my.ini
C:\> net stop mysql
C:\> net start mysql
Give it a Try !!!
I am trying to enable logging on MySQL on my Mac, OS X version 10.8.3.
Everywhere I searched, I get the same answer, i.e. to add the following to my.cnf:
[mysqld]
general_log=1
log=/var/log/mysql-query.log
and then restart mysql.
Permissions on the log file are correct and owner is _mysql like all other MySQL files.
However, doesn't matter how much I try, once my.cnf has been modified, MySQL won't restart. It would only shutdown and that's it. Via command line or via Preferences Pane, it won't start again.
I tried enabling log vie Workbench too, but as soon as log=... entry goes into my.cnf, MySQL refuses to start. I have to manually delete this entry to start MySQL.
Can anybody please guiding me on how to enable logging for MySQL on OS X 10.8.3?
Ok, finally wasting more than a day, what worked for me is this:
general-log
general_log_file = /var/log/mysql-query.log
For almost 10 years, in all the Linux systems I have ever used and installed, which must be at least 100 if not more, it has always been a simple entry like log=< path to log file > under [mysqld] section. Apparently it was the same on Macs too what I read from various blogs etc, however on this particular setup which I am doing, this is the first time that I am setting it up like above.
So my current working /etc/my.cnf file is as follows:
[client]
socket=/var/mysql/mysql.sock
[mysqld]
socket=/var/mysql/mysql.sock
general-log
general_log_file = /var/log/mysqld.log
I had to do:
touch /etc/my.cnf
chown _mysql /etc/my.cnf
to create one.
Also I had to do:
touch /var/log.mysqld.log
chown _mysql /var/log/mysqld.log
followed by restarting mysql via Workbench. Also tried restart via command line as follows:
/usr/local/mysql/bin/mysqladmin -uroot -p shutdown
sudo /usr/local/mysql/bin/mysqld_safe &
Main thing is, finally it is working and I can move ahead with my day.
I'm running MySQL Workbench 5.2.47 on Mac Mountain Lion. The above steps (create a /etc/my.cnf, create a dummy log file for mysql to populate, etc) could all be accomplished in MySQL Workbench.
1) Go to Server Admin -> Options File(Configuration).
2) Set your options, including location of 'general-log' under the 'Logging' tab. Click 'Apply'.
3) Startup / Shutdown -> Stop Server
4) Startup / Shutdown -> Start Server
Logging should now be turned on for all your statements.
#zeeshan's answer was pointed me to the write direction the most important thing is to make sure the permissions are right just as zeehan has mentioned.
/etc/my.cnf
[mysqld]
general_log = 1
general_log_file = /var/log/mysql-query.log
Then just chown the log and my.cnf files to be owned by "_mysql".
sudo chown _mysql /var/log/mysql-query.log
sudo chown _mysql /etc/my.cnf
Should be able to restart the mysqld using system_preferences.
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.