Binary log error in mysql - 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.

Related

Where to find Percona Configuration file?

Recently I have installed Percona 5.7.12 in my linux box but I have not found any configuration file(like my.cnf for mysql) where i can set/modify global variables.
I want to change the values of default system variables like 'sql_mode', password_policy etc.I tried setting values like *SET GLOBAL sql_mode = 'ALLOW_INVALID_DATES';* but after restart of mysqld instance, it seems old default values are retained.How can I set those values permanently so that modified values are retained??? Any help would be appreciated.
According to Percona's install guide, the config file should be located under /etc/my.cnf:
Percona Server stores the data files in /var/lib/mysql/ by default. You can find the configuration file that is used to manage Percona Server in /etc/my.cnf.
If there is no such file in the /etc directory, then you can create it yourself and set any config parameters there. Parameters in the config file are preserved across MySQL system restarts.
It's this file /etc/mysql/conf.d/mysql.cnf in my Percona 5.7 installation.
I can find it by following these steps:
mysqladmin --help
The output contains these lines:
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
The first file (/etc/my.cnf) doesn't exist on my machine.
The second one (/etc/mysql/my.cnf) contains these lines:
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/percona-server.conf.d/
This file /etc/mysql/conf.d/mysql.cnf in the first directory contains the settings I would expect in /etc/my.cnf.
I was facing this same issue. Found that the xtrabackup versions at both the servers were way different (8.0.23 at the source where the backup was taken and 2.4.9 at the destination where I was trying to restore the backup).
As soon as I upgraded the xtrabackup version to 8.0.23 on the destination server, the "prepare" went smoothly without any issues.

How to make sql-mode="NO_ENGINE_SUBSTITUTION" permanent in MySQL my.cnf

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.

Can't Restart MySQL After Editing my.cnf on Mac OS X 10.8.3

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.

logging mysql queries wont work

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

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