		      ディザスタリカバリについて

● 本ドキュメントについて
====================
本文書は、災害等が発生し、ディザスタリカバリとして遠隔拠点に置かれてい
る非同期スレーブメタデータサーバにフェイルオーバするときの注意点を記載
します。

同期スレーブメタデータサーバへのフェイルオーバについては、フェイルオー
バの文書を参照してください。

以下では、既に災害等によりマスターメタデータサーバが停止し、スレーブメ
タデータサーバは起動していることを想定しています。

● マスターメタデータサーバにアクセス可能な場合
======================================
マスターメタデータサーバのジャーナルファイル、データベースにアクセス可
能な場合は、フェイルオーバの文書の非同期スレーブメタデータサーバへのフェ
イルオーバの手順に進みます。

● マスターメタデータサーバにアクセス不能な場合
======================================
マスターメタデータサーバのジャーナルファイル、データベースにアクセス不
能な場合は、スレーブメタデータサーバは非同期であるため、マスターメタデー
タの更新がまだスレーブに届いていない可能性があります。

その間のメタデータ操作を復旧させることはできませんし、また届いていない
メタデータ操作については、これからマスターへと昇格させるスレーブサーバ
上でのメタデータ更新と矛盾が生じる可能性があります。

このため、マスターメタデータサーバの復旧見込みとデータ操作の必要性に応
じて、以下のいずれかから方針を選びます。

(a) 矛盾を避けるため、マスターメタデータサーバが復旧するまでファイル・
    ディレクトリ更新を禁止する

(b) ある程度の矛盾が生じる点については諦め、失われたメタデータ操作はマ
    スターメタデータサーバが復旧してから確認することとし、ファイル・ディ
    レクトリ更新を禁止しない

マスターメタデータサーバのディスク装置が復旧したときに備えて、スレーブ
メタデータサーバのジャーナルファイルのシーケンス番号を記録します。
(スレーブ)
# gfjournal -m 0000000000.gmj
1234567890

あとで必要となった場合に状況を解析できるようにするためにスレーブメタデー
タサーバのジャーナルファイルをコピーしてバックアップしておきます。
(スレーブ)
# cp -p 0000000000.gmj 0000000000.gmj.bak

同様に、スレーブメタデータサーバのバックエンドDBもバックアップしておき
ます。
(スレーブ)
# gfdump.postgresql -d -f - | gzip > dump.gz

方針 (a) を選んだ場合には、ユーザにファイルやディレクトリの変更作業を行
わないよう周知を行います。

スレーブメタデータサーバをマスターに昇格させます。
(スレーブ)
# pkill -USR1 gfmd

これで昇格した新メタデータサーバが利用可能になりました。

スレーブメタデータサーバが一台少なくなっていますので、別サーバでいちか
らスレーブメタデータサーバの設定を行います。

● マスターメタデータサーバが復旧したときの手順
=====================================
旧マスターメタデータサーバのディスク装置が復旧した場合、復旧したジャー
ナルファイルの内容を確認し、スレーブをマスターに昇格させる前に記録した
シーケンス番号以降、どのような更新が旧マスターメタデータサーバ側で起き
ていたかを確認します。
(旧マスター)
# gfjournal -l 0000000000.gmj | less

更新が行われていない場合は、同期が完全に行われていたということですので、
何の問題もありません。

更新が行われていた場合は、その更新操作は失われています。復旧手順として
は以下が考えられます。

(a) ファイルやディレクトリの更新を行っていない場合
-----------------------------------------
新マスターでユーザーがファイルやディレクトリに関する更新操作を行ってい
るかどうか、シーケンス番号以降の操作を gfjournal -l で確認します。

ファイルやディレクトリに対する更新が行われていないのであれば、旧マスター
メタデータサーバのメタデータを用いて復旧します。

旧マスターメタデータサーバのハードウェアが復旧できているのであれば、新
マスターを -S オプションを用いてスレーブとして起動し直し、旧マスターメ
タデータサーバをマスターとして起動して作業完了です。

旧マスターメタデータサーバのハードウェアが復旧できない場合には、新マス
ターメタデータサーバを停止し、旧マスターのバックエンドDBおよびジャーナ
ルファイルを新マスターにコピーし、新マスターメタデータサーバを起動して
ください。このとき、スレーブとして起動しますので、マスターに昇格させて
ください。

どちらの手順でも、旧マスターメタデータサーバと新マスターメタデータサー
バの両方をマスターとして起動することがないように、十分注意して作業する
必要があります。

(b) ファイルやディレクトリの更新が行われている場合
-----------------------------------------
新マスターでファイルやディレクトリの更新が行われている場合は、旧スレー
ブメタデータサーバで記録していたシーケンス番号以降の失われたメタデータ
の更新内容を gfjournal -l で確認します。

失われたメタデータの更新に含まれるファイルについて、ファイルの実体をバッ
クアップし、ユーザに知らせます。

このとき実体ファイルの gfsd のスプールディレクトリからの相対パス名は
gfspoolpath コマンドで以下のように調べることが出来ます。

% gfspoolpath -I inode番号:gen番号

なお、ファイルの実態は、gfsd の再起動などにより、/lost+found へ移動して
いることもあります。その時、ホスト名に格納されていた inode番号、gen番号
のファイルは Gfarm ファイルシステムの以下に移動しています。

% printf "/lost+found/%016X%016X-%s\n" inode番号 gen番号 ホスト名
