I am running an Xubuntu 16.04 machine, and have installed mysql version 5.6. I wanted to change the mysql settings buffer pool size among other things. I tried editing /etc/mysql/my.cnf, /etc/mysql/conf.d/mysql.cnf. Then restarted mysql server. After that, when I login to mysql console and try to print the variables, I still do not see the values I entered in the config files. What am I missing?
EDIT
I have put the settings under [mysqld] section. Below is the content of the above files:
[mysqld]
innodb_buffer_pool_size=4G
innodb_log_buffer_size=512M
innodb_log_file_size=2G
innodb_write_io_threads=16
innodb_flush_log_at_trx_commit=0
Related
I am trying to update MySQL "innodb_buffer_pool_size" in windows server. I have run "set global innodb_buffer_pool_size=25610241024".
After I restart the server it's set back to 8M again.
If I change my.ini file then MySQL57 service is not running.
I am using MySQL 5.7.36.
To save setting, you need to put them in a my.ini file that the mysql server reads on startup.
SET GLOBAL... only affect the current running instance.
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.
I needed to set up the system variable "show_compatibility_56" to ON in MySQL. So, I run the command set global show_compatibility_56 = on;, and it worked However, I noticed that whenever I stop and then start the MySQL server, this variable goes back to OFF. Any hints on how to keep it always ON even if I restart the server?
I'm using a Laravel Homestead (Vagrant) box (MySql Ver 14.14 Distrib 5.7.17).
I needed to SSH into Homestead and then run:
echo "[mysqld]
show_compatibility_56 = ON
performance_schema" | sudo tee -a /etc/mysql/conf.d/mysql.cnf >/dev/null
sudo service mysql restart
(Thanks to Mark Reed for showing how to skip opening vim.)
Older version:
sudo vim /etc/mysql/conf.d/mysql.cnf
Then I added this section:
[mysqld]
show_compatibility_56 = ON
performance_schema
I was surprised that other answers here and elsewhere on the web didn't specify that it needed to be under [mysqld] instead of [mysql] and also that you must restart the MySql service:
sudo service mysql restart
you need to save this variable setting in your configuration file my.cnf for linux and my.ini for windows.
To make it permanent, you need to add this variable in configuration file of MySQL like we did for all other variables as:
show_compatibility_56 = ON
For Linux based system: File name is my.cnf and default location is /etc/my.cnf
For Windows based system: File name is my.ini and default location is your windows mysql data directory that you can check via below command:
show variables like 'datadir';
If you've installed MySQL through Hombrew on a Mac, there isn't a my.cnf by default. I created one in /etc/my.cnf, added the text from #Ryan's answer:
[mysqld]
show_compatibility_56 = ON
performance_schema
... and then restarted MySQL, with (I'm using the older 5.7 version):
$ brew services restart mysql#5.7
This worked for me.
As Zafar has already pointed you can set the variable in the configuration file to save the value.
Also note that this is now deprecated. The manual says:
Note:
show_compatibility_56 is deprecated because its only purpose is to
permit control over deprecated system and status variable information
sources that will be removed in a future MySQL release. When those
sources are removed, show_compatibility_56 will have no purpose and
will be removed as well.
I want to change max_allowed_packet on server using WHM vps.
but I am not getting at where it located, so please help me
I have tried
SET GLOBAL max_allowed_packet =1073741824;
but its not working its required super admin.
how to edit mysql.ini in WHM vps
same with httpd.conf, how to edit setting of apache in WHM ?
Ahoy,
You can not edit the servers my.cnf file from inside WHM, you will need to edit this file using she ssh command line. To learn how to connect to your server using ssh please see:
http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CpanelDocs/ShellAccess
Once you are connected to your server with the root login using ssh, you will want to issue the following command to edit my.cnf:
# nano -w /etc/my.cnf
In this file you will want to add a line under the [mysqld] section with the following contents:
max_allowed_packet=500M
You will now want to press Ctrl + O to save, and then Ctrl + X to exit. You will now want to restart the MySQL server through WHM or on the command line with:
# /etc/init.d/mysql restart
This will update the max_allowed_packet for cPanel/WHM's mysql.
Change in the my.ini/my.cnf file. Include the single line under [mysqld] in your file
max_allowed_packet=500M
now restart the MySQL service once you are done. You can see it's current value in mysql like this:
SHOW VARIABLES LIKE 'max_allowed_packet'
You can read about it here http://dev.mysql.com/doc/refman/5.1/en/packet-too-large.html
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.