スイッチオーバーの実行
前の項の例に続いています。フェイルオーバーを実行した後で、次のスイッチオーバーの手順を実行して元のノードにサービスを戻すことができます。
-
機能しなくなったゾーンを修復した後で、そのゾーンのすべてのストレージ・ノードを再起動しますが、このときサービスは開始しません(ハード・ロールバックを回避します)。
ノート:
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