破損データや整合性のとれないデータがターゲットへ複製されるのを防ぐため、LifeKeeper は、データ複製の前に、リソースが In Serviceになるまで待機します。v9.5.2 からはデフォルトでLifeKeeper は、データの複製前にアプリケーションタイプ ‘filesys’ の親リソースが In Service になるのを待ちます。 これにより、データの複製前に、ファイルシステムの正確性が保証されます。ファイルシステムのマウントに失敗した場合は、適切なリカバリー対応として、データが複製される前にカレントシステムのファイルシステムを修復するか、別のシステムのデータを確認してください。
［Wait to Resync］機能は、 /etc/default/LifeKeeper の “LKDR_WAIT_TO_RESYNC” で設定可能です。 ［Wait to Resync］ 機能を設定するにあたり 3 つのオプションがあります。:
- False ［Wait to Resync］ 機能を無効にします。再同期前に親リソースは確認されません。再同期は、他に障害となる問題がなければ DataKeeper リソースの初期のリストア中に開始されます。
- <resource type> 特定のリソースタイプを指定してください。デフォルトでは ‘filesys’ が指定されています。インストールされている任意のリソースタイプが選択可能です。 ‘/opt/LifeKeeper/bin/typ_list -f:’ コマンドを実行することで、インストールされたリソースタイプの一覧を確認することができます。このコマンドのアウトプットは “アプリケーション:タイプ”の形式で表示されます。
以下例です。
最初の項目はアプリケーションで、 “:” に続く2番目の項目はタイプになります。例えば、上記の [gen:app] の “gen” の部分がアプリケーションで “app” の部分がタイプになります。 “:” の右側はどのタイプでも指定が可能です。LifeKeeper は指定したタイプのDataKeeper リソースの親が In Service になるまで再同期を開始しません。例えば、/etc/default/LifeKeeper でリソースタイプ “LKDR_WAIT_TO_RESYNC=app”が定義されていて、リソース階層が下記のようになっていると仮定します。
app1、app2、app3 がリソースタイプ “app” をもっています。この場合、netraid リソース “datarep-maxdb1” は、3つ全ての gen:app となる親リソースが In Service になるまで同期を実施しません。netraid リソース “datarep-maxdb2”は、 “app1” のみがgen:app となる親なので、 “app1” が In Service になるまでは同期しません。
- Hierarchy 同期前にDataKeeper リソースの の全ての親リソースが In Service になる必要があります。
ユーザーはこの機能の情報を3つの方法で確認することができます。:
- 要求された親リソースが Out of Service の場合は、GUI がターゲットを ［Wait to Resync］ と表示します。:
- 要求された親リソースが Out of Service の場合は、In Service 処理の間に警告メッセージがログに記録されます。このメッセージは、確認中のタイプを指定し、 “LKDR_WAIT_TO_RESYNC=hierarchy” となっている場合に、確認中の全ての階層を指定します。
a. LKDR_WAIT_TO_RESYNC=filesys となっている場合の In Service 処理中に表示されるログメッセージの例です。:
b. LKDR_WAIT_TO_RESYNC=hierarchy となっている場合のログファイルの中のログメッセージです。:
WARN:dr:recover:datarep-maxdb:104237:Mirror “datarep-maxdb” will wait to reconnect targets until parent file system “/maxdb” is in-service. To reconnect targets immediately run: “/opt/LifeKeeper/bin/mirror_action datarep-maxdb resume” on “ip-10-0-2-128” (see “LKDR_WAIT_FOR_FILE_SYSTEM_TO_MOUNT” in /etc/default/LifeKeeper).
- 要求された親リソースが 障害ステータス (OSF) の場合は、エマージェンシーメッセージが LifeKeeper ログファイルと全てのオープンしているターミナルに記録されます。
a. この場合、GUI は［Wait to Resync］ステータスを表示します。
b. 以下のメッセージが全てのターミナルと LifeKeeper ログファイルに記録されます。:
recover[26796]: EMERG:dr:recover:datarep-maxdb:104236:Resource “/maxdb” is “OSF”. The mirror “datarep-maxdb” will wait to reconnect targets until parent file system “/maxdb” is in-service. This may indicate inconsistent data. Do not bring the resource “/maxdb” in-service until the data has been verified; replication will continue when “/maxdb” is in-service. A full resync may be necessary (see “LKDR_WAIT_FOR_FILE_SYSTEM_TO_MOUNT” in /etc/default/LifeKeeper).
c. ファイルシステムのデータが検証されるまで、ファイルシステムリソースを In Service にしないでください。一旦ファイルシステムリソースが In Service になると、次の DataKeeper リソースに対する quickCheck のサイクル中に複製が再開されます。
d. 障害の発生したファイルシステムリソースは、マウント、ログの再生、fsck がファイルシステムを修復できないことを示します。これは、別のノードでファイルシステムを In Service にすることができた場合、ディスク上のデータ不整合を示している可能性があります。ファイルシステムを障害が発生したノードでリカバリーもしくは別のノードへの切り替えのどちらかの方法にて修復できたら、全てのノードのデータの一貫性を保つため、全同期が必要となります。
e. ファイルシステムがマウントできることおよびデータが検証されたことを確認するため、ミラーがターゲットにマウントされます。 これは [Pause Mirror] の機能を使用して実行可能です。
ミラーが一時停止されている際、LifeKeeper は自動的にファイルシステムをターゲットにマウントします。この処理に成功したら、データの整合性を確認してください。ターゲット側(一時停止されているサーバー)で [Force Mirror Online] を選択すると、ミラーを強制的にオンラインにすることができます。 警告: この処理は、親リソースが In Service になっていない場合であっても複製を再開します。データが検証済みの場合にのみミラーを強制的にオンラインにしてください。
データに全く問題ないことが確認できるまでは、ターゲット側の［Resume Replication］を選択 しないでください 。ミラーを一時停止した後に［Resume Replication］を選択すると、親リソースが In Service になっていない場合や、障害が発生した場合であっても、複製が開始されます。
f. データが検証され、親リソースの障害も修正され In Service になったら、DataKeeper リソースに対する次の quickCheck サイクルが、これ以上データの再同期を待つ必要がないことを検知します。親リソースが In Service であったとしても、［Wait to Resync］が表示される quickCheck サイクルまでに数分 (デフォルトで最大２分) 要します。
g. データの破損 (例：ファイルシステムを一つのノードにマウントできるが、別のノードにはマウントできないなど) が発見された場合や、破損が疑わしい場合は、全同期を実施することを提案します。全同期を強制的に実施するため、ミラーはまず最初に一時停止される必要があります。ミラーが一時停止されたら、ソースシステムで以下のコマンドを実行してください。:
/opt/LifeKeeper/bin/mirror_action <tag> fullresync
このトピックへフィードバック