前の項の例に続いています。フェイルオーバーを実行した後で、次のスイッチオーバーの手順を実行して元のノードにサービスを戻すことができます。
機能しなくなったゾーンを修復した後で、そのゾーンのすべてのストレージ・ノードを再起動しますが、このときサービスは開始しません(ハード・ロールバックを回避します)。
java -jar KVHOME/lib/kvstore.jar restart -disable-services \ -root nyc1/KVROOT &
計画的なメンテナンスを実行する際は、ノードをオンラインに戻す前に、ノードを分離したりサービスを無効にしたりする必要はありません。
ネットワーク接続を再確立するか、機能していなかったゾーンの標準起動シーケンスを再び有効にします。
トポロジを修復します。新たに再起動したストレージ・ノードのトポロジを更新して、フェイルオーバーによって行われた変更を含むようにします。
java -Xmx256m -Xms256m -jar KVHOME/lib/kvstore.jar runadmin \ -host jersey1 -port 5000 kv-> plan repair-topology -wait Executed plan 10, waiting for completion... Plan 10 ended successfully
このコマンドを使用すると、機能していなかったノード上のサービスも再起動されます。
verify configurationコマンドを使用して、構成の問題がないことを確認します。
pingコマンドを実行します。maxCatchupTimeSecs値がawait-consistencyコマンドの-timeoutフラグで使用されます。
このtimeoutフラグを使用して、スイッチオーバーにかかる予測時間を指定できます。たとえば、ノードが長い間オフラインになっていた場合は、再びプライマリ・ノードに変換できる状態に追い付くまでに何時間もかかることがあります。
kv-> ping
Pinging components of store mystore based upon topology sequence #208
200 partitions and 2 storage nodes
Time: 2015-07-17 17:10:19 UTC Version: 12.1.3.4.1
Shard Status: healthy:1 writable-degraded:0 read-only:0 offline:0
Admin Status: healthy
Zone [name=Manhattan id=zn1 type=SECONDARY]
RN Status: online:1 offline:0 maxDelayMillis:120000
maxCatchupTimeSecs:1800
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]
Status: RUNNING
Ver: 12cR1.3.4.1 2015-07-13 10:16:21 UTC Build id: 508d38507fff
Admin [admin1] Status: RUNNING,REPLICA
Rep Node [rg1-rn1] Status: RUNNING,REPLICA
sequenceNumber:434 haPort:5011 delayMillis:0 catchupTimeSecs:0
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:434 haPort:6011
このケースでは、値として1800秒(30分)を使用します。
await-consistencyコマンドを使用して、セカンダリ・ゾーンがマスターに追い付くために使用される待機時間(1800秒)を指定します。
システムはゾーンのタイプを変更しようとするとき、ノードが追い付くために5分間しか待機しません。この時間内にノードが追い付かない場合、プランは失敗します。
ノードが追い付くために5分よりも長くかかる場合は、-timeoutフラグに長い待機時間を指定してawait-consistencyコマンドを実行する必要があります。このケースでは待機時間として1800秒が使用されます。
kv-> await-consistent -timeout 1800 -znname Manhattan The specified zone is consistent
デフォルトでは、追い付いたとみなされるためのノードの遅延時間は1秒以内です。この値は-replica-delay-thresholdフラグを指定して変更できます。ネットワークの遅延のためにノードがマスターの1秒以内に追い付けない場合には、これを行う必要があります。
ノードが追い付くのをスイッチオーバーで待機しない場合は、-no-replica-delay thresholdフラグを使用できます。このケースでは、ノードが遅れていてもプライマリ・ノードに変換されます。このリスクを取る価値があるかどうかを判断する必要があります。
スイッチオーバーを実行して、機能していなかったゾーンをプライマリ・ゾーンに変換して戻します。
kv-> topology clone -current -name newTopo kv-> topology change-zone-type -name newTopo -znname Manhattan -type primary Changed zone type of zn1 to PRIMARY in newTopo kv-> plan deploy-topology -name newTopo -wait Executed plan 11, waiting for completion... Plan 11 ended successfully
Manhattanゾーンのゾーン・タイプがPRIMARYに変更されたことをpingコマンドを実行して確認します。
kv-> ping
Pinging components of store mystore based upon topology sequence #208
200 partitions and 2 storage nodes
Time: 2015-07-17 17:10:19 UTC Version: 12.1.3.4.1
Shard Status: healthy:1 writable-degraded:0 read-only:0 offline:0
Admin Status: healthy
Zone [name=Manhattan id=zn1 type=PRIMARY]
RN Status: online:1 offline:0 maxDelayMillis:120000
maxCatchupTimeSecs:1800
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=PRIMARY]
Status: RUNNING
Ver: 12cR1.3.4.1 2015-07-13 10:16:21 UTC Build id: 508d38507fff
Admin [admin1] Status: RUNNING,REPLICA
Rep Node [rg1-rn1] Status: RUNNING,REPLICA
sequenceNumber:434 haPort:5011 delayMillis:0 catchupTimeSecs:0
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:434 haPort:6011