14549


MySQLの運用中、Errcode:28で落ちてしまいました。

[code]

    SQLSTATE[HY000]: General error: 3 Error writing file '/tmp/MYfRrHW4' (Errcode: 28)
    
[/code]

下記のperrorコマンドで確認すると容量が無いとのことでしたが

[code]

    [root@ ~]$ perror 28
    OS error code  28:  No space left on device
    
[/code]

df -hを試してみると空き容量は足りているように見えます。

[code]

    /dev/sda1              99M   13M   82M  14% /boot
    tmpfs                 7.9G     0  7.9G   0% /dev/shm
    /dev/sdb1              99G   41G   53G  44% /var/data
    
[/code]

df -iも試してみましたがこちらの空き容量も足りているように見えます。

[code]

    /dev/sda1              26104      34   26070    1% /boot
    tmpfs                2054640       1 2054639    1% /dev/shm
    /dev/sdb1            13107200     250 13106950    1% /var/data
    
[/code]

そこで質問なのですが、errorCode:28の場合  
空き領域が足りない以外で原因は何かありますでしょうか？  
よろしくお願いします。


CC BY-SA 3.0
2015-08-17T09:29:54.613
14522
2015-08-18T11:55:30.157
2015-08-18T11:55:30.157
7918
7918
question
mysql linux
MySQLのErrcode:28について教えてください。


とりあえずお尋ねの点について私が知っていることをお答えすると、  
Quota、limitといったファイル容量制限機構がLinuxにもあり、これらによって該当のエラーが返されることはあります。

だたし、今回の場合本当に領域が足りなかったのだと思います。  
根拠としては、  
まず、プロセスが停止してしまってからディスクを見てどれだけ空いているか計るのは役にたちません。  
Linuxをはじめ多くのUNIX系プログラムでは、一時ファイルを扱う場合、  
生成モードでファイルをopen()し、  
とりあえずunlink()をかけ、  
その後read(),write()をする  
という手順は非常に多く使われています。これでちゃんと動くし、不慮の事故でプロセスが停止しても一時ファイルが残りません。  
MySQLもそうなっているでしょう。止まってしまってから見たディスク領域は停止した瞬間とは違うので役に立ちません。  
もう一つ、質問が事故の起きた日にされたのなら、その日は多くの企業にとって夏休み明けで、平常より処理が多かったでしょう。

総合的にみて、ディスク領域が本当に不足していたと考えるのが妥当です。


CC BY-SA 3.0
2015-08-17T23:08:11.437
14549
2015-08-17T23:08:11.437
8136
14522
answer


> 空き領域が足りない以外で原因は何かありますでしょうか？

ext2のシステムでのことですがファイルシステムが壊れている場合にno space
leftになったことがあります。その時はfsckで直ったような記憶があります。

とはいえ/tmp を使い潰すほどの巨大なテンポラリファイルが作成された可能性が一番高いと思います。

Slowクエリログに出力されていたり、sar に CPU、ディスクなどの負荷が上がった痕跡が残っていないか調べてみてはどうでしょう。


CC BY-SA 3.0
2015-08-18T04:29:24.513
14566
2015-08-18T04:29:24.513
5008
14522
answer