mysql my.cnf ignorado

Question

O problema

Estou tentando modificar um valor my.cnf no meu servidor de produção, mas as alterações não entram em vigor após sudo service mysql restart , usando uma cópia exata do my.cnf (original baixado e substituído) no meu desenvolvimento servidor as alterações feitas são visíveis a partir de variáveis de show na linha de comando do mysql.

my.cnf está localizado em /etc/mysql/my.cnf

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

Portanto, apenas um arquivo existe em todo o sistema.

A produção é do Ubuntu 10.04 LTS 64bit
O desenvolvimento é Ubuntu 11.10 32bit

As versões do Mysql são 5.1.61 e amp; 5.1.62 respectivamente.

Atualização 2:

Depois de executar mysql stop e mysql status retorne mysql stop / waiting, se eu rodar 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

Isto parece que ainda está rodando e o tempo não parece bom para mim, mas agora estou preocupado se eu matar estes / este processo eu não serei capaz de fazer o mysql rodar novamente, e sendo produção isso é ruim: S.

Eu percebo que provavelmente não é algo que pode ser respondido, mas matar esses processos e, em seguida, executar o serviço mysql start, isso terá o mysql em execução novamente? - Além disso, os processos acima têm números normais para eles?

Atualização:

Isso não significa que ele está obtendo as configurações do my.cnf ... mas não está usando? Muito confuso agora.
No final, tem as configurações do 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/

    

Answer 1

Algo interessante em /etc/mysql/conf.d/? A versão do Mysql 5.1 que você está usando deve analisar my.cnf e depois qualquer coisa em /etc/mysql/conf.d/ na ordem dos nomes dos arquivos de configuração. Nas versões anteriores, a ordem poderia ser algo não determinista. Seja qual for o valor definido pela última vez na cadeia, deve ganhar, o que pode explicar por que suas alterações em my.cnf não estão atualizando o servidor, se arquivos posteriores estiverem sobrescrevendo suas configurações.

Se não houver nada em /etc/mysql/conf.d/, crie um arquivo chamado innodb.cnf (não analisará nada que não termine em .cnf) com apenas essas duas linhas e veja se sua configuração innodb é atualizada após o reinício.

[mysqld]
innodb_buffer_pool_size = 500M

    

Answer 2

Se você quer saber sobre um sistema linux se o seu mysqld está realmente lendo este arquivo em particular, eu recomendaria strace:

strace -e trace=open mysqld

Isso mostrará todos os arquivos que são abertos pelo processo mysqld durante a inicialização. No nosso caso:

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

No meu caso, descobriu-se que até mesmo a propriedade foi definida (query_cache_size) no meu my.cnf foi ignorada. Isso aconteceu depois e atualizar para Percona-XtraDB-Cluster-server-55.x86_64 1: 5.5.34-25.9.607.rhel6.

No final, resolvi temporariamente isso especificando-o na linha de comando:

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

No caso do Percona Cluster (baseado no Galera) você tem que iniciar o primeiro nó com o bootstrap:     /etc/init.d/mysql bootstrap-pxc --query_cache_size = 0

    

Answer 3

Tenho o mesmo problema de my.cnf sendo ignorado, no meu caso, as permissões do arquivo estavam erradas (era de propriedade root e o modo era definido como 600)

sudo chmod 644 my.cnf

mudou para 644 e o problema foi resolvido.

    

Answer 4

Parece que sua instância do mysql não está em execução

Você tem a instância mysql.server em execução que é executada com sucesso, mas usa seu próprio my.cnf (ou seja, my.cnf padrão)

Eu sou do fundo centos, mas é o mesmo em todos env, eu acho.

mysql.server start

Espero que você veja a seguinte mensagem:

Starting MySQL. SUCCESS!

Geralmente, com assinaturas dead / lock bloqueadas pid ..

(não sei se isso realmente fornece alguma pista ou ajuda)