I have made some changes in my /etc/my.cnf to turn ON log_bin. I then rebooted the server. But when I do SHOW VARIABLES, the log_bin is still turned off. This means that mysql is not using /etc/my.cnf. Hence, I did locate my.cnf and there are no more paths for the file.
How can I turn on log_bin?
EDIT:
When I did sudo docker container ps, I can see a MYSQL image:
CONTAINER ID IMAGE COMMAND
asdshg3 mysql/mysql-server:5.7 "/entrypoint.sh mysq…"
I think this is the reason why my /etc/my.cnf is not getting picked up.
Related
The server is working on CentOS 8, I'm trying to configure MariaDB by making alterations to /etc/my.cnf but then when I restart DB by doing sudo systemctl restart mariadb, the server does restart but no configuration changes get applied.
mysql > SHOW VARIABLES;
It outputs the same values. I tried to comment out the including directive #!includedir /etc/my.cnf.d and to add settings to [mysqld] and [mariadb] sections.
mysql --verbose --help says:
Default options are read from the following files in the given order:
/etc/my.cnf ~/.my.cnf.
The following groups are read: mysql client client-server client-mariadb
Check whether mysql uses the config file debugging it with strace:
sudo strace mysql
In the strace output, look for lines like:
openat(AT_FDCWD, "/etc/my.cnf", O_RDONLY|O_CLOEXEC) = ...
Make sure openat doesn't return -1. In that case check whether the file exists or mysql has enough permissions to read the file.
When adding additional configuration files, make sure that they are not writable by 'other'. Otherwise you'll have a message on mysql startup like:
Warning: World-writable config file '/etc/mysql/conf.d/myproject.cnf' is ignored
and the configuration does not get applied.
I try to configure mysql as mentioned here: https://websiteforstudents.com/install-erpnext-erp-platform-on-ubuntu-16-04-18-04-lts-with-nginx-mariadb-support/ on a Linux Mint 18.2 system.
I added innodb-file-format=barracuda to the [mysqld] section in /etc/mysql/mariadb.conf.d/50-server.cnf and restarted the mysql service. But these settings are taking no effect.
If I run following commands
sudo mysql -u root -p
SHOW VARIABLES LIKE 'innodb_file_format';
then I get following output.
+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| innodb_file_format | Antelope |
+--------------------+----------+
The settings file ~/.my.cnf is not existing.
Why are my settings taking no effect?
++++++++++++ UPDATE 2019-06-03 ++++++++++++
I think I found the issue now. /etc/mysql/mariadb.conf.d/50-server.cnf is the correct logfile and the settings were not overwritten by another *.cnf-file. After a restart of the PC, the changed settings were used. The problem is, that restarting the mysql service (sudo service mysql restart or sudo /etc/init.d/mysql restart) is not enough.
So the question should be:
How do I correctly restart mysql so that changes in the *.cnf-files get active?
First, you should try to find my.cnf in other locations like
How do I find the MySQL my.cnf location
If no luck, scan all *.cnf files in /etc/mysql/mariadb.conf.d/ because Mariadb may read all *.cnf as config in that folder
Therefore you may add this value on 50-server.cnf, but it is overwritten in another files
Hope this helps
Don't do this:
systemctl restart mysqld
Instead, do:
systemctl stop mysqld
systemctl start mysqld
Not sure exactly what the syntax is for Debian's 'service' command but I believe that's just a wrapper around systemctl. Syntax should be easily found. Change the service name if your system uses something different, of course. I have found that for some services, doing a restart doesn't seem to reread the config files, while a stop and then start forces a complete reload and config file read.
I changed some mysql config settings and set something wrong, now Docker container keeps restarting and I cannot find the my.cnf file to edit in host filesystem. I have tried aufs/diff folders but so far unable to find it. Also tried:
find / -name my.cnf -exec nano {} \;
But it does not bring up the file I changed. And I tried to change config.v2.json to start /bin/bash instead of mysqld and restarted docker, but yet it started mysqld (due supervisor or something?) using official mysql container image.
I am seeing two possible solutions for your problem:
Bypass the ENTRYPOINT for the MySQL image
Find your image name by running docker images then run:
docker run -it --entrypoint="/bin/sh" OPTIONS image
That should take you to the bash inside the container and from there you can execute all the commands you want to find your my.cnf file. Although I don't know if editing the file from there, save it and try to run it again will works. I didn't tried.
Delete the old image and use the proper way to edit the my.cnf file
Find your image name by running: docker images and then delete it by running docker rmi <image_name>
Check the docs for the default MySQL images at MySQL Dockerhub is pretty straight on this and I quote:
Using a custom MySQL configuration file The MySQL startup
configuration is specified in the file /etc/mysql/my.cnf, and that
file in turn includes any files found in the /etc/mysql/conf.d
directory that end with .cnf. Settings in files in this directory will
augment and/or override settings in /etc/mysql/my.cnf. If you want to
use a customized MySQL configuration, you can create your alternative
configuration file in a directory on the host machine and then mount
that directory location as /etc/mysql/conf.d inside the mysql
container.
If /my/custom/config-file.cnf is the path and name of your custom
configuration file, you can start your mysql container like this (note
that only the directory path of the custom config file is used in this
command):
$ docker run --name some-mysql -v /my/custom:/etc/mysql/conf.d -e
MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag
This will start a new
container some-mysql where the MySQL instance uses the combined
startup settings from /etc/mysql/my.cnf and
/etc/mysql/conf.d/config-file.cnf, with settings from the latter
taking precedence.
From that point and if you create the my.cnf file on your host then you'll never run into this problem again since you can edit the file as many times as you want.
I need some help to set MAX connections value permanently in MySql. I have tried but I can't find a permanent solution. Now, I am using temporary solution by changing in command prompt like in this article.
Since this question shows up on the search results when people search for a solution, and now that the solution has changed, I felt it necessary to post an answer.
Ubuntu 15.04+ no longer respects the limits set in /etc/security/limits.conf. So if you set max connections and you don't see any effect, have a look at the log file at sudo vim /var/log/mysql/error.log and you'll see Changed limits: max_connections: 214 (requested 5000).
Solution:
Copy the limits for mysql from the systemd config file to /etc/systemd using:
sudo cp /lib/systemd/system/mysql.service /etc/systemd/system/
sudo vim /etc/systemd/system/mysql.service
Then add the following lines to the bottom of the file:
LimitNOFILE=infinity
LimitMEMLOCK=infinity
You could also use a finite number instead of infinity.
Now reload systemd config:
sudo systemctl daemon-reload
Thank you Very much i inserted the code into the MY.ini file and it solved the problem.
in c:/xampp/mysql/bin/my.ini file under the [mysqld] section i inserted the following line
**
max_connections = 250
**
Later restart the xampp server to take effect.
if we give set-variable=max_connections=250 Mysql server is not starting.
Once again thank you very much.
I had the same problem using Ubuntu 16.04.
Had to do it this way:
sudo vim /etc/systemd/system/mysql.service
Added the lines at the bottom of the file:
LimitNOFILE=infinity
LimitMEMLOCK=infinity
Reloaded systemd config:
sudo systemctl daemon-reload
Increased the number of files the system could open:
ulimit -n 4096
Edited my.cnf like this:
vi /etc/mysql/mysql.conf.d/mysqld.cnf
Looked for the max_connections and changed it´s value to 20000.
To make sure the settings become permanent performed a mysql service restart:
sudo service mysql restart
Went to phpmyadmin and checked the max_connections global variable using:
SHOW VARIABLES like '%max_connections';
It worked - Now when the daemon restarts I have the same max_connections that I had before.
you can set that in my.cnf, Mysql Doc
I quote
You can increase this value in main config file (e.g., /etc/my.cnf or /etc/mysql/my.cnf) using this syntax:
[mysqld]
set-variable=max_connections=250
i think you need to restart mysql after changes to take effect.
I am having a bit of an issue that popped up over the past weekend.
One of my servers was rebooted and when the server came it started a default instance of mysql that is configured upon installation. It uses port 3306 as a default and blocks one of my instances from coming up.
How can I remove this default instance from booting and instead boot my instances in /etc/my.cnf ?
I think what is happening is it is going to /var/lib/mysql and starting an instance based off some default configuration as there is not a my.cnf file located here, but I find this code in init.d:
#Set some defaults
mysqld_pid_file_path=
if test -z "$basedir"
then
basedir=/usr
bindir=/usr/bin
if test -z "$datadir"
then
datadir=/var/lib/mysql
fi
But I don't see any my.cnf file at that location that it could be pulling configuration options from.
My data directories change per instance and they are all specified in /etc/my.cnf
I appreciate any effort spent helping with this issue.
Try this:
$ my_print_defaults --defaults-file=/etc/my.cnf mysqld
This will show you what it thinks datadir is set to, according to your config file.
I've seen config files get confused as people edit them, or even automated tools may edit the config file and append new config entries. Keep in mind if the config file has more than one line defining datadir, the last such line in the file takes precedence.
If you have an instance of mysqld starting up automatically at boot time, I'd use chkconfig to find out when that's happening. For example, here's a command run on my VM:
$ chkconfig
...
mysql 0:off 1:off 2:on 3:on 4:on 5:on 6:off
...
The numbers 0 through 6 are runlevels, and "on" means that when the given runlevel starts, the /etc/init.d/mysql service script is run by init.
You can also use chkconfig to modify which runlevels a given service starts under, and even to disable the service at all runlevels, so that it won't start automatically ever.
$ chkconfig --level 2345 mysql off
Refer to man chkconfig for more uses.