SSDに関する検証 その１２
＜緊急特集！！SSDに関する検証 その１２＞
ペンネーム： ミラニスタ
磁気ディスクの代わりに半導体メモリにデータを記録するストレージ装置
SSD (Solid State Disk) の検証を行っています。
検証製品（富士ゼロックス株式会社様製 GigaExpress）の紹介URL⇒
http://www.fujixerox.co.jp/product/gigaexpress/
▼ 前回のおさらい
mdadm でアレイを組んだ（2台の）SSD（サーバからは /dev/md0 という１つ
のマウント先として認識されます。）に UNDO および REDO を配置し、更新処
理中に片側 SSD の電源を OFF/ON としてみました。
電源瞬断という SSD にとっては、データ損失を伴う致命的な障害が発生し
たにも関わらず、更新処理は無事に終了しました。
ただし、障害が発生した側の SSD は読み書きができない状態となっている
ため、このままでは正常なもう片方に障害が発生してしまうと、データベース
は壊れてしまいます。
▼ リカバリする
1. 状況の確認
# mdadm -D /dev/md0
/dev/md0:
Version : 00.90.01
Creation Time : Mon Aug xx 19:47:57 2007
Raid Level : raid1
.......................................................
Update Time : Mon Aug xx 20:21:03 2007
State : clean, degraded
.......................................................
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 0 0 -1 removed
2 8 33 -1 faulty /dev/sdc1
UUID : 8e4a1ad0:0c3dfcc2:e99566ab:6c8684d2
Events : 0.2624
この状況で、fdisk コマンドで /dev/sdc に対してパーティション操作を行
うことができるかどうか確認してみます。
# fdisk /dev/sdc /dev/sdc を読めません
どうやら、サーバがデバイス自体を認識していないようです。
さて、どうやって認識させればよいのでしょうか？
実は GigaExpress は、｢ホット・プラグ｣あるいは｢ホット・スワップ｣に対
応していません。
従って、再認識させるためにはサーバのリブートが必要です。
2. インスタンスの停止
しかし、Oracleは今動いている状態ですから、normal か immediate で一旦
停止させましょう。
SQL> shutdown immediate データベースがクローズされました。 データベースがディスマウントされました。 ORACLEインスタンスがシャットダウンされました。
3. ファイルのバックアップ
また、念のためアレイに置いてあるファイルのバックアップを取っておきま
しょう。
$ df -k Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/md0 16255800 1247708 14182348 9% /oracle/app/oracle/oradata/ssd $ cd /oracle/app/oracle/oradata/ssd $ ls -l 合計 1203392 -rw-r----- 1 oracle oinstall 52429312 9月 x 19:30 redo04.log -rw-r----- 1 oracle oinstall 52429312 9月 x 19:30 redo05.log -rw-r----- 1 oracle oinstall 52429312 9月 x 19:54 redo06.log -rw-r----- 1 oracle oinstall 1073750016 9月 x 19:54 undo_ssd01.dbf $ cp -p * /var/backup
4. サーバのリブート
これでやっとサーバのリブートができます。
# sync # sync # sync # shutdown -r now
このまま、サーバが無事再起動してくるのを待ちましょう。
5. パーティションの作成
リブートによって、/dev/sdc が認識されるようになったので、fdisk コマ
ンドでパーティションを作成します。
# /sbin/fdisk /dev/sdc
......................................
コマンド (m でヘルプ): n
コマンドアクション
e 拡張
p 基本領域 (1-4)
p
領域番号 (1-4): 1
最初 シリンダ (1-16128, 初期値 1):
初期値 1 を使います
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-16128, 初期値 16128):
初期値 16128 を使います
コマンド (m でヘルプ): w
領域テーブルは交換されました！
ioctl() を呼び出して領域テーブルを再読込みします。
ディスクを同期させます。
作成したパーティションの状況を確認します。
# fdisk -l
.............................................................
Disk /dev/sdb: 16.9 GB, 16911433728 bytes
64 heads, 32 sectors/track, 16128 cylinders
Units = シリンダ数 of 2048 * 512 = 1048576 bytes
デバイス Boot Start End Blocks Id System
/dev/sdb1 1 16128 16515056 83 Linux
Disk /dev/sdc: 16.9 GB, 16911433728 bytes
64 heads, 32 sectors/track, 16128 cylinders
Units = シリンダ数 of 2048 * 512 = 1048576 bytes
デバイス Boot Start End Blocks Id System
/dev/sdc1 1 16128 16515056 83 Linux
6. アレイの再作成
# mdadm --create /dev/md0 --level=raid1 --raid-devices=2 /dev/sdb1 /dev/sdc1
mdadm: /dev/sdc1 appears to contain an ext2fs file system
size=16514944K mtime=Mon Sep XX 20:58:09 2007
mdadm: /dev/sdc1 appears to be part of a raid array:
level=1 devices=2 ctime=Mon Sep XX 20:56:15 2007
Continue creating array? yes ←入力
mdadm: array /dev/md0 started.
# mdadm -D /dev/md0
/dev/md0:
Version : 00.90.01
Creation Time : Mon Sep xx 20:58:09 2007
Raid Level : raid1
Array Size : 16514944 (15.75 GiB 16.91 GB)
Device Size : 16514944 (15.75 GiB 16.91 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Sep xx 20:58:09 2007
State : clean, recovering
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Rebuild Status : 48% complete
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
UUID : e6ce2ba3:c8b4edfc:5b6bcf3d:0498d181
Events : 0.1
最終的に「State : clean」を確認
7. アレイのマウント
再作成したアレイを元のようにマウントします。
# mount /dev/md0 /oracle/app/oracle/oradata/ssd
マウントしたら、ファイルが存在しているか確認します。
# cd /oracle/app/oracle/oradata/ssd # ls -l 合計 1203392 -rw-r----- 1 oracle oinstall 52429312 9月 x 19:30 redo04.log -rw-r----- 1 oracle oinstall 52429312 9月 x 19:30 redo05.log -rw-r----- 1 oracle oinstall 52429312 9月 x 19:54 redo06.log -rw-r----- 1 oracle oinstall 1073750016 9月 x 19:54 undo_ssd01.dbf
何度も確認をしましたが、片方の SSD が故障しただけの状態では、生き
残ったほうの SSD にはデータはまだ存在しています。（電源が入っていれば）
従って、6. で再度アレイを組むと、復活したデバイス（/dev/sdc）への同
期が始まり、最終的にミラーリングが完成します。
念には念を入れ、3. でバックアップを取得しましたが、実際にファイルが
壊れてしまってバックアップから戻さなければならないようなことは（検証し
ている中では）発生しませんでした。
8. インスタンス再起動
$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 – Production on 月 9月 xx 21:04:44 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
アイドル・インスタンスに接続しました。
SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 536870912 bytes
Fixed Size 1220408 bytes
Variable Size 113246408 bytes
Database Buffers 415236096 bytes
Redo Buffers 7168000 bytes
データベースがマウントされました。
データベースがオープンされました。
[/bash]
これで、リカバリの完了です！！
▼ まとめ
2台の SSD でアレイを組んでいる状態での、障害発生からのリカバリ要領を
おさらいしておきます。
1. 状況の確認
どちらの SSD に障害が起きているのかを見極めます。間違って正常な方を
操作してしまうと取り返しのつかないことになります。
正常な SSD は電源がある限り、データを保持しています。
2. インスタンスの停止
サーバをリブートする前に、インスタンスを正常に停止させます。
3. ファイルのバックアップ
念のため、アレイ上のファイルのバックアップを取っておきましょう。
（オフラインバックアップ）
4. サーバのリブート
SSD を再認識させるために、サーバのリブートを行います。
5. パーティションの作成
アレイを組む前に、パーティションを作成します。
6. アレイの再作成
アレイを再構成することにより、2台の SSD を同期させます。
7. アレイのマウント
復活させたアレイをマウントし、インスタンスの再起動に備えます。
8. インスタンス再起動
インスタンスの再起動に成功すれば、リカバリは完了です。
いかがでしょうか。万一 SSD が故障したとしても、落ち着いて対応すれば
データを消失することなく、システムを復旧させることができます。
実際は、一連の操作をスクリプト化しておけば、オペレーションミスも防ぐ
ことができるでしょう。
ところで、GigaExpress がホットプラグ対応であれば、上記 2 と 4 の手順
は不要になります。つまり、サービスを停止することなく復旧が可能になりま
す。
富士ゼロックス様にこの点を確認したところ、技術的には可能なので次期リ
リース製品はホットプラグ対応になるとのことでした。
今回で SSD に関する検証を終える予定でしたが、全体のまとめをすること
ができませんでしたので、次回を本当の最終回としたいと思います。
FIFAクラブワールドカップ ジャパン 2007のＡ.Ｃ.ミラン戦、チケット買っ
ちゃいました！ ボス、12月13日は休ませていただきます！！
台風は大変でした！の 茅ヶ崎にて