DataStax Enterprise 5.0へのアップグレード

DataStax Enterprise 4.7または4.8から5.0へのアップグレード手順。

DataStax Enterprise 4.7または4.8から5.0にアップグレードするには、以下の手順に従います。以前のバージョンを使用している場合は、4.8にアップグレードしてから続行してください。

重要: すべての手順を読むようにという推奨事項をご覧になったことと思います。アップグレード手順を細かく確認することで、大きな差が出てきます。やるべきことを前もって理解しておくことにより、スムーズなアップグレードが保証され、落とし穴やフラストレーションを避けることができます。

アップグレードの前にこれらの手順を読み、理解しておいてください。

このページに含まれる内容:

Apache Cassandra™のバージョン変更

DataStax Enterprise 4.7または4.8から5.0へのアップグレードには、Cassandraのメジャー・バージョン変更が含まれます。
  • DataStax Enterprise 5.1はCassandra 3.11を使用します。
  • DataStax Enterprise 5.0はCassandra 3.0を使用します。
  • DataStax Enterprise 4.7~4.8はCassandra 2.1を使用します。
  • DataStax Enterprise 4.0~4.6はCassandra 2.0を使用します。
SSTableをアップグレードするための推奨事項に必ず従ってください。

一般的な推奨事項

DataStaxでは、バージョン・アップグレードの前にデータをバックアップすることをお勧めしています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。

OpsCenterでは、バックアップ・サービス が提供されます。このサービスは、DataStax Enterpriseクラスターの企業全体のバックアップ操作と復元操作を管理します。

アップグレード・プロセス中の一般的な制限事項

制限事項は、クラスターの一部が部分的にアップグレードされている状態で適用されます。

これらの例外により、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。

一般的なアップグレード制限事項
  • 新しい機能を有効にしないでください
  • nodetool repairを実行しないでください。OpsCenter Repair Serviceが構成されている場合は、Repair Serviceをオフにします。
  • アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
  • ローリング再起動中に、DDLTRUNCATEのような種類のCQLクエリーを実行しないでください。
  • アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
  • 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
DSE Analytic(HadoopおよびSpark)ノードの制限事項
  • すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
  • ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。
DSE Search(Solr)アップグレードの制限事項
  • スキーマを更新しないでください。
  • アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
  • ローリング再起動中に、DDLTRUNCATEのような種類のクエリーを実行しないでください。
  • アップグレード中にノードのバージョンが混合している間、DataStax Enterpriseでは後方互換性を提供するための2つの異なるサーバーを実行します。1つはshard_transport_optionsに基づいており、もう1つはinternode_messaging_optionsに基づいています(これらのオプションはdse.yamlに含まれています)。すべてのノードが5.0にアップグレードされると、internode_messaging_optionsが使用されます。internode_messaging_optionsは、DataStax Enterpriseの複数のコンポーネントによって使用されます。5.0以降では、すべてのノード間メッセージング要求でこのサービスが使用されます。
任意の種類のセキュリティを使用するノードの制限事項
  • アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。
  • Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。DataStaxドライバーのアップグレード」を参照してください。
クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバー・バージョンの非互換性を回避するには、以下の回避策のいずれかを使用してください。
  • 起動時のプロトコル・バージョンを強制する。たとえば、アップグレード中はJavaドライバーをv2のままにしておきます。クラスター全体がアップグレードしてから、はじめてJavaドライバーv3に切り替えてください。
  • 初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。たとえば、初期のコンタクト・ポイントにはJavaドライバーv2のみが含まれます。
プロトコル・バージョンのネゴシエーションの詳細については、ご使用のJavaドライバー・バージョン(たとえばJavaドライバー)の「混在クラスターのあるプロトコル・バージョン」を参照してください。

アップグレードの準備

以下の手順に従い、DataStax Enterprise 4.7または4.8からDataStax Enterprise 5.0にアップグレードするために各ノードを準備します。
  1. アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。

    必要なディスク領域は、コンパクション戦略によって異なります。「DataStax Enterpriseデプロイの計画とテスト」の「ディスク領域」を参照してください。

  2. このリリースの変更点と機能について十分理解してください。
  3. 現在の製品バージョンを確認します。必要に応じて、中間バージョンにアップグレードします。
    現在のバージョン アップグレード・バージョン
    DataStax Enterprise 4.7または4.8 DataStax Enterprise 5.0
    DataStax Enterprise 4.0、4.5、または4.6 DataStax Enterprise 4.8
    DataStax Communityまたはオープン・ソースのApache Cassandra™ 2.0.x DataStax Enterprise 4.8
    DataStax Community 3.0.x 中間バージョンは不要です。
    Apache Cassandra™ 3.xのDataStaxディストリビューション アップグレードは利用できません。
  4. すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
    これは、 Cassandraのメジャー・バージョン の変更を含むDataStax Enterpriseのアップグレードに必要です。
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。
    $ nodetool upgradesstables

    SSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。SSTableの互換性とアップグレードバージョン」を参照してください。

    同時にアップグレードするSStableの数を設定するには、--jobsオプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。

  5. Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
    $ java -version

    Oracle Java SE Runtime Environment 8(最低1.8.0_40)またはOpenJDK 8の最新バージョンが推奨されます。開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。

  6. nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。
  7. DSE Searchノード:
    • Luceneフィールド・キャッシュ(solr_field_cache_enabled)ファイルは廃止予定です。このフィールドはdse.yamlファイルに含まれています。代わりに、ソート、ファセット、またはグループ分けされるフィールドに対して、schema.xmlファイル内のフィールドにdocValues="true"を設定します。次に、コアを再度読み込んでインデックスを再作成します。デフォルト値はfalseです。falseをオーバーライドするには、Solr要求内にuseFieldCache=trueを設定します。

      バージョンが混在しているアップグレード中は、フィールド・キャッシュ(solr_field_cache_enabled: true)を再度有効にして、インデックスを再作成せずに、クエリーを実行できるようにします。

    • ユニーク・キー要素はすべてSolrスキーマでインデックスを付ける必要があります。

      ユニーク・キー要素を確認するには、schema.xmlですべてのユニーク・キー・フィールドがindexed=trueになっていることを確認します。必要に応じて、schema.xmlに変更を加え、インデックスを付け直します。

    • HTTPベースのSolrシャード・トランスポート・オプションは廃止予定です。代わりにノード間メッセージング・オプションを使用してください。5.0では、すべてのノード間メッセージング要求でこの内部メッセージング・サービスが使用されます。HTTPは5.1では削除されます。
    • アップグレードの前にスキーマを調整してください。DSE 5.0.10以降では、スキーマ内のすべてのフィールド定義が検証されます。フィールドにインデックスがないか、docValuesを適用するか、これらがコピー・フィールド・ソースに対して使用される場合であっても、DSE Searchがサポートされている必要があります。自動リソース生成のデフォルトの動作には、すべてのカラムが含まれます。パフォーマンスを改善するには、フィールドがデータベースから読み込まれないように対策を講じます。スキーマ内の使用されていないフィールドを削除するかコメント・アウトして、スキーマ内の必要なフィールドのみを含めます。 スキーマを変更したら、Solrコアを再読み込みします。
  8. DSE Searchパーティション・キー名
    DSE SearchインデックスによってサポートされているCOMPACT STORAGEテーブルのパーティション・キー名は、schema.xml内のuniqueKeyに一致します。たとえば、コンパクト・ストレージで次のテーブルを作成するとします。
    CREATE TABLE keyspace_name.table_name (key text PRIMARY KEY, foo text, solr_query text) 
    WITH COMPACT STORAGE
    Solr schema.xmlは次のとおりです。
    ...
    <uniqueKey>id</uniqueKey>
    ...
    次に、テーブル内のキー名をスキーマに合わせて変更します。
    ALTER TABLE ks.table RENAME key TO id;
  9. 使用する 構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。

    構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。

アップグレード手順

ヒント: DataStaxインストーラーは、DataStax Enterpriseをアップグレードし、多数のアップグレード・タスクを自動的に実行します。
DataStax Enterprise 4.7または4.8からDataStax Enterprise 5.0にアップグレードするには、各ノードで以下の手順に従います。一部の警告メッセージがアップグレード中とアップグレード後に表示されます
  1. アップグレードの順序は重要です。ノードは以下の順序でアップグレードします。
    • 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
    • データ・センター内のシード・ノードを最初にアップグレードします。

      DSE Hadoopを使用するDSE Analyticsノードでは、Job Trackerノードを最初にアップグレードします。次にHadoopノード、Sparkノードの順にアップグレードします。

    • タイプは以下の順序でアップグレードします。
      1. DSE Analyticsノードまたはデータ・センター
      2. トランザクション/DSE Graphノードまたはデータ・センター
      3. DSE Searchノードまたはデータ・センター
    若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。ノードは1つずつアップグレードして再起動してください。クラスター内の他のノードは、すべてのノードがアップグレードされるまで、最も古いバージョンで動作します。
  2. DSE Analyticsノード:すべてのSparkワーカー・プロセスを強制終了します。
  3. DSE Searchノード:以下の考慮事項を確認して、適切なアクションを実行します。
  4. 次のようにnodetool drainを実行し、古いインストールのコミット・ログをフラッシュします。
    $ nodetool drain -h hostname
    この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。
    重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。
  5. ノードの停止
  6. 適切な方法を使用して、サポートされるプラットフォームに新しい製品バージョンをインストールします。
    注: システム上にある同じインストール・タイプを使用して新しい製品バージョンをインストールします。アップグレードではインストール・タイプに関係なくインストールを行うため、問題が発生することがあります。
  7. クラスターがセキュアなKerberos環境でHadoopを実行する場合は、task-controllerファイルの所有権をrootに変更し、アクセス・パーミッションを4750に変更します。例を次に示します。
    $ sudo chown root /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller
    $ sudo chmod 4750 /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller

    パッケージ・インストールのみ:task-controllerファイルのデフォルトの場所を/usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controllerに設定する必要があります。

  8. 新しい製品バージョンを構成するには:
    1. バックアップ 構成 ファイルを新しい構成ファイルと比較します。
      • 廃止予定、削除済み、または変更済みの設定を探します。
      • 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
    2. 該当する変更を新しいバージョンにマージします。
  9. ノードを起動します。
  10. アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
    $ nodetool status
  11. 警告、エラー、および例外がないか、ログを確認します。 DataStax Enterprise 5.0はCassandra 3.0を使用するため、output.logには以下に関する警告が含まれる場合があります。
    • sstable_compression
    • chunk_length_kb
    • memory_allocator
    • memtable_allocation_type
    • offheap_objects
    • netty_server_port - 5.0へのアップグレード中にのみ使用。すべてのノードが5.0を実行するようになると、このノードによってコーディネートされる要求はこのポートで他のノードに連絡しなくなります。代わりに、要求にはノード間メッセージング・オプションが使用されます。internode_messaging_optionsは、DataStax Enterpriseの複数のコンポーネントによって使用されます。5.0以降では、すべてのノード間メッセージング要求でこのサービスが使用されます。

    多くの場合、警告、エラー、および例外は、アップグレードしたノードの起動時にログに表示されます。これらのログ・エントリーの一部は、固有のアップグレード関連の手順を実行するときに役立ちます。予想しなかった警告、エラー、または例外が表示された場合は、DataStaxサポートまでお問い合わせください。

    DSE Analyticsノードのアップグレード中は、タスク・トラッカーに関する例外が、まだ5.0にアップグレードされていないノードのログに記録されます。クラスター全体がアップグレードされたらジョブは成功となります。

  12. 推奨される順序に従って、クラスター内の各ノードでアップグレードを 繰り返します
  13. すべてのノードがアップグレードされたら、次のレガシー・テーブルを削除します:system_auth.users、system_auth.credentials、およびsystem_auth.permissions。

    CassandraのNEWS.txtに説明されているように、認証および権限管理サブシステムはロールベースのアクセス制御(RBAC)をサポートするように再設計されています。これにより、system_authキースペースのスキーマが変更されます。

  14. 新しいバージョンがすべてのノードにインストールされたら、次のSSTableをアップグレードします。
    $ nodetool upgradesstables
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。

    同時にアップグレードするSStableの数を設定するには、--jobsオプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。

  15. 複数のデータ・センターのデプロイでは、system_distributedキースペースのレプリケーション係数をNetworkTopologyStrategyに変更します。
  16. OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。
OpsCenter Backup Service

DataStax EnterpriseおよびApache Cassandra™の構成ファイル

構成ファイル Installer-Servicesおよびパッケージのインストール Installer-No Servicesおよびtarボールのインストール
DataStax Enterprise構成ファイル
byoh-env.sh /etc/dse/byoh-env.sh install_location/bin/byoh-env.sh
dse.yaml /etc/dse/dse.yaml install_location/resources/dse/conf/dse.yaml
logback.xml /etc/dse/cassandra/logback.xml install_location/resources/logback.xml
spark-env.sh /etc/dse/spark/spark-env.sh install_location/resources/spark/conf/spark-env.sh
spark-defaults.conf /etc/dse/spark/spark-defaults.conf install_location/resources/spark/conf/spark-defaults.conf
Cassandraの構成ファイル
cassandra.yaml /etc/cassandra/cassandra.yaml install_location/conf/cassandra.yaml
cassandra.in.sh /usr/share/cassandra/cassandra.in.sh install_location/bin/cassandra.in.sh
cassandra-env.sh /etc/cassandra/cassandra-env.sh install_location/conf/cassandra-env.sh
cassandra-rackdc.properties /etc/cassandra/cassandra-rackdc.properties install_location/conf/cassandra-rackdc.properties
cassandra-topology.properties /etc/cassandra/cassandra-topology.properties install_location/conf/cassandra-topology.properties
Tomcatサーバーの構成ファイル
server.xml /etc/dse/resources/tomcat/conf/server.xml /etc/dse/tomcat/conf/server.xml

アップグレード中とアップグレード後の警告メッセージ

アップグレード中およびアップグレード後に表示される一部のログ・メッセージは無視できます。

DataStax Enterprise 5.0にアップグレードする直前にスキーマを変更した場合は、以下のようなログ・メッセージがアップグレード後に表示される場合があります。
WARN  [main] 2016-06-23 12:01:59,693  CommitLogReplayer.java:154 - Skipped 31 mutations from unknown (probably removed) CF with id b0f22357-4458-3cdb-9631-c43e59ce3676
WARN  [main] 2016-06-23 12:01:59,693  CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 3aa75225-4f82-350b-8d5c-430fa221fa0a
WARN  [main] 2016-06-23 12:01:59,696  CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 45f5b360-24bc-3f83-a363-1034ea4fa697
WARN  [main] 2016-06-23 12:01:59,696  CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 0359bc71-7123-3ee1-9a4a-b9dfb11fc125
WARN  [main] 2016-06-23 12:01:59,697  CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 296e9c04-9bec-3085-827d-c17d3df2122a
これらのログ・メッセージは無視しても差し支えありません。

アップグレード順序

ノードは以下の順序でアップグレードします。
  • 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
  • データ・センター内のシード・ノードを最初にアップグレードします。
  • タイプは以下の順序でアップグレードします。
    1. DSE Analyticsノードまたはデータ・センター
    2. トランザクション/DSE Graphノードまたはデータ・センター
    3. DSE Searchノードまたはデータ・センター
  • DSE Hadoopを使用するDSE Analyticsノードでは、Job Trackerノードを最初にアップグレードします。次にHadoopノード、Sparkノードの順にアップグレードします。
Apache Cassandraのメジャー・リリースを含むアップグレードには、SSTableのアップグレードが必要です。
  • DataStax Enterprise 5.1はCassandra 3.11を使用します。
  • DataStax Enterprise 5.0はCassandra 3.0を使用します。
  • DataStax Enterprise 4.7~4.8はCassandra 2.1を使用します。
  • DataStax Enterprise 4.0~4.6はCassandra 2.0を使用します。