この記事を読むのに必要な時間は約 9 分です。
Diskの追加を行います。
まず今を知る
作業前に今の状態を確認します。
df-k
parted -l
ls -l /dev/oracle*
ボリュームを作成する
ブロックストレージから適当に作成する。
ここでの適当は適当な大きさという意味です。
テスト的に作るのであればデフォルトの50はやめて、カスタムで50以上にした方が良いです。
初期ディスクサイズと同じだと何かとわかりずらいためです。
20秒ぐらいで作成が完了します。
作成されたディスクをクリックしてアタッチしていきます。
アタッチメントタイプを選ぶことができます。
- iscsi
- 準仮想化
業務で利用するわけでもないので準仮想化にします。※少しでも簡単に
デバイスパスのオプションですが、これもテスト的な位置づけとして適当なわかりやすい物に変えておきます。
状態を確認する。
どのように変わったのかを確認します。
df -h
↓
※変化無し
parted -l
↓
※変化あり
ls -l /dev/oracle*
↓
※変化あり
OSとしてディスクが追加された状態ですが、df -h で見れないように、ファイルシステムが存在しないからです。
買ってきたばっかりの内臓HDDをWindowsパソコンの本体に接続して、コンパネからディスクの状態を確認する状態と一緒ですね。
それではファイルシステムを作ってみたいと思います。
ファイルシステム作成
parted -lの結果より、追加されたディスクはsdaだとわかりました。※このために60GBにしました。
それでは、ここにファイルシステムを作っていきたいと思います。
fdisk /dev/sda
変更はメモリだけだよー みたいな感じですね。
mでマニュアルを見てみます。
pで現在の編集対象の情報を見てみます。
ディスクサイズが60GBですので一安心ですね。
n で新しいパーティションを追加します。
p でプライマリーを選びます。
１を選びます。ここいらの考え方はWindowsと一緒ですね。
ファーストセレクターはよくわからないのでデフォルト値です。
ラストセレクターもよくわからないのでデフォルト値です。
これで、メモリ上は完成しました！！
この状態で・・・
マニュアル通り w で書き込みです。
状態を確認する。パート３
どのように変わったのかを確認します。
df -h
↓
↓
※変化無し
parted -l
↓
↓
※変化あり
ls -l /dev/oracle*
↓
↓
※変化あり
少しずつ仕上がってきましたね。
USBメモリをさしたが、フォーマットが壊れている状態で、ドライブは見えるけど中身にアクセスできない状態と同じですね。
フォーマットする
mkfs.ext4 でフォーマットします。いつの間にか ext3の次が出てました。
因みに2022年現在ではext3は使ってはいけないコマンドですね。※あと10数年で・・・・
３０秒ぐらいで完了しました。
ディスクのUUIDを調べます。
blkid /dev/sda1
more コマンドで /etc/fstabを開き、Exampleをメモ帳などにコピーしてUUIDを調べたものに書換えて、最後に挿入します。
例通りに実施すると /data1 になりますが、今回はOCI側で tekito としたので tekitoフォルダを作ってみたいと思います。
mkdir /tekito
vi /etc/fstab でファイルを開いて一番下まで移動＋挿入して 書き込み終了
ここまで終わって後はインスタンスの再起動です。
状態を確認する。パート４
どのように変わったのかを確認します。
df -h
↓
↓
↓
※やっとできた・・・
parted -l
↓
↓
↓
※もうパーティションの話はない。
ls -l /dev/oracle*
↓
↓
↓
※ファイルとしても変化無し
少しずつ仕上がってきましたね。
USBメモリを右クリックしてフォーマットした状態ですね。
いやー
めんどくさい・・・・・
適当なフォルダを作ってファイルを作ってみました。
この状態で、OCI側からボリュームをデタッチしてみたいと思います。
くだらない実験ですが、pwdで、まだデタッチ後も、まだ、同じ場所にいることになっていました・・・
ファイルの作成はさすがに失敗してくれました。
このデタッチした状態で、ボリュームのバックアップを取得します。
３０秒ぐらいで完了しましたが、1kbも無いであろう状態ですが、２GB確り取られました。
それでは再度アタッチしてみます。設定は以前と同じです。
設定を同じにしたからと言って、そのままではやはりNGでした。
しかし、一度 / まで戻ってみてみると・・・
正しく認識されているようです。
それではと移動してみましたが、 IOエラーがでます。
パーティション情報を見ると、 /dev/sdc になっています。
これが原因ですね。
uuidを調べてみると同じ値が入っていましたのでfstabの書き換えとかもなく、再起動だけで元通りに動きそうです。
その前に、アンマウントしてみると・・・怒られます。
障害発生想定でいろいろ試してみましたが、ここぐらいにしておきましょう。
↓
reboot
切り離していた状態が元通りになり、 file.txtが見えるようになりました。
データ領域もバックアップから戻してみる。
ここまで来たら、せっかくなのでバックアップからの戻しを試してみたいと思います。
file.txtを削除してみます。
ディスクをOCI側からデタッチします。
ブートボリュームの時と同じく、取得したバックアップを戻してみます。
おっと、サイズオーバーの用です。 60GBではなく50GBなら行けたと思います。
仕方ないので、先ほどまで利用していたボリュームを削除します。
この tekito ですね。
削除して容量を空けます。
改めて、バックアップから戻します。
ブロックボリュームが利用可能になりました。
改めて・・と言っても、このボリュームとしては初めてですが、インスタンスに戻して（くっつけてみます。）みます。
アタッチが終わったのでlsをたたいてみますが、怒られます。
パーティション情報を見てみると sdc で先ほどと同じです。
なので、初回、 a->ｃに変わったことが原因だったと思いますが、どうやら関係ないようですね。
rebootです。
↓
再起動後、/tekitoを覗いてみると正しく 削除したはずのfile1.txtが残っていました。
ここまでやれば、障害発生時でも一安心ですね！
