スイッチオーバーの実行

前の項の例に続いています。フェイルオーバーを実行した後で、次のスイッチオーバーの手順を実行して元のノードにサービスを戻すことができます。

機能しなくなったゾーンを修復した後で、そのゾーンのすべてのストレージ・ノードを再起動しますが、このときサービスは開始しません(ハード・ロールバックを回避します)。

ノート:

SNAを開始する前に、各ノードで環境変数MALLOC_ARENA_MAXを1に設定します。こうすることで、メモリー使用量が指定されたヒープ・サイズに制限されます。
```
java -Xmx64m -Xms64m \
-jar KVHOME/lib/kvstore.jar restart -disable-services \
-root nyc1/KVROOT &
```
ノート:

計画的なメンテナンスを実行する際は、ノードをオンラインに戻す前に、ノードを分離したりサービスを無効にしたりする必要はありません。
ネットワーク接続を再確立するか、機能していなかったゾーンの標準起動シーケンスを再び有効にします。
トポロジを修復します。新たに再起動したストレージ・ノードのトポロジを更新して、フェイルオーバーによって行われた変更を含むようにします。
```
java -Xmx64m -Xms64m -jar KVHOME/lib/kvstore.jar runadmin \
-host jersey1 -port 5000 \
-security USER/security/admin.security

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: 2018-09-28 06:57:10 UTC   Version: 18.3.2
Shard Status: healthy:1 writable-degraded:0 read-only:0 offline:0
Admin Status: healthy
Zone [name=Manhattan id=zn1 type=SECONDARY allowArbiters=false masterAffinity=false]
RN Status: online:1 offline:0 maxDelayMillis:120000
                                                maxCatchupTimeSecs:1800
Zone [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false masterAffinity=false]
RN Status: online:1 offline:0
Storage Node [sn1] on nyc1:5000
Zone: [name=Manhattan id=zn1 type=SECONDARY allowArbiters=false masterAffinity=false]
Status: RUNNING
Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
        Admin [admin1]          Status: RUNNING,REPLICA
        Rep Node [rg1-rn1]      Status: RUNNING,REPLICA
        sequenceNumber:434 haPort:5011 available storage size:18 GB delayMillis:0 catchupTimeSecs:0
Storage Node [sn2] on jersey1:6000
Zone: [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING
Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
        Admin [admin2]          Status: RUNNING,MASTER
        Rep Node [rg1-rn2]
        Status: RUNNING,MASTER sequenceNumber:434 haPort:6011 available storage size:16 GB

このケースでは、値として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: 2018-09-28 06:57:10 UTC   Version: 18.3.2
Shard Status: healthy:1 writable-degraded:0 read-only:0 offline:0
Admin Status: healthy
Zone [name=Manhattan id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
RN Status: online:1 offline:0 maxDelayMillis:120000
                                                maxCatchupTimeSecs:1800
Zone [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false masterAffinity=false]
RN Status: online:1 offline:0
Storage Node [sn1] on nyc1:5000
Zone: [name=Manhattan id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING
Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
        Admin [admin1]          Status: RUNNING,REPLICA
        Rep Node [rg1-rn1]      Status: RUNNING,REPLICA
        sequenceNumber:434 haPort:5011 available storage size:18 GB delayMillis:0 catchupTimeSecs:0
Storage Node [sn2] on jersey1:6000
Zone: [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING
Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
        Admin [admin2]          Status: RUNNING,MASTER
        Rep Node [rg1-rn2]
        Status: RUNNING,MASTER sequenceNumber:434 haPort:6011 available storage size:12 GB