ライブラリ・バージョン12.1.3.0

リリース2.0からリリース3.0へのアップグレード
前 | 第6章 既存のOracle NoSQL Databaseデプロイメントのアップグレード | 次

## リリース2.0からリリース3.0へのアップグレード

リリース2からリリース3へのストアのアップグレードは、一度に1つのストレージ・ノードに対して実行できます。これは、リリース2と3のストレージ・ノードが混在していても同じノードで同時に実行できるためです。これにより、最も効率的な方法でストレージ・ノードを戦略的にアップグレードできます。

### 注意

1.0ストアをリリース3に直接アップグレードすることできません。ストアを1.0から2.0へアップグレードしてから、リリース3にアップグレードする必要があります。1.0ストアをアップグレードする方法は、「NoSQL DBリリース1.0からNoSQL DBリリース2.0へのアップグレード」を参照してください。

### 注意

ストアに多数のストレージ・ノードが含まれている場合、スクリプトを使用してアップグレードを実行することもできます。詳細は、「スクリプトを使用したリリース3へのアップグレード」を参照してください。

潜在的な問題を回避するために、新しいCLIコマンドを使用して、ノードを同時にアップグレードするタイミングを特定できます。このようなコマンドについては、次の手順で説明します。

ストアをアップグレードするには、まず管理サービスを実行しているストレージ・ノードにリリース3のソフトウェアをインストールします。新しいCLIコマンドが機能するためには、更新された管理サービスが必要です。

次の手順を実行します。

1. リリース2の管理サービスを実行しているストレージ・ノードにおいて:

   1. 更新されたソフトウェアを、管理サービスを実行しているストレージ・ノード上の新規KVHOMEディレクトリに配置します。ここでは、新規KVHOMEディレクトリはNEW_KVHOMEとします。ノードでNFSを使用してこのディレクトリを共有する場合、これは、共有ディレクトリごとに一度のみ行う必要があります。

   2. リリース2 CLIを使用してストレージ・ノードを停止します。この手順を実行すると、そのストレージ・ノード上の管理サービスがシャットダウンされます。

      /etc/init.d、Upstartまたは他のメカニズムを使用して再起動時にストレージ・ノード・エージェントを自動的に起動するようにノードを構成している場合は、まずそのスクリプトをNEW_KVHOMEを指すように変更します。

      そのスクリプトを変更した後、ストレージ・ノードをシャットダウンします。

          java -Xmx256m -Xms256m \
          -jar KVHOME/lib/kvstore.jar stop -root <kvroot>

   3. リリース3コードを使用してストレージ・ノードを再起動します。

          nohup java -Xmx256m -Xms256m \
          -jar NEW_KVHOME/lib/kvstore.jar start -root <kvroot>&

      (ストレージ・ノード・エージェントを自動的に再起動するようにシステムが構成されている場合、このステップは不要です。)

   4. CLIを使用して、リリース3コードを実行しているストレージ・ノードに接続します。

          java -Xmx256m -Xms256m \
          -jar NEW_KVHOME/lib/kvstore.jar runadmin -port 5000 -host node1
          kv->

   5. ストア内のすべてのストレージ・ノードで、リリース3へのアップグレードに必要とされる適切なソフトウェア・レベルが実行されていることを確認します。2.0または2.1のパッチ・リリース・レベルがソフトウェア・レベルの最小要件を満たしていることに注意してください。

          kv-> verify prerequisite
          Verify: starting verification of mystore based upon topology
          sequence #315
          300 partitions and 6 storage nodes. Version: 12.1.3.0.1 Time:
          2014-01-07 08:19:15 UTC
          See node1:<KVROOT>/mystore/log/mystore_{0..N}.log for progress
          messages
          Verify prerequisite: Storage Node [sn3] on node3:5000
          Zone: [name=Boston id=zn1 type=PRIMARY]   Status: RUNNING
          Ver: 12cR1.2.1.54 2013-11-11 12:09:35 UTC  Build id: 921c25300b5e

          ...

          Verification complete, no violations.

      ここに示すのは、検証コマンドの出力例の一部のみです。重要な部分は最後の行です。違反はありません。

      違反の理由として最も可能性が高いのは、リリース・レベルを(誤って)ダウングレードしようとしたことです。たとえば、上位のマイナー・リリースから下位のマイナー・リリースにダウングレードすることはできません。この違反は、ストア内の他のノードのリリース・レベルより低いマイナー・リリース・レベルのパッケージを使用してCLIコマンドを実行しているために発生した可能性があります。

      ### 注意

      上位のパッチ・レベルから下位のパッチレベルにダウングレードすることは可能です。したがって、たとえば2.1.4から2.1.3にダウングレードすることはできますが、2.1.3から2.0.39にダウングレードすることはできません。

      また、1.0ノード・ディレクトリをリリース3に直接アップグレードしようとした場合も違反が発生します。1.0ストアをアップグレードする際、まず2.0にアップグレードし、次にリリース3にアップグレードする必要があります。1.0ストアをアップグレードする方法は、「NoSQL DBリリース1.0からNoSQL DBリリース2.0へのアップグレード」を参照してください。

      いずれにしても、`verify prerequisite`コマンドが違反を示す場合は、状況を解決してから、識別されたそのノードのアップグレードを試行します。

   6. アップグレードするノードの順序付きリストを取得します。

          kv-> show upgrade-order
          sn3 sn4
          sn2 sn5
          sn6

      1行にまとめられたストレージ・ノードは、同時にアップグレードする必要があります。したがって、この出力ではsn3とsn4をアップグレードします。その後、sn2とsn5をアップグレードします。最後に、sn6をアップグレードします。

      次のグループに進む前に、ノードのグループを完全にアップグレードする必要があることに注意してください。つまり、sn3とsn4をアップグレードしてから、sn2、sn5またはsn6のアップグレードに進みます。

2. アップグレードするストレージ・ノードの最初のグループ(この例ではsn3とsn4)の各ストレージ・ノードに対して、次の手順を実行します。

   1. リリース3ソフトウェアを新規KVHOMEディレクトリに置きます。ここでは、新規KVHOMEディレクトリはNEW_KVHOMEとします。ノードでNFSを使用してこのディレクトリを共有する場合、これは、共有ディレクトリごとに一度のみ行う必要があります。

   2. リリース2ユーティリティを使用してストレージ・ノードを停止します。

      /etc/init.d、Upstartまたは他のメカニズムを使用して再起動時にストレージ・ノード・エージェントを自動的に起動するようにノードを構成している場合は、まずそのスクリプトをNEW_KVHOMEを指すように変更します。

      スクリプトを変更したら、古いコードを使用してストレージ・ノードをシャットダウンします。

          java -Xmx256m -Xms256m \
          -jar KVHOME/lib/kvstore.jar stop -root <kvroot>

   3. 新しいコードを使用してストレージ・ノードを再起動します。

          nohup java -Xmx256m -Xms256m \
          -jar NEW_KVHOME/lib/kvstore.jar start -root <kvroot>&

      (ストレージ・ノード・エージェントを自動的に再起動するようにシステムが構成されている場合、このステップは不要です。)

3. ノードの次のセットをアップグレードする前に、アップグレードを検証します。このコマンドは、正常にアップグレードされたノード、および引き続きアップグレードが必要なノードを示します。

       kv-> verify upgrade
       Verify: starting verification of mystore based upon topology
       sequence #315
       300 partitions and 6 storage nodes. Version: 12.1.3.0.1 Time:  ....
       See node1:<KVROOT>/mystore/log/mystore_{0..N}.log for progress
       messages
       Verify upgrade: Storage Node [sn3] on node3:5000
       Zone: [name=Boston id=zn1 type=PRIMARY]    Status: RUNNING
       Ver: 12cR1.3.0.1 2013-12-18 06:35:02 UTC  Build id: 8e70b50c0b0e

       ...

       Verify: sn2: Node needs to be upgraded from 12.1.2.1.54 to
       version 12.1.3.0.0 or newer

       ...

       Verification complete, 0 violations, 3 notes found.
       Verification note: [sn2]    Node needs to be upgraded from
       12.1.2.1.54 to version 12.1.3.0.0 or newer
       Verification note: [sn5]    Node needs to be upgraded from
       12.1.2.1.54 to version 12.1.3.0.0 or newer
       Verification note: [sn6]    Node needs to be upgraded from
       12.1.2.1.54 to version 12.1.3.0.0 or newer

   見やすさとスペースの関係で、`verify upgrade`コマンドによって生成された出力の一部のみを示しています。アップグレードされたノードは、現在のソフトウェア・バージョン番号を含む検証メッセージで識別されます。

        Verify upgrade: Storage Node [sn3] on node3:5000
       Zone: [name=Boston id=zn1 type=PRIMARY]
       Status: RUNNING
       Ver: 12cR1.3.0.1 2013-12-18 06:35:02 UTC  Build id: 8e70b50c0b0e

   引き続きアップグレードが必要なノードは、2種類の方法で識別されます。まず、ノードの検証メッセージは、引き続きアップグレードが必要であることを示します。

       Verify: sn2: Node needs to be upgraded from 12.1.2.1.54 to
       version 12.1.3.0.0 or newer

   次に、検証出力の末尾には、引き続きアップグレードが必要なすべてのノードが示されます。

       Verification complete, 0 violations, 3 notes found.
       Verification note: [sn2]    Node needs to be upgraded from
       12.1.2.1.54 to version 12.1.3.0.0 or newer
       Verification note: [sn5]    Node needs to be upgraded from
       12.1.2.1.54 to version 12.1.3.0.0 or newer
       Verification note: [sn6]    Node needs to be upgraded from
       12.1.2.1.54 to version 12.1.3.0.0 or newer

   ### 注意

   アップグレードしたと思われるノードが、引き続きアップグレードが必要であることを検証が示す場合は、ストア内の他のノードをアップグレードする前にその問題を解決する必要があります。サニティ・チェックの一種として、アップグレードが完了したばかりのノードのみを検証できます。

       kv-> verify upgrade -sn sn3 -sn sn4
       Verify: starting verification of mystore based upon topology
       sequence #315
       ...
       Verification complete, no violations.

4. `show upgrade-order`コマンドで識別されたストレージ・ノードのグループのアップグレードを続行できます。前述の手順に従います。リリース2の停止コマンドを使用してリリース2のストレージ・ノードを停止した後、リリース3の起動コマンドを使用してストレージ・ノードを再起動します。すべてのストレージ・ノードがアップグレードされるまでこれを続行します。

   ある時点で次にアップグレードするノードのグループがわからなくなった場合は、`show upgrade-order`コマンドをいつでも再実行できます。

       kv-> show upgrade-order
       Calculating upgrade order, target version: 12.1.3.0.1,
       prerequisite: 11.2.2.0.23
       sn2 sn5
       sn6

5. ストレージ・ノードのアップグレードがすべて完了した後、`verify upgrade`コマンドを実行すると、出力の末尾に検証に関する注意事項は表示されません。

       kv-> verify upgrade
       Verify: starting verification of mystore based upon topology
       sequence #315
       ...
       Verification complete, no violations.
       kv->

### スクリプトを使用したリリース3へのアップグレード

多数のストレージ・ノードが含まれるデプロイメントの場合、前述の手動によるアップグレード手順は問題をはらみます。その場合、スクリプトを使用してストアをアップグレードする必要があります。

リリース3ディストリビューションでの検証にはサンプル・スクリプト(bashシェル・スクリプト)を使用できます。次の場所にあります。

    <KVROOT>/examples/upgrade/onlineUpgrade

このスクリプトには、このセクションの前半で説明したのと同じアップグレード制限があります。リリース2インストールからリリース3へのアップグレードのみ可能です。また、アップグレード・プロセス中にストアを使用できるようにするためには、ストアに少なくとも3つのレプリケーション係数が必要です。

提供されているスクリプトはサンプルにすぎません。インストール環境で適切に機能するためには、スクリプトを変更する必要があります。

スクリプトではソフトウェア・プロビジョニングは実行されないことに注意してください。つまり、インストール・ソフトウェアのために使用するいかなる場所のホスト・マシンへのリリース3パッケージの配置も自分で行う必要があります。ただし、スクリプトはsshを使用してホスト・マシンと通信するため、scpを使用してスクリプトでマシンをプロビジョニングすることもできます。

スクリプトはsshを使用するため、スクリプトが機能するためには、自動ログイン(つまり、パスワードなしのssh経由によるログイン)を許可するようにマシンを構成する必要があります。sshでは公開/秘密鍵認証をサポートしているため、これは通常は安全な動作方法です。

このようにsshを構成する方法の詳細は、http://www.linuxproblem.org/art_9.htmlを参照してください。sshおよびsshサーバーをインストールして構成する方法の詳細は、オペレーティング・システムのドキュメントを参照してください。

前 | 先頭へ | 次
アップグレードに関する一般的な注意事項 | ホーム | NoSQL DBリリース1.0からNoSQL DBリリース2.0へのアップグレード