web-dev-qa-db-ja.com

MySQL：ファイル '/tmp/#sql_3c6_0.MYI'を作成/書き込みできません（エラーコード：2）-それはどういう意味ですか？

何らかの理由で、本番DBがこのメッセージを出力することにしました。すべてのアプリケーション呼び出しは次のエラーでDBに失敗します。

PreparedStatementCallback; SQL [ /*long sql statement here*/ ]; 
Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2); 
nested exception is Java.sql.SQLException: Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2)

これが何を意味するのか、私にはわかりません。 #sql_3c6_0.MYIにファイル/tmpがなく、何らかの理由で#文字を含むファイルを作成できません。誰かがそれについて聞いたか、このエラーを見ましたか？何が間違っている可能性がありますか？

MySQL DBは稼働しているようで、コンソールからクエリを実行できますが、アプリケーションはそれにアクセスできないようです。アプリケーションコード/ファイルに変更はありませんでした。それはちょうど青から起こった。だから私はどこから見るべきか、どのような解決策を適用すべきかさえわからない。何か案は？

mysqlexceptionjdbc
41
PhD

多くの場合、これは/tmpパーティションの容量が不足してファイルを作成できないか、何らかの理由でmysqldプロセスが権限の問題のためにそのディレクトリに書き込めないことを意味します。パレードでselinuxが降る場合があります。

「一時ファイル」を終了する操作は、デフォルトで/tmpディレクトリに入ります。表示されている名前は、内部のランダムな名前です。

19
tadman

Fedoraシステムでwordpressを実行すると、このエラーも発生します。

私はそれをグーグルで調べて、これを修正する方法を見つけました。

たぶんこれもあなたを助けるでしょう。

  1. mysql configを確認してください：my.cnf

     cat /etc/my.cnf | grep tmpdir

    my.cnfに何も表示されません

  2. tmpdir=/tmpの下のmy.cnfに[mysqld]を追加します

  3. web/appおよびmysqlサーバーを再起動します

    /etc/init.d/mysqld restart

36
Rivsen

Systemdを使用したFedoraでは、MySQLはプライベート/ tmpディレクトリを取得します。/proc/PID_of_MySQL/mountinfoには、次のような行があります。

156129 8：1/tmp/systemd-namespace-AN7vo9/private/tmp rw、relatime-ext4/dev/sda1 rw、seclabel、data = ordered

これは、一時フォルダー/ tmp/systemd-namespace-AN7vo9/privateがMySQLプロセスのプライベート名前空間に/ tmpとしてマウントされることを意味します。 残念ながら、頻繁に使用されない場合、このフォルダーはtmpwatchによって削除されます。

/etc/cron.daily/tmpwatchを変更し、次のような除外パターン-X '/tmp/systemd-namespace*'を挿入しました。

/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
        -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
        -X '/tmp/systemd-namespace*' \
        -X '/tmp/hsperfdata_*' 10d /tmp

副作用は、未使用のプライベート名前空間フォルダが自動的に削除されないことです。

16
ArturZ

ファイル名は、MySQLのクエリによって作成された一時テーブルのように見えます。これらのファイルは非常に短命であることが多く、特定のクエリ中に作成され、その後すぐにクリーンアップされます。

それでも、クエリが一時テーブルで処理する必要があるデータの量によっては、非常に大きくなる可能性があります。または、一時テーブルを作成する複数の同時クエリがあり、これらのクエリが同時に十分に実行されると、ディスク容量を使い果たす可能性があります。

私はMySQLコンサルティングを行い、ルートパーティションで断続的にディスクがいっぱいになるエラーが発生した顧客を支援しました。彼のクエリログを調べた結果、4つ以上のクエリが同時に実行され、それぞれがルートパーティションにある/ tmpに1.5GBの一時テーブルを作成することがあることがわかりました。ブーム！

私が彼に与えた解決策：

  • MySQLがメモリ内に非常に大きな一時テーブルを作成できるように、MySQL構成変数tmp_table_sizeおよびmax_heap_table_sizeを増やします。しかし、MySQLがメモリに1.5GBの一時テーブルを作成できるようにすることはお勧めできません。これらの同時作成されるテーブルの数を制限する方法がないためです。この方法でメモリをかなり早く使い果たすことができます。

  • MySQL構成変数tmpdirを、より多くのスペースがある別のディスクパーティション上のディレクトリに設定します。

  • どのクエリがそのような大きな一時テーブルを作成しているかを把握し、クエリを最適化します。たとえば、インデックスを使用して、クエリがスキャンをテーブルのより小さなスライスに減らすのに役立ちます。または、クエリ内のデータの一部をアーカイブして、クエリにスキャンする行があまりないようにします。

13
Bill Karwin

これについて正しい方向に向けてくれたArturZに多大な感謝を。私のシステムにはtmpwatchがインストールされていないので、それは私の問題の原因ではありません。しかし、最終結果は同じです：systemdが作成するプライベート/ tmpは削除されます。発生することは次のとおりです。

  1. systemdは、プライベートな名前空間を取得するために、CLONE_NEWNSフラグを使用してclone（）を介して新しいプロセスを作成します。または、CLONE_NEWNSでunshare（）を呼び出します。同じこと。

  2. systemdは、/ tmpにサブディレクトリ（たとえば、/ tmp/systemd-namespace-XRiWad/private）を作成し、/ tmpにマウントします。 CLONE_NEWNSは＃1で設定されているため、このマウントポイントは他のすべてのプロセスからは見えません。

  3. systemdは、このプライベート名前空間でmysqldを呼び出します。

  4. 特定のデータベース操作（「describe;」など）は、一時ファイルを作成および削除します。これには、/ tmp/systemd-namespace-XRiWad/privateのタイムスタンプが更新されるという副作用があります。他のデータベース操作は、/ tmpをまったく使用せずに実行されます。

  5. データベース自体はアクティブのままですが、/ tmp/systemd-namespace-XRiWad/privateのタイムスタンプを更新する操作は行われませんが、最終的には10日が経過します。

  6. / bin/systemd-tmpfilesが登場し、「古い」/ tmp/systemd-namespace-XRiWad/privateディレクトリが削除され、mysqldでプライベート/ tmpが事実上使用できなくなりますが、パブリック/ tmpはシステム上の他のすべてで使用できます。

Mysqldを再起動すると、新しいプライベート/ tmpディレクトリを使用して、ステップ1ですべてが再び開始されるため、機能します。ただし、問題は最終的に再び発生します。そしてまた。

簡単な解決策は、/ tmp/systemd-namespace- *という名前の/ tmp内のすべてを保存するように/ bin/systemd-tmpfilesを構成することです。これを行うには、次の内容の/etc/tmpfiles.d/privatetmp.confを作成しました。

x   /tmp/systemd-namespace-*
x   /tmp/systemd-namespace-*/private

問題が解決しました。

13
Thomas Dwyer III

私にとって、この問題はmysqlもウェブサーバーも使用していない長い期間の後に発生しました。だから私は自分の設定が正しいと確信していました。サービスを再起動するだけでこの問題が修正されます。この問題に関する奇妙な部分は、データベースに接続でき、mysqlツールを使用してテーブルをクエリ/追加できることです。例えば ​​：

mysql -u root -p

私はを使用して再起動しました：

systemctl start mysqld.service

またはサービスmysqld restartまたは/etc/init.d/mysqld restart

注：これらのコマンドのマシン/環境に応じて、サービスを再起動する必要があります。

6
SvennD

より良い方法が私のために働いた。

    chown root:root /tmp
  chmod 1777 /tmp
  /etc/init.d/mysqld restart

それだ。

こちらを参照してください： http://nixcraft.com/databases-servers/14260-error-1-hy000-cant-create-write-file-tmp-sql_9f3_0-myi-errcode-13-a.html =

http://smashingweb.info/solved-mysql-tmp-error-cant-createwrite-to-file-tmpmykbo3bl-errcode-13/

5
Ranjith Siji

非常に簡単です。/tmpフォルダーに777権限として付与するだけです。入力するだけ：

chmod -R 777 /tmp
3
Ken Yang

Debian 7.5では、同じエラーが発生しました。 /tmpフォルダーの所有者とアクセス許可がオフになっていることに気付きました。別の答えが示唆したように、私は次のようにしました（ルートでなければなりません）：

chown root:root /tmp && chmod 1777 /tmp

Mysqlデーモンを再起動する必要さえありませんでした。

2
Abner

Ubuntuボックスでは、/ tmpを別のボリューム（シンボリックリンク）に移動した後にこのエラーが発生し始めました。必要な許可1777を設定した後でも、問題は解決しませんでした。

MySQLは、新しいtmpの場所/ mnt/tmpへの書き込みを許可していなかったAppArmorによって保護されています。これを修正するには、/ etc/apparmor.d/abstractions/user-tmpに次の行を追加する必要がありました

所有者/ mnt/tmp/** rwkl、

/ mnt/tmp/rw、

2
krishnakumarp

特にSELinuxが有効になっている場合、アクセス制御セキュリティポリシーにより、外部の実行可能ファイルがシステムの場所に一時ファイルを作成することを許可しません。

以下のコマンドを発行して、SELinuxを無効にします。

echo 0>/selinux/enforce

Mysqlを起動して、/ tmpまたはシステムディレクトリの読み取り/書き込み中にエラーに関連する許可を与えることはありません。

SELinuxセキュリティを有効にする場合は、上記のコマンドで0から1に変更します。

1
Shoaib Khan

パーミッションの問題、mysql configを確認してください。

また、ディスク容量、クォータ制限に達していないかどうかも確認してください。

注：一部のシステムは（スペースだけでなく）ファイル数を制限しているため、古いセッションファイルをいくつか削除することで問題を解決できました。

0
takeshin

私はmariadbを使用しています。この行を/etc/my.cnfに配置しようとすると：

[mysqld]
tmpdir=/tmp

/ tmpに関連するWebサイトのフロントエンドから生成されるエラーを解決しました。ただし、/ tmpにバックエンドの問題があります。たとえば、バックエンドからmariadbを再構築しようとすると、/ tmpディレクトリを読み取れず、同様のエラーが生成されました。

mysqldump: Couldn't execute 'show fields from `wp_autoupdate`': Can't create/write to file '/tmp/#sql_1680_0.MAI' (Errcode: 2 "No such file or directory") (1)

したがって、これはフロントエンドとバックエンドの両方で機能します：

1。mkdir/var/lib/mysql/tmp

2。chmod mysql：mysql/var/lib/mysql/tmp

。[mysqld]セクションに次の行を追加します：

    tmpdir = /var/lib/mysql/tmp

4。mysqldを再起動します（例：Centos7：systemctl restart mysqld）

0
MaXi32