44

何らかの理由で、私の本番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は稼働しているようで、コンソールを介して照会できますが、アプリケーションはそれを実行できないようです。アプリケーションコード/ファイルに変更はありませんでした。それは突然起こった。そのため、どこから調べ始めればよいのか、どの解決策を適用すればよいのかさえわかりません。何か案は？

4

14 に答える 14

38

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

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

多分これもあなたを助けるでしょう。

  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

于 2012-11-02T16:15:49.933 に答える
21

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

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

于 2012-08-17T00:18:25.983 に答える
16

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

156 129 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によって削除されます。

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

/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

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

于 2013-01-22T09:58:00.260 に答える
14

これについて正しい方向に私を向けてくれた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ディレクトリを削除し、プライベート/ tmpをmysqldで使用できなくし、パブリック/tmpをシステム上の他のすべてで使用できるようにします。

mysqldを再起動すると、手順1ですべてが最初からやり直され、新しいプライベート/tmpディレクトリが作成されるため機能します。ただし、問題は最終的に再び発生します。そしてまた。

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

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

問題が解決しました。

于 2013-03-07T07:14:04.907 に答える
14

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

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

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

私が彼に与えた解決策：

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

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

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

于 2012-11-02T16:55:11.947 に答える
7

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

mysql -u root -p

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

systemctl start mysqld.service

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

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

于 2013-07-19T12:33:54.830 に答える
5

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

    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/

于 2013-04-17T17:54:48.147 に答える
3

非常に簡単です。/tmpフォルダーに777権限を付与するだけです。次のように入力するだけです。

chmod -R 777 /tmp
于 2015-07-15T08:14:08.730 に答える
2

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

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

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

/ mnt / tmp / rw、

于 2015-01-06T05:21:14.320 に答える
2

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

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

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

于 2015-03-28T13:33:35.190 に答える
2

私は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. mysql：mysql / var / lib / mysql/tmpをchownします

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

    tmpdir = /var/lib/mysql/tmp

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

于 2019-08-22T12:56:44.563 に答える
1

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

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

echo 0> / selinux / enforce

これで、mysqlを起動して、/tmpまたはシステムディレクトリの読み取り/書き込み中にエラーに関連する権限を付与しません。

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

于 2014-05-19T20:23:09.673 に答える
0

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

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

注：一部のシステムでは（スペースだけでなく）ファイルの数が制限されています。古いセッションファイルをいくつか削除すると、私の場合の問題を修正するのに役立ちました。

于 2014-07-17T10:18:47.080 に答える
0

VPS/仮想ホスティングを使用している場合。

私はVPSを使用していて、MySQLが/ tmpに書き込めないというエラーが発生し、すべてが正しく見えました。十分な空き領域、十分な空きiノード、正しいアクセス許可がありました。問題は私のVPSの外にあることが判明しました。満杯だったのは、VPSをホストしているマシンでした。ファイルシステムには「仮想空間」しかありませんでしたが、VPSをホストするバックグラウンドのマシンには「物理空間」が残っていませんでした。彼らがそれを修正したなら、私はVPS会社に連絡しなければなりませんでした。

これが問題である可能性があると思われる場合は、より大きなファイルを/ tmp（1GB）に書き込むことをテストできます。

dd if=/dev/zero of=/tmp/file.txt count=1024 bs=1048576

エラーメッセージがNo space left on device表示されました。これは、バックグラウンドでいっぱいになったディスク/ボリュームであるというプレゼントでした。

于 2020-01-22T12:48:37.683 に答える