MySQLデータベースは数か月間問題なく使用されてきました。今日、Synaptic Package Managerを使用してアップグレード可能なパッケージを確認したところ、さまざまなMySQLコンポーネント(-common、-client、-serverなど)が思い付きました。したがって、アップグレードすることに決めました(インストールしたバージョンを書き忘れていましたが、5.6.21だったと思います)を5.6.25-1-ubuntu2.0にアップグレードしました。その後、データベースのクエリを実行すると、次のメッセージが表示されました:-
Error occured: Can't connect to MySQL server on '127.0.0.1' (111)
その後、サーバーが稼働していないことがわかりました。ログファイルで、次のメッセージが好きです。
Can't create file /var/lib/mysql/user.lower-test
私は1時間ほどオンラインで検索しており、この問題は以前に報告されていますが、「更新後」の問題のコンテキストでは確認できていないため、次のステップがわかりません。
MySQLの複数のインスタンスを実行しようとしたときにこの問題に遭遇しましたが、apparmorを削除する代わりに、usr.sbin.mysqldファイルを更新しました。
vim /etc/apparmor.d/usr.sbin.mysqld
たとえば、これは私のファイルの外観です。書き込み権限が必要なフォルダーを追加すると、すべて正常に機能しました。
/usr/sbin/mysqld {
capability dac_override,
capability sys_resource,
capability setgid,
capability setuid,
network tcp,
/etc/hosts.allow r,
/etc/hosts.deny r,
/etc/mysql/*.pem r,
/etc/mysql/conf.d/ r,
/etc/mysql/conf.d/* r,
/etc/mysql/*.cnf r,
/usr/lib/mysql/plugin/ r,
/usr/lib/mysql/plugin/*.so* mr,
/usr/sbin/mysqld mr,
/usr/share/mysql/** r,
/var/log/mysql.log rw,
/var/log/mysql.err rw,
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
/var/lib/mysql1/ r,
/var/lib/mysql1/** rwk,
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid rw,
/var/run/mysqld/mysqld.sock w,
/var/run/mysqld/mysqld1.pid rw,
/var/run/mysqld/mysqld1.sock w,
/run/mysqld/mysqld.pid rw,
/run/mysqld/mysqld.sock w,
/sys/devices/system/cpu/ r,
}
この問題は、権限の問題か、mysqlデータディレクトリを/ var/lib/mysql以外の場所に変更するようです。
Sudoで実行してみてください
/ var/lib/mysqlはmysqlユーザーが所有し、グループもmysqlに設定されているようです。
$ Sudo chown -R mysql /var/lib/mysql
$ Sudo chgrp -R mysql /var/lib/mysql
$ Sudo chmod 755 /var/lib/mysql
/ var/lib/mysqlディレクトリが実際に存在し、データディレクトリに対応していることを確認しましたか?そうでない場合は、おそらくmysqldセクションの下にdatadirパラメータを指定する必要があります。
[mysqld]
datadir=/var/lib/mysql
その後、MySQLが新しいデータディレクトリとサブディレクトリを読み取り\実行\変更できるようにapparmorを設定するか、またはご自身の責任でapparmorを削除するかを選択できます。以下を実行するには、rootになる必要がある場合があります。
/etc/init.d/apparmor stop
/etc/init.d/apparmor teardown
update-rc.d -f apparmor remove
apt-get purge apparmor
reboot
この問題は、/ var/lib/mysqlを別のディスクに移動して、元のディレクトリをシンボリックリンクに置き換えようとしたときに発生しました。
Apparmorはこの構成でアクセスを拒否します
これがApparmor開発者によってバグではないと考えられる理由。回避策は、バインドマウントを使用することです。見る
説明のために。
そう
mount --bind /newmysqldatadir /var/lib/mysql
service mysql start
私のために問題を修正しました。
同様の問題がありました。私のマシンにUbuntuサーバーを再インストールし、ハードドライブに/ etc /の完全バックアップを作成しました。再インストールした後、/ drive/etc /からすべての重要なファイルのコピーをシステムの/ etcに作成しました。
これを行っている間に、usr.sbin.mysqld.bakというusr.sbin.mysqldファイルのbakを作成し、同じ/etc/apparmor.d/ディレクトリに保存しました。
さらに検索したところ、次のブログ投稿が見つかりました: https://blogs.Oracle.com/jsmyth/apparmor-and-mysql
Apparmor-utilsをインストールし、/ usr/sbin/mysqldでaa-complainを行おうとしたところ、2つのapparmor構成(両方のファイル)が定義されていると言われました。
あなたが直面している問題ではないかもしれませんが、わかりやすくするために、apparmor sbinディレクトリと同じディレクトリにバックアップファイルを作成するなど、私を馬鹿にしないでください。
また、パーティションがいっぱいでないかどうかも確認してください。これは私の場合です。
不明な理由により、データを別のパーティションに移動することもできませんでした。
したがって、迅速な修正のために、llvmやgpartedをいじる代わりに、/swapfile
サイズ。