mysql my.cnf忽略

问题

我试图在我的生产服务器上修改一个my.cnf值,但是在sudo service mysql restart ,在我的开发服务器上使用my.cnf的一个精确副本(下载并replace原来的)在mysql命令行中显示variables是可见的。

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状态后返回mysql停止/等待,如果我运行top -b | grep mysql 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开始,这将有MySQL再次运行? – 另外,上面的proccesses有正常的数字吗?

更新:

这不意味着它从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/ 

/etc/mysql/conf.d/中有什么有趣的东西? 你正在使用的Mysql 5.1的版本应该按照configuration文件名的顺序parsingmy.cnf,然后parsing/etc/mysql/conf.d/中的任何东西。 在以前的版本中,顺序可能有点不确定。 无论在链上最后设置什么值都应该赢,这也许可以解释为什么在my.cnf中的更改没有更新服务器,如果以后的文件重写您的设置。

如果在/etc/mysql/conf.d/中没有任何内容,那么只需用这两行创build一个名为innodb.cnf的文件(不会parsing那些不以.cnf结尾的文件),看看你的innodb在重新启动后设置更新。

 [mysqld] innodb_buffer_pool_size = 500M 

如果你想在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 

在我的情况下,事实certificate,即使该属性被定义(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集群(基于Galera),必须使用bootstrap启动第一个节点:/etc/init.d/mysql bootstrap-pxc –query_cache_size = 0

看起来像你的mysql实例没有运行

你有mysql.server实例运行成功运行,但它使用自己的my.cnf(意思是默认my.cnf)

我是从centos背景,但是在所有env我都猜到了。

 mysql.server start 

希望你会看到下面的消息:

 Starting MySQL. SUCCESS! 

这是一般,与lockingPID,死/锁子..

(不知道这是否真的提供任何线索或帮助)

得到了同样的问题my.cnf被忽略,在我的情况下文件的权限在哪里错了(被拥有的根和模式设置为600)

 sudo chmod 644 my.cnf 

改成644,问题解决了。