mysql my.cnf被忽略

Question

The Issue

我试图在我的生产服务器上修改一个my.cnf值，但是这些更改在sudo service mysql restart之后并没有生效，它使用了开发服务器上的my.cnf的确切副本(下载和替换)--从mysql命令行中的显示变量中可以看到所做的更改。

my.cnf位于/etc/mysql/my.cnf

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

所以整个系统上只有一个文件。

生产ubuntu 10.04 LTS 64位

开发为ubuntu 11.10 32位

Mysql版本分别为5.1.61和5.1.62。

更新2 :

运行mysql停止和mysql状态后，如果运行top -b | grep mysql，则返回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启动，这会让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/

Answer 1

/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无法保证目录中选项文件的读取顺序.在Unix操作系统上使用！included指令查找和包含的任何文件都必须有以.cnf结尾的文件名。在Windows上，此指令检查具有.ini或.cnf扩展名的文件。

Answer 2

如果您想知道在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

在我的例子中，即使是在我的my.cnf上定义(my.cnf)的属性也被忽略了。这发生在Percona集群服务器-55.x86_64 1:5.5.34-25.9.607.rhel6之后。

最后，通过在命令行中指定它，临时解决了这个问题：

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

对于Percona集群(基于Galera)，您必须使用引导: /etc/init.d/mysql引导-pxc-query_cache_size=0启动第一个节点。

Answer 3

我也遇到了my.cnf被忽略的问题，在我的例子中，文件的权限是错误的。

它是由根和模式设置为600拥有的。

sudo chmod 644 my.cnf

我把它改成了644，问题就解决了。

重要注

来自MySQL文档：在Unix平台上，MySQL忽略了具有全局可写性的配置文件.作为一项安全措施，这是故意的。