さくらVPSでスケールアップをして公式の通りにディスク容量の拡張を行ってみたが、成功しているかどうかが分からない。

Question

さくらVPS 1Gプランから4Gプランへ、スケールアップを申し込みました。
CPUですとかメモリとかそういうのは良いとして、
今回SSDが
ちゃんとディスクの領域が広がっているのかどうか。使えているのかどうか。
が不安な状態ですので、問題なく今後も使えたらよいのですが疑念を晴らしたくこちらへ伺いました。

一応の所成功していると思うのですが、
成功とはどういうことなのか。

スケールアップ後のディスクにデータがどんどん保存されるのか？
スケールアップ前に使用していたディスクが100%になったら自動で
スケールアップ後も1％から使用が開始されるのか？
現在すでに、スケールアップ後のディスクがメインとして書き込まれているのか？

自分が一番心配しているのが
新しくディスクを作成するコマンドはしてみたが、マウントやらなにやらで、しっかりとやりきらずに、

このまま使用を続けると既存のディスクが100%となり、エラーというか停止してしまうことなのですが、
ちゃんと新しいディスクが問題なく使えるとよいのですが、お教えいただきたく思います。

今、以下のような画面でディスクの状態がでます。

＜centos df コマンド実行＞
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda4 26273556 20995372 3924452 85% /
devtmpfs 2012012 0 2012012 0% /dev
tmpfs 2022532 0 2022532 0% /dev/shm
tmpfs 2022532 8684 2013848 1% /run
tmpfs 2022532 0 2022532 0% /sys/fs/cgroup
/dev/vda2 487652 133261 324695 30% /boot
/dev/vda5 175323868 61464 166333128 1% /data
tmpfs 404508 0 404508 0% /run/user/1000

↑上記は実際今コピーした数値です。

vda4というのが今まで使用していたもので、今回vda5というものを広げてみた、ところです。
ここはvda4が一度いっぱいになって、エラーのようになってmariaDBがソケットエラーうんぬんと、
一度停止状態に近いことが起きたので、
次はなるべくトラブル状態が起きないことを願っています。

で、今dfコマンドを打ったとします。
上記の３０秒後にでも打つと
vda4のusedが増えているのです。
vda5は値が全くかわっていません。

自分はmysqlであれなんであれ、　いっぱいになって停止という状態が怖いので、今回拡張をしたのですが、
あのvda4 のUse85%はこのまま増えていって100%になってもらって、停止状態、等に至るのが嫌なのですが、

今回私が作成したvda5はちゃんと、約170GB分データを保存して活躍してくれるのでしょうか？
すみません宜しくお願いします・・・

Answer 1

一応の所成功していると思うのですが、
成功とはどういうことなのか。

さくらのVPS ディスク拡張手順 (標準OS CentOS7.2) の手順の「成功」という話であれば、最後に

df コマンドなどで作成した領域がマウントされていることを確認できれば、作業完了です。

とありますので、ディスクが OS に認識されることでしょう。

スケールアップ後のディスクにデータがどんどん保存されるのか？
スケールアップ前に使用していたディスクが100%になったら自動で
スケールアップ後も1％から使用が開始されるのか？
現在すでに、スケールアップ後のディスクがメインとして書き込まれているのか？

おそらく、いいえ。

vda4というのが今まで使用していたもので、今回vda5というものを広げてみた、ところです。

ここはvda4が一度いっぱいになって、エラーのようになってmariaDBがソケットエラーうんぬんと、
一度停止状態に近いことが起きたので、
次はなるべくトラブル状態が起きないことを願っています。

ということであれば、

vda4 ( / ) のどのディレクトリの容量がいっぱいになったかによります。

/data が100%を超えたので、 /data に /dev/vda5 をマウントしたということであれば、/data に保存されていたデータは、今後は vda5 に書き込まれますがいっぱいになったのが /data ではない場合は、どこがいっぱいかを調べて、そのディレクトに対して「新しいディスクをマウントする」の操作をする必要があります。

で、今dfコマンドを打ったとします。
上記の３０秒後にでも打つと
vda4のusedが増えているのです。
vda5は値が全くかわっていません。

自分はmysqlであれなんであれ、　いっぱいになって停止という状態が怖いので、今回拡張をしたのですが、
あのvda4 のUse85%はこのまま増えていって100%になってもらって、停止状態、等に至るのが嫌なのですが、

今回私が作成したvda5はちゃんと、約170GB分データを保存して活躍してくれるのでしょうか？
すみません宜しくお願いします・・・

いいえ。

現在の状態では、新しい vda5 ( /data )は使われずに vda4 ( / )がいっぱいになると思います。

まずは、vda4 ( / ) の中で、どのディレクトリがいっぱいになったのかを調べることから始めてください。

データが増えているディレクトリが判明したらそのディレクトリに対して、 vda5 を割り当てるようにしてください。(マウントする前にデータのコピーをしておきましょう。)

Comments

[gugupoo]

有難うございました！ようやく理解しつつあります！

別の問題が生じまして、それは今回の必要以上に肥大化したものは何かということで
今回の肥大化は　

/var/lib/mysql/ 　　の、　ibdata1　ファイル。これが18GBでした。
（これをうまく容量を削除といいますか、減らすために、mysqlをdumpしてしっかり戻すというそこはおいておいて）

で、　そもそも私は、
こういったcentosやVPS操作や、考え方を幾分理解せずままある程度進めていることは自分でもわかっているのですが、それでも勉強中・修行中ということで、最低限の知識も伸ばしつつ、
セキュリティーにも強くなりつつ、
現状色々理解不足なのは申し訳ございません）

で！、　　
/dev/vda5 175323868 61464 166333128 1% /data
↑こういう部分も、　いわゆるマウントするということすら、
自分の言葉に置き換えて理解しているレベルでなく、ネット上の知識をコピペしてやっていることは
よくわかっていたつもりです。
で、

-----------------------------
その１　
/dev/vda5 175323868 61464 166333128 1% /data
これは　/data ディレクトリのものは　今後はvda5に書き込まれるもの、ということでよいでしょうか？

その２　
であるならば　/var ディレクトリをマウントしたほうがよく
mount /dev/vda5 /var
とするのが今回肥大化するデータの逃げ先確保という意味で一番良いでしょうか？

その３
その2が大筋正解であった場合、　決して/var以下でなく、
当然全てのディレクトリを /dev/vda5 でマウントするのもよいと思うのですが
現在は　vda4 が　dev/vda4 26273556 20995372 3924452 85% /　　で、全てのディレクトリをマウントしていると思いますが、
mount /dev/vda5 / ←これで/ディレクトリのマウントへと切り替わりますか？

その4
いついつくらいまでのデータが　vda4　にある
いつくらいまでのデータが　vda5　　にある

という概念と思いますが、　いつかもっと時間があるときなどに、

全てのデータがvda10に100Gであります！！
など気持ちよく表現したいものですが、
いつか、　vda4、vda5 vda6 ..　などを　vda10に
改めてまとめる、など出来るのでしょうか？！
色々理解しておらず申し訳ありません…

[CHERRY]

> その１　
> /dev/vda5 175323868 61464 166333128 1% /data
> これは　/data ディレクトリのものは　今後はvda5に書き込まれるもの、ということでよいでしょうか？

はい。

> その２　
> であるならば　/var ディレクトリをマウントしたほうがよく
> mount /dev/vda5 /var
> とするのが今回肥大化するデータの逃げ先確保という意味で一番良いでしょうか？

MySQL だけであれば、 /var/lib/mysql/ だけで良いかもしれませんね。

注意点としては、/var に vda5 をマウントすると元々のデータ( vda4 の /var )は見えなくなるので、最初に今のデータ( vda4 の /var )をマウントするディスク( vda5 )にコピーしておく必要があります。

> その３
> その2が大筋正解であった場合、　決して/var以下でなく、
> 当然全てのディレクトリを /dev/vda5 でマウントするのもよいと思うのですが
> 現在は　vda4 が　dev/vda4 26273556 20995372 3924452 85% /　　で、全てのディレクトリをマウントしていると思いま> すが、
> mount /dev/vda5 / ←これで/ディレクトリのマウントへと切り替わりますか？

切り替えれなくはないですが、/dev/vda5 の中身がない「空」の状態で、 mount (貼り付け)すると なにもない真っ白な状態になります。

mount コマンドでのマウントは、「今まで、いっぱい記録したノートの一部に『はがせるのり』で、別の紙を貼り付けた状態」と例えるとわかりやすいでしょうか。

umount コマンドで vda5 のマウントを解除 (たとえ話の「別の紙」を剥がす)すると もともとの vda4 の / の内容(ノートの記録内容)が残っています。

> その4
> いついつくらいまでのデータが　vda4　にある
> いつくらいまでのデータが　vda5　　にある
> という概念と思いますが、　いつかもっと時間があるときなどに、

いいえ。

mount すると mount されたもとのディレクトリのデータは残っていますが、 OS からは参照できません。

その 2 で書かれた ` mount /dev/vda5 /var ` を実行すると `/var` は、 `/dev/vda5` のディスクの内容だけになるので、おそらく「空」の ` /var ` が表示されるだけになります。

` umount /var ` と実行して、 ` /var ` にマウントした ` /dev/vda5 ` を取り除かない限り、 /dev/vda4 のデータは見えません。

> 全てのデータがvda10に100Gであります！！
> など気持ちよく表現したいものですが、
> いつか、　vda4、vda5 vda6 ..　などを　vda10に
> 改めてまとめる、など出来るのでしょうか？！

ディスクとまとめるとなると データを別のところにバックアップして、現在のディスクを初期化・再パーテーションして、OSを再インストールして、データの復元という手順になりますね。

VPSの場合は、

1. もう１台、別のサーバーを借りて新サーバを用意
2. 環境構築
3. データ移行
4. 動作テスト
5. 旧サーバ停止
6. データ移行後に旧サーバに作成・更新されたデータを移行・反映
7. ドメインを切り替えて、新サーバーにアクセスを切り替え
8. 旧サーバにアクセスがないことを確認して停止

とした方が、システムの停止時間が少なくてすむと思います。

[gugupoo]

大変有難うございます。

今現在、　18GB使用してしまっている/var/lib/mysql/　ディレクトリのそのファイルibdata1、
これが原因で今があり、解決の道は２つあると思います。

１、ibdata1ファイルをうまく扱い、もっと小さく扱ってしまい今回のスケールアップや、容量確保のような話はなくす。

２、スケールアップを生かして、とりあえず逃げ場を作る路線

１路線も今実際想定して同時に精読中ではありますが、

>>>MySQL だけであれば、 /var/lib/mysql/ だけで良いかもしれませんね。

>>>注意点としては、マウントするともともとのデータは見えなくなるので、最初に今のデータをマウン>>>トするディスクにコピーしておく必要があります。

これさえすれば、varディレクトリのmysqlがマウントされて、
いわゆる170Gの空いたスペースにvarディレクトリの内容がどんどん保存されていくことになりますか？
＝　肥大化ibdata1ファイルもここに入るので、とりあえず170GB分は生き残ることができる。

３、ibdata1　をうまく取り扱う…　かなり怖いイメージがあるのですが、フルdumpというのをして、再度流し込む‥　　というそこを扱った質問をした場合は、　別途質問を質問するコーナーですればよろしいでしょうか！

[gugupoo]

余談＞＞てっきり、自分はアクセスログ　㏒フォルダがいっぱいになったと思っていました。
VPSサーバーは３回くらい借りたことがあり、継続して勉強中で、cronのログ等々色々で結構すぐたまった記憶がありますが、今回こちらのmysqlのibdata1というファイルは
それよりは遅かったのですが、
一気にログファイルよりも速いスピードで？　一気に肥大化してきた気がします・・

dumpから続けていった形で、　誤って全mysqlデータを削除したり、元にもどれなかったり、
あと今現在も稼働しているサーバーですので
停止時間が短い方が助かると思っています・・

なんとか肥大化をおさえる、　もしくは今回のようなスケールアップなりで逃れる
でないと、　これは一気に本当にいってしまいますよね・・・；；

[CHERRY]

> 今現在、　18GB使用してしまっている/var/lib/mysql/　ディレクトリのそのファイルibdata1、
> これが原因で今があり、解決の道は２つあると思います。

> １、ibdata1ファイルをうまく扱い、もっと小さく扱ってしまい今回のスケールアップや、容量確保のような話はなくす。

ログ的なデータであれば、エクスポートする等で、データの保存期間を短くしたりして、データ容量が減る見込みがあれば、可能かもしれません。

それ以外の場合は、データ構造を見直したり、プログラムの修正も含めて根本的な対策が必要かもしれません。

> ２、スケールアップを生かして、とりあえず逃げ場を作る路線

> これさえすれば、varディレクトリのmysqlがマウントされて、
> いわゆる170Gの空いたスペースにvarディレクトリの内容がどんどん保存されていくことになりますか？
> ＝　肥大化ibdata1ファイルもここに入るので、とりあえず170GB分は生き残ることができる。

既存のファイル等は、自動では入りませんので、

1. サービスを停止して、
2. データのコピー
3. マウント
4. サービスの再開

という手順になると思います。

これさえすれば、varディレクトリのmysqlがマウントされて、
いわゆる170Gの空いたスペースにvarディレクトリの内容がどんどん保存されていくことになりますか？
＝　肥大化ibdata1ファイルもここに入るので、とりあえず170GB分は生き残ることができる。

> ３、ibdata1　をうまく取り扱う…　かなり怖いイメージがあるのですが、フルdumpというのをして、再度流し込む‥　　というそこを扱った質問をした場合は、　別途質問を質問するコーナーですればよろしいでしょうか！

MySQL の話題になりますので、別の質問のほうが良いと思います。

[CHERRY]

MySQL のデータが増加している原因は、何でしょうか？
それを見極めないと際限なく容量を追加することになると思います。

データの INSERT が大量にある？
データ件数は多くないが、データの更新が激しい？

[CHERRY]

上記では、ディスクの容量を増やす方向で回答していますが、

MySQL 的な解決方法としては、

https://dev.mysql.com/doc/refman/5.6/ja/symbolic-links.html
https://dev.mysql.com/doc/refman/5.6/ja/tablespace-placing.html

等の解決方法もあります。

こちらの場合は、マウント場所を変える必要もなく
MySQL のファイルの移動＆リンク作成又は MySQL のコマンドだけで対応できるので、場合によってはこちらのほうが良いかもしれません。

ちょっと古いですが、下記のような手順ですね。

http://code.zobe.jp/2012/09/decentralized_placement_per_database_about_mysql/

[gugupoo]

有難うございます！

>>データの INSERT が大量にある？
>>データ件数は多くないが、データの更新が激しい？

有難うございます！上記は、
INSERTは大量にあります。SELECTもUPDATEも大量にあるかとおもいます…。
そもそも前プランでも何の連絡も、当方から他のVPS利用者皆様へトラブルをかけたこともございません。ただ自分自身で、ファイルを圧迫していてはまずい…この再CPU メモリ　ディスク、　全部スケールアップとのことなので、必要なくてもサーバー会社さんに資金がいくのは良いことなので先んじてスケールアップしたつもりです。

ただ、INSERT UPDATE SELECT　結構ありまして…　cronも結構回します…　ネットワーク上ではあらゆる皆様に迷惑がかからないように本当に心がけております！！

で、今さらに私CHERRY様お教えいただいたものと別で
https://onoredekaiketsu.com/extend-partition-after-increasing-storage-capacity-with-sakura-vps/
こちら様のような、　vda4を拡張するというようなものがよいのであろうかと発見して、
こちらをやるとしたら、自己責任でやってみようと思っています。しかし…

とりあえず多くをさらにお伺いしたいところでありますが、
一旦、vda4の拡張のこれを読んでみて、いけそうでしたら試してみたいと思います。

このvda5 等々の実用化という路線以外の、　このvda4 の拡張路線に関して、
ご感想等あられたら、お待ちしています！
私は、今から2時間以内に上記を読みつつ、実行するときはしようとおもっております！
ここにアドバイス等あられましらた、お待ちいたしております！いったん失礼致します。

[CHERRY]

gdisk でのパーテーション拡張ですか...　

手元の PC では、実行したことありますが、クラウド環境では試したこと無いのでなんとも言えないのですが...
バックアップを取ってから　自己責任で試してみるのはありだと思います。

失敗した際に復旧するまで半日程度はサービスが止まることになると思いますので、ある程度は時間的余裕をみておいたほうが良いかもしれません。

[gugupoo]

いえ！！　CHERRY様から見ての感想といいますか直感のご感想をお伺いしたかったのでそれはまだしません！！
自己責任とは言うものの、危険が少し伴うものを行うつもりはありません。。

そこで；；　本当に情けないですが、お伺いしてよろしいでしょうか；；

1. サービスを停止して、
2. データのコピー
3. マウント
4. サービスの再開

データのコピー
すなわち、私でいう
/var/lib/mysql/ 　を、vda5にコピーするやり方が分からなく、お教え頂けませんでしょうか；申し訳ございません＞＜；至急私も、平行して調べますので！＞＜；

＞＞＞＞＞＞注意点としては、/var に vda5 をマウントすると元々のデータ( vda4 の /var )は見えなく＞＞＞＞＞＞なるので、最初に今のデータ( vda4 の /var )をマウントするディスク( vda5 )にコピーしておく必要があります。
↑ここのことだと思いますが、データのvda5に対するコピーをどうやってやればよいのかを・・＞＜申し訳ございません＞＜　私も調べますので＞＜；；

[gugupoo]

CHERRY様

結局vda４を拡張するという路線で、なんとか成功致しました；！
そこに至るまでは、vda5にしっかりコピーが分からなかったり、
バックアップをしっかりとって、再度データを流しこむ、というようなものをやる
実際のディスク残量の少なさと、私自身の余裕の少なさもあり、
本当にイチかバチかでありましたがディスク拡張をたまたま検索で見つけることができたのも
CHERRY様に物凄く詳しく教えて頂けた結果と思っています。

CHERRY様にマウントからその周辺の事について本当に深く教えて頂けて心より感謝しております。有難うございました。

Answer 2

現状vda5は /data 以下に保存した場合のみ使われるようになってますね。
何かしら自分で保存先を変更するなりなんなりしないと使われませんよ。

Comments

[gugupoo]

有難うございます。

自分が肥大化したデータの、　/var　ディレクトリ　のマウントに今回行った設定をやってやるとすなわち、

mount /dev/vda5 /data
でなく
mount /dev/vda5 /var

のような設定でとりあえず、今回の目標は果たせると思うのですが、

これがもしうまくいったとして、
（データの圧迫、や停止からは逃れる事に成功）
したとして、

データの保存される仕組みというと

あのあたり～～～　までのデータは　vda4にはいっている。

あれ（ mount /dev/vda5 /var ）を設定したあたりからのデータは
vda5 にはいっている、という
何かすごいあいまいなといいますか・・　

このフォルダにはこのファイル！　こっちのフォルダにはこのファイル！
とかそういうすっきりしたものでなく、
２か所に同じディレクトリのものが入っている？？　というような現象と思うのですが、

ファイルの保存とかでなくて、
これが　VPSというものであったり、　イメージ、　マウント、　とか
そういうものの取り扱いは　こういう　vda4 vda5 に分かれて
保存される？ようなそういうものになりうるということでしょうか・・
意味不明なことを書いていて申し訳ございません・・