定数が維持されている場合は、ストアが正常に実行しているため、何も行う必要はありません。
ゾーンが機能しなくなったが定数が失われた状況では、フェイルオーバーを実行するしかありません。
たとえば、ストアに2つのプライマリ・ゾーンManhattanとJerseyCityが構成され、ぞれぞれは専用の物理データ・センターにデプロイされているとします。
簡潔にするため、この例ではレプリケーション係数が2のストアを使用します。一般に、大半のアプリケーションで適正であり有効な開始点となるプライマリ・レプリケーション係数は3であり、これは、1つのプライマリ・ゾーンに障害が発生した場合、3つのレプリカにより書込み可用性が得られるためです。
このとき、Manhattanゾーンが機能しなくなったとします。これによって、関連付けられているストレージ・ノードすべてで障害が発生し、定数が失われます。このケースでは、Manhattanのホスト・ハードウェアの損傷が修復不可能である場合、または問題の修復に時間がかかりすぎる場合に、フェイルオーバーの開始を選択できます。
この後の手順で、フェイルオーバー操作を実行する際の、障害の確認、ストレージ・ノードの分離、管理定数の削減について説明します。このプロセスではゾーン障害時にサービスが継続できます。
ストアに接続します。このためには、JerseyCityゾーンで実行している管理に接続します。
java -Xmx256m -Xms256m -jar KVHOME/lib/kvstore.jar \ runadmin -host jersey1 -port 6000
verify configurationコマンドを使用して障害を確認します。
kv-> verify configuration
Connected to Admin in read-only mode
Verify: starting verification of store mystore based upon
topology sequence #207
200 partitions and 2 storage nodes.
Time: 2015-05-29 19:41:14 UTC Version: 12.1.3.4.1
See jersey1:/kvroot/mystore/log/mystore_{0..N}.log
for progress messages
Verify: Shard Status: healthy:0 writable-degraded:0
read-only:1 offline:0
Verify: Admin Status: read-only
Verify: Zone [name=Manhattan id=zn1 type=PRIMARY]
RN Status: online:0 offline:1
Verify: Zone [name=JerseyCity id=zn2 type=PRIMARY]
RN Status: online:1 offline:0
Verify: == checking storage node sn1 ==
Verify: sn1: ping() failed for sn1 :
Unable to connect to the storage node agent at host nyc1,
port 5000, which may not be running; nested exception is:
java.rmi.ConnectException: Connection refused to host:
nyc1; nested exception is:
java.net.ConnectException: Connection refused
Verify: Storage Node [sn1] on nyc1:5000
Zone: [name=Manhattan id=zn1 type=PRIMARY] UNREACHABLE
Verify: admin1: ping() failed for admin1 :
Unable to connect to the storage node agent at host nyc1,
port 5000, which may not be running; nested exception is:
java.rmi.ConnectException: Connection refused to host:
nyc1; nested exception is:
java.net.ConnectException: Connection refused
Verify: Admin [admin1] Status: UNREACHABLE
Verify: rg1-rn1: ping() failed for rg1-rn1 :
Unable to connect to the storage node agent at host nyc1,
port 5000, which may not be running; nested exception is:
java.rmi.ConnectException: Connection refused to host:
nyc1; nested exception is:
java.net.ConnectException: Connection refused
Verify: Rep Node [rg1-rn1] Status: UNREACHABLE
Verify: == checking storage node sn2 ==
Verify: Storage Node [sn2] on jersey1:6000
Zone: [name=JerseyCity id=zn2 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.4.1 2015-05-28 08:27:41 UTC Build id: 287a5a28cea4
Verify: Admin [admin2]
Status: RUNNING,MASTER (non-authoritative)
Verify: Rep Node [rg1-rn2]
Status: RUNNING,MASTER (non-authoritative)
sequenceNumber:217 haPort:6003
Verification complete, 4 violations, 0 notes found.
Verification violation: [admin1] ping() failed for admin1 :
Unable to connect to the storage node agent at host nyc1,
port 5000,which may not be running; nested exception is:
java.rmi.ConnectException: Connection refused to host:
nyc1; nested exception is:
java.net.ConnectException: Connection refused
Verification violation: [rg1-rn1] ping() failed for rg1-rn1 :
Unable to connect to the storage node agent at host nyc1,
port 5000, which may not be running; nested exception is:
java.rmi.ConnectException: Connection refused to host:
nyc1; nested exception is:
java.net.ConnectException: Connection refused
Verification violation: [sn1] ping() failed for sn1 :
Unable to connect to the storage node agent at host nyc1,
port 5000, which may not be running; nested exception is:
java.rmi.ConnectException: Connection refused to host:
nyc1; nested exception is:
java.net.ConnectException: Connection refused
このケースでは、ホストnyc1のストレージ・ノード・エージェントが使用できないことが確認されます。
ハード・ロールバックとデータ損失を防ぐために、機能していないノード(Manhattan)を他のシステムから分離します。機能しなくなったノードはすべて、構成が更新されるまでストアに再結合しないでください。
このためには、次を実行します。
ネットワークを物理的に切断するか、ファイアウォールを使用します。
機能しなくなったノードの起動シーケンスを変更して、SNAが開始しないようにします。
ストアに変更を加えるには、まず管理定数を減らす必要があります。このためには、repair-admin-quorumコマンドを使用して使用可能なプライマリ・ゾーンを指定します。
kv-> repair-admin-quorum -znname JerseyCity Connected to admin in read-only mode Repaired admin quorum using admins: [admin2]
これで、一時的に定数を減らした状態で、残りの管理サービスを使用して管理手順を実行できるようになりました。
plan failoverコマンドを使用して、使用可能なゾーンを含むようにストアの構成を更新します。
kv-> plan failover -znname Manhattan -type offline-secondary -wait Executing plan 8, waiting for completion... Plan 8 ended successfully
plan failoverコマンドは、他のプランがまだ実行中である場合に実行すると失敗します。このプランを実行する前に、それらのプランを取り消すか中断する必要があります。
たとえば、topology redistributeが進行中であるとします。plan failoverコマンドを実行すると、失敗します。これを成功させるには、まずtopology redistributeコマンドを取り消すか中断する必要があります。
このためには、最初にshow plansコマンドを使用して、topology redistributeコマンドのプランIDを調べます。このケースでは9です。次に、plan cancelコマンドを使用してtopology redistributeコマンドを取り消します。
kv-> plan cancel -id 9
フェイルオーバーを実行した後で、pingコマンドを使用して、Manhattanのゾーン・タイプがセカンダリに変更されていることを確認します。
kv-> ping
Pinging components of store mystore based upon topology sequence #208
200 partitions and 2 storage nodes
Time: 2015-07-26 05:00:34 UTC Version: 12.1.3.4.1
Shard Status: healthy:0 writable-degraded:1 read-only:0 offline:0
Admin Status: writable-degraded
Zone [name=Manhattan id=zn1 type=SECONDARY]
RN Status: online:0 offline:1
Zone [name=JerseyCity id=zn2 type=PRIMARY]
RN Status: online:1 offline:0
Storage Node [sn1] on nyc1:5000
Zone: [name=Manhattan id=zn1 type=SECONDARY] UNREACHABLE
Admin [admin1] Status: UNREACHABLE
Rep Node [rg1-rn1] Status: UNREACHABLE
Storage Node [sn2] on jersey1:6000
Zone: [name=JerseyCity id=zn2 type=PRIMARY]
Status: RUNNING
Ver: 12cR1.3.4.1 2015-07-13 10:16:21 UTC Build id: 508d38507fff
Admin [admin2] Status: RUNNING,MASTER
Rep Node [rg1-rn2]
Status: RUNNING,MASTER sequenceNumber:427 haPort:6011
フェイルオーバー操作はこれで完了です。ストアの書込み可用性は、ただ1つの使用可能なプライマリ・ゾーンであるゾーン2を使用して再び確立されています。ゾーン1はオフラインです。障害前にゾーン1から伝播されなかったデータは失われます。
このケースでは、ストアにデータの作業用コピーが1つしかないため、残存ゾーンで1つのノード障害が発生すると読取りと書込みのアクセスが妨げられます。永続的な障害の場合には、永続的なデータ損失が発生することがあります。
フェイルオーバーの原因となった問題が修正され、機能していなかったノード(Manhattan)の元のデータがまた使用可能になった場合は、スイッチオーバーを実行して元のノードにサービスを戻すことができます。これを行うには、次の項を参照してください。