問題のサマリー: 停止したクラスタノードが NFS 共有から遮断されたままになり、あとで保護グループがこのノードに切り替わる際に、このノードでの ScalMountPoint rs の起動が失敗します。
回避方法: このノードの共有モードを RW に設定したあと、ScalMountPoint rg を、起動に失敗したノード上で再起動します。
問題のサマリー: 保護グループの外側にあるリソースグループから保護グループの内側にあるリソースグループへの、RG_affinities (++/+++ など) または RG_dependencies が存在していて、かつそれらの外部リソースグループが unmanaged でない場合、保護グループのスイッチオーバーは失敗します。
回避方法: 依存先のリソースグループを管理する保護グループの外側に依存元のリソースグループを配置し続ける必要がある場合は、次のオプションを検討してください。
それらのリソースグループをほかの保護グループ内に配置したあと、それらの保護グループを依存先保護グループと同じマルチグループ内に配置することにより、依存元リソースグループを含む保護グループからこの依存先保護グループへの依存関係が形成されるようにします。スイッチオーバーを起動するには、geopg コマンドで個々の保護グループを指定するのではなく、geomg でマルチグループを指定します。
依存元リソースグループは保護グループの外側に配置したままにしますが、それらのリソースグループを unmanaged の状態に切り替えたあとで、依存先リソースグループを含む保護グループのスイッチオーバーを起動する必要があります。
問題のサマリー: Oracle Solaris Cluster 4.3 から Oracle Solaris Cluster 4.4 へのローリング更新のあと、geopg list および geopg show が Java 例外とともに失敗します。
回避方法: リソース geo-failovercontrol を、Oracle Solaris Cluster 4.3 を実行しているクラスタノードから Oracle Solaris Cluster 4.4 を実行しているノードに切り替えます。
問題のサマリー: 保護グループ内のプロジェクトに含まれるレプリケート済みファイルシステムをエクスポートすると、保護グループのスイッチオーバーが失敗します。また、そのようなファイルシステムがエクスポートされ、そのマウントポイントが変わった場合、マウントポイントが上書きされることになります。
回避方法: レプリケートされたファイルシステムをエクスポートする必要がある場合、それらのエクスポートを停止したあとでスイッチオーバーを行う必要があります。さらに、エクスポートされたレプリケート済みファイルシステムのマウントポイントが変更される場合、それをソースと同じマウントポイントに設定したあとでスイッチオーバーを行う必要があります。
問題のサマリー: クラスタが Oracle ZFS Storage Appliance 保護グループのセカンダリになっている間は、Oracle ZFS Storage Appliance でレプリケートされた LUN はエクスポートできないので、そのクラスタからそれらの LUN にアクセスすることはできません。このセカンダリクラスタ上でユーザーが cldevice clear コマンドを実行した場合、これらのレプリケート済み LUN に対応する DID は削除されます。続いて、ユーザーがこのセカンダリクラスタに新しい LUN を追加して cldevice populate コマンドを実行した場合、削除されたレプリケート済み LUN に割り当てられていた DID が、その新しく追加された LUN に再割り当てされる可能性があります。
あとでこのクラスタがプライマリになった場合に、このレプリケートされたデータを使用するアプリケーションがこのクラスタ上で起動される際に、削除されたレプリケート済み LUN に割り当てられていた DID へのアクセスを試みても予期するデータが見つからないため、アプリケーションの起動が失敗します。
回避方法: この問題を回避するには、Oracle ZFS Storage Appliance 保護グループに関してセカンダリになっているクラスタ上では cldevice clear コマンドを決して実行しないようにしてください。
この問題が発生した場合は、cldevice rename コマンドを使用して問題を解決できます。次のシナリオは、この問題の一例と、その状況から回復するためのコマンドを示したものです。このシナリオでは次のサンプルコンポーネントが使用されます。
clusterB – Oracle ZFS Storage Appliance 保護グループのセカンダリクラスタ。
zfssaBoxB – レプリケートされるプロジェクトの現在のターゲット。
DID 13 – この保護グループによって管理されるプロジェクト内のレプリケート対象 LUN に対応する、clusterB 上の DID。
次の一連のアクションを実行すると、この問題が発生します。
新しい LUN を clusterB に追加します。
clusterB のいずれかのノード上で cldevice clear コマンドを発行します。
レプリケートされた LUN はエクスポートされず、アクセス不可能であるため、DID 13 がクラスタから削除されます。
clusterB のいずれかのノード上で cldevice populate コマンドを発行します。
ステップ 1 で作成された新しい LUN に DID 13 が割り当てられます。
保護グループを clusterB にスイッチオーバーし、clusterB をプライマリにします。
このスイッチオーバーによって cldevice populate コマンドが発行されます。クラスタは、次に利用可能な DID である 14 を、clusterB からアクセス可能となったレプリケート済みの LUN に割り当てます。
このとき、アプリケーションリソースは起動できません。DID 13 のデータが予期した内容と異なるからです。
次の回復ステップを実行すると、問題が修正されます。ここで、DID 15 は次の未割り当て DID です。
clusterB の各ノードで DID 13 を DID 15 に移動します。
# cldevice rename -d 15 13; devfsadm; cldevice populate
clusterB の各ノードで DID 14 を DID 13 に移動します。
# cldevice rename -d 13 14; devfsadm; cldevice populate
アプリケーションリソースグループを再起動します。
clresourcegroup restart rg-name
これでアプリケーションは起動できるようになります。DID 13 に予期したデータが見つかるからです。
問題のサマリー: スイッチオーバー時に ASM デバイスグループがオンラインになれない場合がありますが、これは、ベースとなるデバイスが I/O を受け入れていないからです。
回避方法: アプリケーションリソースグループを再起動するには、次のようにします。
グローバルクラスタのいずれかのノードから cldevice populate を発行します。
ゾーンクラスタのいずれかのノードから、ストレージにアクセスできないために失敗したアプリケーションリソースグループを再起動します (例: clrg restart <rg>)。
問題のサマリー: データガード保護グループの作成時にデータガードマネージャーユーザーを sysdba_username=c##dgmgr に設定した場合、次のメッセージとともに処理が失敗します。
Unable to connect using connect string "c##dgmgr/<password>@<instance>". Check that the password or connect string is correct and that the database instance is running
回避方法: この問題を解決するには、sysdba_username=sys を設定します。
問題のサマリー: HA for Oracle Database がほかのリソースに対する依存関係を持っている場合は、Oracle Data Guard 保護グループ構成を取得しようとしてもエラーで失敗します。
回避方法: 保護グループの external_dependencies_allowed プロパティーを true に設定します。
# geopg set-prop -p external_dependencies_allowed=TRUE protection_group
問題のサマリー: プライマリクラスタの障害回復フレームワークによって管理されているソースアプライアンス上のプロジェクトやマウントポイントと同じ名前で構成されたプロジェクトやマウントポイントがターゲットアプライアンス上に存在していると、スイッチオーバーやテイクオーバーが失敗します。
回避方法: Oracle ZFS Storage Appliance のレプリケートされたプロジェクトを保護グループに追加する前に、ターゲットアプライアンスにソースアプライアンスと同じ名前のプロジェクトまたはマウントポイントが存在しないことを確認してください。
問題のサマリー: サイト内のいずれかのコントローラ上で geomg create を使用してマルチグループが作成されると、そのコントローラにサイト内のその他のクラスタとのサイト構成同期エラーが発生していない場合は、それらのクラスタ上でマルチグループが自動的に作成されます。このようなクラスタのいずれかとそのコントローラの間のサイト同期ステータスが ERROR である場合、そのクラスタはマルチグループの作成を受け入れません。
サイトの同期エラーを解決しようとする 1 つの方法として、クラスタ上のサイトの構成データをコントローラ上に存在するデータと同じにするために、そのクラスタ上でコントローラを引数として指定して geosite update コマンドを使用することにより、マルチグループをそのクラスタにレプリケートすることが考えられます。このマルチグループ構成のレプリケーションは、そのクラスタのサイト同期ステータスでコントローラに関して OK が報告されたとしても、状況によっては失敗することがあります。
回避方法: geosite leave コマンドを使用してそのクラスタをサイトから切り離したあと、geosite add-member および geosite join コマンドを使用してサイトに戻します。
問題のサマリー: プライマリとセカンダリの両方の ZFSSA アプライアンスが起動しているときに geopg takeover コマンドを実行した場合は、保護グループがアクティブ化されたあとに元のプライマリ ZFSSA アプライアンス上に存在する空のプロジェクトのために、セカンダリサイトへのスイッチオーバーが失敗します。
回避方法: 保護グループがアクティブ化されたあと、保護グループをスイッチオーバーしようとする前に、セカンダリアプライアンス上の空のプロジェクトを削除します。
問題のサマリー: レプリケーションが Idle (export pending) 状態のときに障害回復フレームワークが間違ってスイッチオーバーを許可してしまいます。
回避方法: 障害回復フレームワークによって管理されているプロジェクトでは、オフラインレプリケーション機能を使用しないでください。