mysql my.cnfは無視されました
問題
運用サーバーでmy.cnfの値を変更しようとしていますが、開発サーバーでmy.cnf（ダウンロードして元に置き換えたもの）の正確なコピーを使用してSudo service mysql restartを実行しても変更が反映されません。行われた変更は、mysqlコマンドラインのshow変数から確認できます。
my.cnfは/etc/mysql/my.cnfにあります
Sudo find / -name my.cnf
/etc/mysql/my.cnf
したがって、システム全体に存在するファイルは1つだけです。
生産はubuntu 10.04 LTS 64bitです
開発はubuntu 11.10 32ビットです
Mysqlのバージョンはそれぞれ5.1.61と5.1.62です。
更新2：
Mysql [stop]とmysql statusを実行した後、top -b | grep mysqlを実行すると、mysql stop/waitingが返されます。
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/
/etc/mysql/conf.d/で興味深いものはありますか？使用しているMysqlのバージョンはmy.cnfを解析し、次に/etc/mysql/conf.d/のすべてを設定ファイル名の順に解析する必要があります。以前のバージョンでは、順序はやや非決定的でした。
チェーンの最後に設定された値が勝つ必要があります。これは、my.cnfの変更がサーバーを更新していない理由を説明している可能性があります。後でファイルが設定を上書きしている場合。
/etc/mysql/conf.d/に何もない場合は、innodb.cnfというファイルを作成し（.cnfで終わらないものは解析しないでください）、次の2行だけで、再起動後に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オペレーティングシステムで！includedirディレクティブを使用して検索およびインクルードされるファイルは、ファイル名の末尾が
.cnfである必要があります。 Windowsでは、このディレクティブは.iniまたは.cnf拡張子を持つファイルをチェックします。
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でプロパティ（query_cache_size）が定義されていても無視されたことがわかりました。これは、Percona-XtraDB-Cluster-server-55.x86_64 1：5.5.34-25.9.607.rhel6の後にアップグレードして発生しました。
最後に、コマンドラインで指定して一時的に解決しました。
/etc/init.d/mysql start --query_cache_size=0
パーコナクラスター（Galeraベース）の場合、最初のノードをブートストラップで開始する必要があります：/etc/init.d/mysql bootstrap-pxc --query_cache_size = 0
私の場合、my.cnfが無視されるという同じ問題が発生しました。私の場合、ファイルの権限が間違っていました。
ルートが所有し、モードが600に設定されています。
Sudo chmod 644 my.cnf
644に変更し、問題は解決しました。
重要な注意点
Unixプラットフォームでは、MySQLは誰でも書き込み可能な構成ファイルを無視します。
これは、セキュリティ対策として意図的なものです。
Mysqlインスタンスが実行されていないようです
正常に実行されているmysql.serverインスタンスが実行されていますが、独自のmy.cnf（つまり、デフォルトのmy.cnf）を使用しています
私はcentosの出身ですが、すべての環境で同じです。
mysql.server start
うまくいけば、次のメッセージが表示されます。
Starting MySQL. SUCCESS!
これは一般に、ロックされたPID、デッド/ロックサブシステムです。
（これが本当にあなたに手掛かりや助けを提供するかどうかわかりません）
私の場合、私はこの問題に1日ほど悩まされていました。Ubuntu18.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
Francoの提案 のように、私の構成が誰でも書き込み可能でないことも確認しました。