WordPressを稼働させているAWSでno space left on Deviceのエラーに…
みたら/dev/xvda1が100%になっていた.(dhコマンドで確認)
AWSに移行したばかりで過去のWordPressからインポートしたものが多かった模様.画像がかなり占めている.
これを解消するには幾らか対応が必要.
対応項目は以下
- AWSのコンソールでボリュームのサイズ変更
- sshしてログインして”sudo growpart /dev/xvda 1″ (/dev/xvdaは適宜変更)
- もしこれでno space left on deviceになる場合はなんらかファイル削除
- sudo resize2fs /dev/xvda1
- df -h で確認
AWSでのボリュームサイズ変更
console AWSの設定で、「ボリュームの変更」をアクションから選択します.
このサイズを変更すればOK.
反映に時間がかかるケースもあるみたいだが、私の場合は即反映された.
SSHして残作業
対象のEC2にsshしたら、まず
lsblkでちゃんとサイズが変わっているか確認.
この時点ではシステムは全くその大きさを無視した過去設定で動いているので、
反映させてやる作業がここから必要.
sudo growpart /dev/xvda 1
をまず実行. /dev/xvdaは適宜環境に合わせて変更.
ここで再度”no space left on device”のエラーが出る笑
それを解消するための作業でそれでつまるとは…
色々悩んだが消せるファイルがろくにない…
私の場合は一旦wordpressのコンテンツをローカルにダウンロードして容量を開けて対応する方針とした.
その方針を決めるにあたって、まずは基本の大きなフォルダ/ファイル探しから.
そうすると、WordPreesのwp-contentsが非常に膨れ上がっていることがわかった. なので先ほど述べたように一部画像をローカルに持ってきて、サーバ内で画像を削除して容量を開けた. 35Mのサイズの画像があってそれを一枚削除するだけで、コマンドを打てるようになった!
これでlsblkはちゃんと新しい大きさに変わるはず.
これで growpartを難なく実行できるようになったので次工程へ
sudo resize2fs /dev/xvda1
こちらは問題なく通った.
これで作業完了.
最後に
du -h
で適切に容量が追加されていることを確認.
