ファイル/var/lib/mysql/user.lower-testを作成できません

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データディレクトリを/ 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

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,

}

/ var / lib / mysqlを別のディスクに移動し、元のディレクトリをシンボリックリンクに置き換えようとしたときに、問題が発生しました。

Apparmorはこの構成でアクセスを拒否します

• https://bugs.launchpad.net/apparmor/+bug/1485055

これがApparmor開発者によってバグではないと考えられる理由。回避策は、バインドマウントを使用することです。見る

• /unix/198590/what-is-a-bind-mount

説明のために。

そう

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サイズを小さくしました。