mysql my.cnf игнорируется

Проблема

Я пытаюсь изменить значение my.cnf на своем производственном сервере, но изменения не вступают в силу после sudo service mysql restartс использованием точной копии my.cnf (загруженной и замененной оригинальной) на моем сервере разработки внесенные изменения видны из переменных show в командной строке mysql.

my.cnf находится по адресу /etc/mysql/my.cnf

sudo find / -name my.cnf
/etc/mysql/my.cnf

Таким образом, во всей системе существует только один файл.

Производится ubuntu 10.04 LTS 64bit
Разработка - ubuntu 11.10 32bit

Версии MySQL 5.1.61 и 5.1.62 соответственно.

Обновление 2:

После запуска mysql stop и mysql status верните mysql stop / wait, если я запустил top -b | grep mysql

27652 root      20   0  4096  424  420 S    0  0.0   0:00.01 mysqld_safe
27769 mysql     20   0  392m  57m 7236 S    0  1.5 119116,08 mysqld

Похоже, что он все еще работает, и время мне не нравится, но теперь я беспокоюсь, что если я убью этот / этот процесс, я не смогу снова запустить mysql, и это плохо: S.

Я понимаю, что это, вероятно, не то, на что можно ответить, но убив эти процессы, а затем запустив службу mysql start, будет ли mysql снова запущен? - Кроме того, есть ли у вышеперечисленных процессов нормальные номера?

Обновить:

Разве это не означает, что он получает настройки из my.cnf ... но не использует его? Так что сейчас очень запуталась.
В конце концов он получил настройки innodb_buffer ...

mysqld --print-defaults
mysqld would have been started with the following arguments:
--user=mysql --socket=/var/run/mysqld/mysqld.sock --port=3306 --basedir=/usr --datadir=/var/lib/mysql --tmpdir=/tmp --skip-external-locking --bind-address=127.0.0.1 --key_buffer=16M --max_allowed_packet=16M --thread_stack=192K --thread_cache_size=8 --myisam-recover=BACKUP --query_cache_limit=1M --query_cache_size=16M --log_error=/var/log/mysql/error.log --expire_logs_days=9 --max_binlog_size=100M --innodb_file_per_table=1 --innodb_buffer_pool_size=500M --innodb_buffer_pool_size=500M --user=mysql --socket=/var/run/mysqld/mysqld.sock --port=3306 --basedir=/usr --datadir=/var/lib/mysql --tmpdir=/tmp --skip-external-locking --bind-address=127.0.0.1 --key_buffer=16M --max_allowed_packet=16M --thread_stack=192K --thread_cache_size=8 --myisam-recover=BACKUP --query_cache_limit=1M --query_cache_size=16M --log_error=/var/log/mysql/error.log --expire_logs_days=9 --max_binlog_size=100M --innodb_file_per_table=1 --innodb_buffer_pool_size=500M --innodb_buffer_pool_size=500M

my.cnf

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
user        = mysql
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
skip-external-locking
bind-address        = 127.0.0.1
key_buffer      = 16M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 8
myisam-recover         = BACKUP
query_cache_limit   = 1M
query_cache_size        = 16M
log_error                = /var/log/mysql/error.log
expire_logs_days    = 10
max_binlog_size         = 100M
innodb_file_per_table = 1

[mysqldump]
quick
quote-names
max_allowed_packet  = 16M

[mysql]

[isamchk]
key_buffer      = 16M

!includedir /etc/mysql/conf.d/

Если вы хотите узнать в системе Linux, действительно ли ваш mysqld читает этот конкретный файл, я бы порекомендовал strace:

strace -e trace=open mysqld

Это покажет вам все файлы, которые открываются процессом mysqld во время запуска. В нашем случае:

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/libpthread.so.0", O_RDONLY) = 3
open("/lib64/libaio.so.1", O_RDONLY)    = 3
open("/lib64/libm.so.6", O_RDONLY)      = 3
open("/lib64/librt.so.1", O_RDONLY)     = 3
open("/lib64/libcrypt.so.1", O_RDONLY)  = 3
open("/lib64/libdl.so.2", O_RDONLY)     = 3
open("/usr/lib64/libssl.so.10", O_RDONLY) = 3
open("/lib64/libcrypto.so.10", O_RDONLY) = 3
open("/lib64/libc.so.6", O_RDONLY)      = 3
open("/usr/lib64/libfreebl3.so", O_RDONLY) = 3
open("/lib64/libgssapi_krb5.so.2", O_RDONLY) = 3
open("/lib64/libkrb5.so.3", O_RDONLY)   = 3
open("/lib64/libcom_err.so.2", O_RDONLY) = 3
open("/lib64/libk5crypto.so.3", O_RDONLY) = 3
open("/lib64/libz.so.1", O_RDONLY)      = 3
open("/lib64/libkrb5support.so.0", O_RDONLY) = 3
open("/lib64/libkeyutils.so.1", O_RDONLY) = 3
open("/lib64/libresolv.so.2", O_RDONLY) = 3
open("/usr/lib64/libselinux.so.1", O_RDONLY) = 3
open("/proc/filesystems", O_RDONLY)     = 3
open("/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 3
open("/sys/devices/system/cpu", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/etc/my.cnf", O_RDONLY)           = 3
open("/etc/localtime", O_RDONLY)        = 3
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 3

В моем случае оказалось, что даже свойство было определено (query_cache_size) на моем my.cnf, оно было проигнорировано. Это произошло после обновления до Percona-XtraDB-Cluster-server-55.x86_64 1: 5.5.34-25.9.607.rhel6.

В конце концов я временно решил это, указав его в командной строке:

/etc/init.d/mysql start --query_cache_size=0

В случае Percona Cluster (на основе Galera) вы должны запустить первый узел с помощью начальной загрузки: /etc/init.d/mysql bootstrap-pxc --query_cache_size = 0

У меня такая же проблема my.cnf будучи игнорируется, в моем случае права доступа к файлу были неправильными.

Он принадлежал root, а режим установлен на 600.

sudo chmod 644 my.cnf

Я изменил это на 644 и проблема была решена.

Важная заметка

Из Документов MySQL:

На платформах Unix MySQL игнорирует файлы конфигурации, которые доступны для записи всем.

Это сделано намеренно в качестве меры безопасности.

Что-нибудь интересное в /etc/mysql/conf.d/? Версия Mysql, которую вы используете, должна анализировать my.cnf тогда что-нибудь в /etc/mysql/conf.d/ в порядке имен файлов конфигурации. В предыдущих версиях порядок мог быть несколько недетерминированным.

Любое значение, установленное последним в цепочке, должно победить, что может объяснить, почему ваши изменения в my.cnf не обновляют сервер; Если более поздние файлы имеют приоритет над вашими настройками.

Если в /etc/mysql/conf.d/ к черту создайте файл с именем innodb.cnf (не будет разбирать ничего, что не заканчивается на .cnf) только с этими двумя строками и посмотрите, обновятся ли ваши настройки innodb после перезапуска.

[mysqld]
innodb_buffer_pool_size = 500M

Информация из Документов:

username$ mysqld --verbose --help | grep '/my.cnf' -B 1

Default options are read from the following files in the given order:
/etc/my.cnf 
/etc/mysql/my.cnf 
/usr/local/mysql/etc/my.cnf 
~/.my.cnf

и подробности этого есть в документации MySQL. Смотреть под Table 4.2

Можно использовать !include директивы в файлах опций для включения других файлов опций и !includedir для поиска файлов опций в определенных каталогах .....

...MySQL не гарантирует, в каком порядке будут считываться файлы опций в каталоге....

Любые файлы, которые можно найти и включить с помощью директивы! Includedir в операционных системах Unix, должны иметь имена, оканчивающиеся на .cnf. В Windows эта директива проверяет файлы с .ini или .cnf расширение.

В моем случае я застрял с этой проблемой примерно на день, в Ubuntu 18.04 MySQL 5.6 не следовал символическим ссылкам. (Почему я действительно не знаю).

В моем окружении у меня было /etc/mysql/my.cnf который был связан с символической ссылкой, /etc/alternatives/my.cnf, который затем был привязан к /etc/mysql/my.cnf.fallback

Итак, я выполнил следующие команды в /etc/mysql/:

sudo mv my.cnf my.cnf.bak
sudo cp my.cnf.fallback my.cnf

Я также убедился, что мои конфиги не доступны для записи всем, например Франко предложил

Похоже, ваш экземпляр mysql не запущен

У вас запущен экземпляр mysql.server, который успешно работает, но он использует свой собственный my.cnf (то есть по умолчанию my.cnf)

Я из фона centos, но я думаю, что он одинаков во всех env.

mysql.server start

Надеюсь, вы увидите следующее сообщение:

Starting MySQL. SUCCESS!

Обычно это с заблокированным pid, dead / lock subsys ..

(не знаю, действительно ли это дает вам подсказку или помощь)