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

DataStax Enterprise 3.2.xにアップグレードするには、以下の手順に従います。

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
jmxremote.password /etc/cassandra/jmxremote.password install_location/conf/jmxremote.password
Tomcatサーバーの構成ファイル
server.xml /etc/dse/resources/tomcat/conf/server.xml install_location/resources/tomcat/conf/server.xml

DataStaxドライバーの変更点

DataStaxドライバーには2つのタイプがあります。

  • DataStax Enterprise用DataStaxドライバー:DSE 4.8以降用
  • Apache Cassandra用DataStaxドライバー:Apache CassandraおよびDSE 4.7以前のバージョン用
注: Apache Cassandraドライバー用のDataStaxドライバーは、DSE 5.0以降のクラスターに接続できますが、DSEドライバーにアップグレードすることを強くお勧めします。DSEドライバーでは、DataStax Enterpriseのすべての機能を使用できます。
1. アップグレードの情報は、各ドライバーのガイドに含まれています。
DataStax Enterprise用DataStaxドライバー Apache Cassandra用DataStaxドライバー
C/C++ C/C++
C# C#
Java Java
Node.js Node.js
Python Python
メンテナンス・モード・ドライバー
DataStaxでサポートされますが、新しいバージョンには重大なバグの修正のみが含まれます。
PHP PHP
Ruby Ruby
追加のドライバーのドキュメント
すべてのドライバー バージョンの互換性

Cassandraのメジャー・バージョンのアップグレード

Apache Cassandraのメジャー・リリースを含むアップグレードには、SSTableのアップグレードが必要です。
  • DataStax Enterprise 6.7はCassandra 3.11と互換性があります。
  • DataStax Enterprise 6.0はCassandra 3.11と互換性があります。
  • 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を使用します。
重要: アップグレードの前にこれらの手順を読み、理解しておいてください。計画およびアップグレード手順を細かく確認しておくと、スムーズなアップグレードが保証され、不備や不満が生じるのを避けることができます。

Cassandraのバージョン変更

DataStax Enterprise 3.2へのアップグレードには、Cassandraのメジャー・バージョン の変更が含まれます。SSTableをアップグレードするための推奨事項に必ず従ってください。

一般的な推奨事項

DataStaxでは、バージョン・アップグレードの前に、ログ、カスタム構成などのデータをバックアップすることを推奨しています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。

アップグレードの制限事項

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

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

アップグレード中の一般的な制限事項
  • 新しい機能を有効にしないでください
  • nodetool repairを実行しないでください。OpsCenter Repair Serviceが構成されている場合は、Repair Serviceをオフにします
  • OpsCenterの互換性を確認してください。DSE 6.0クラスターを管理するには、OpsCenter 6.5が必要です。「DataStax OpsCenterとDataStax Enterpriseの互換性」を参照してください。
  • アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
  • ローリング再起動中に、DDLTRUNCATEのような種類のCQLクエリーを実行しないでください。
  • バージョンが混在しているクラスターではChange Data Capture(CDC)を有効にしないでください。すべてのノードをDSE 5.1以降にアップグレードしてからCDCを有効にしてください。
  • 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
注: アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
  • NodeSyncは、すべてのノードがアップグレードされるまで起動を待機します。
  • バージョンが混在しているクラスターではChange Data Capture(CDC)を有効にしないでください。すべてのノードをアップグレードしてからCDCを有効にしてください。
セキュリティ・アップグレードの制限事項
  • アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。
ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。参照先: DataStaxドライバーの変更点
クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバーのバージョン互換性の喪失を回避するには、以下の回避策のいずれかを使用してください。
  • プロトコル・バージョン:一部のドライバーでは異なるプロトコル・バージョンを使用できるため、起動時にプロトコル・バージョンを強制します。たとえば、ドライバー・アップグレード中はJavaドライバーを現在のプロトコル・バージョンのままにしておきます。クラスター内のすべてのノードでアップグレードが完了してから、はじめてJavaドライバーを新しいプロトコル・バージョンに切り替えてください。
  • 初期のコンタクト・ポイント:初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。たとえば、初期のコンタクト・ポイントにはJavaドライバーv2のみが含まれます。
プロトコル・バージョンのネゴシエーションの詳細については、ご使用のJavaドライバー・バージョン(たとえばJavaドライバー)の「混在クラスターのあるプロトコル・バージョン」を参照してください。

DataStax Enterprise 2.2.2以降からDataStax Enterprise 3.2へのアップグレードの準備

ヒント: DataStaxインストーラーは、DataStax Enterpriseをアップグレードし、多数のアップグレード・タスクを自動的に実行します。
DataStaxインストーラーを使用しない場合、DataStax Enterprise 2.2.2以降からDataStax Enterprise 3.2へのアップグレードに備えるには、以下の手順に従います。
  1. アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。

    必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。

  2. 現在の製品バージョンを確認します。3.2にアップグレードする前に、必要に応じて、次のいずれかの中間バージョンにアップグレードします。
    • DataStax Enterprise 2.2.2以降
    • DataStax Communityまたはオープン・ソースのApache Cassandra 1.1.9
    • DataStax Communityまたはオープン・ソースのApache Cassandra 1.2.9~1.2.15
  3. DataStax Enterprise 3.0.xおよび2.2.xからのアップグレードの場合は、以下のリソースに記載された特定のアクションを確認し、実行します。
  4. Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
    java -version
    Oracle Java SE Runtime Environment 7または8、あるいはOpenJDK 7の最新バージョンが推奨されます。開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。
    注: Oracle Java 7を使用する場合は、最低でも1.7.0_25を使用する必要があります。Oracle Java 8を使用する場合は、最低でも1.8.0_40を使用する必要があります。
  5. このリリースの変更点と機能について十分理解してください。
    • DataStax Enterprise 3.2のリリース・ノート
    • アップグレードに関する一般的なアドバイスおよびApache Cassandraの機能については、NEWS.txtに記載されています。以前のリリースからアップグレードする場合は、NEWS.txtで現在ご使用のバージョンに関する箇所まですべてお読みください。
    • Apache Cassandraでの変更点については、CHANGES.txtに記載されています。
  6. searchノードのあるDataStax Enterprise 2.1.xからのアップグレードについては、「Solr」の制限事項を参照してください。
  7. すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
    nodetool upgradesstables
    この手順は、 Cassandraのメジャー・バージョン の変更を含むDataStax Enterpriseのアップグレードに必要です。
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。

    SSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。

  8. 使用する構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。

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

  9. アップグレードの順序は重要です。以下のガイドラインを使用して、推奨される順序でノードをアップグレードします。
    • 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノートをアップグレードしてから、別のデータ・センターへと進みます。
    • データ・センター内のシード・ノードを最初にアップグレードします。
    • analyticsノードまたはデータ・センターを最初にアップグレードしてから、transactionalノードまたはデータ・センター、searchノードまたはデータ・センターの順にアップグレードします。
    • analyticsノードでは、Job Trackerノードを最初にアップグレードします。その後、Hadoopノードをアップグレードします。

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

DataStax Enterprise 3.2にアップグレードするには、以下の手順に従います。
  1. 次のようにnodetool drainを実行し、古いインストールのコミット・ログをフラッシュします。
    nodetool -h hostname drain 
    この手順により、アップグレード後のノードの起動時の時間を節約できます。
  2. ノードを停止します。
  3. 適切な方法を使用して、サポートされるプラットフォームに新しい製品バージョンをインストールします。
    注: システム上にある同じインストール方法を使用して新しい製品バージョンをインストールします。アップグレードではインストール方法に関係なくインストールを行うため、問題が発生することがあります。
  4. 新しいバージョンを構成するには、バックアップされた構成ファイルを使用して変更を新しいバージョンの構成ファイルにマージします。
  5. 2.2.xおよび3.0.xから3.2.xへのアップグレードの場合のみcassandra.yamlファイルを編集して、前のパーティショナーと一致するように、パーティショナー設定を変更します。Apache Cassandra 1.2を使用していたDataStax Enterprise 2.2.xおよび3.0.xでは、RandomPartitioner(org.apache.cassandra.dht.RandomPartitioner)がデフォルトのパーティショナーでした。
  6. 3.1.xから3.2.0へのアップグレードの場合のみ、クラスター内で古いゴシップ・プロトコルを一時的に有効にします。
    新バージョンをインストールした後、各ノードの最初の再起動の前に、アップグレード済みの各ノードが、アップグレード待機中のノードに接続できるように、古いプロトコルを有効にします。パッケージ・インストールの場合は/etc/cassandra/cassandra-env.shに、tarボール・インストールの場合はインストール場所/conf/cassandra-env.shに、以下の行を追加します。
    VM_OPTS="$JVM_OPTS -Denable-old-dse-state=true
    クラスター全体をアップグレードした後、新しいプロトコルを使用できるように各ノードのcassandra-env.shからこの行を削除し、2回目のローリング再起動を実行します。
  7. ノードを起動します。
  8. アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
    nodetool status
  9. 警告、エラー、および例外がないか、ログを確認します。

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

    DataStax Enterprise 3.0.xからのアップグレードでは、予想される以下のエラー・メッセージを無視します。
    • ローリング・アップグレード中にはログに以下のような例外が表示される可能性があります。
      ERROR 15:36:54,908 Exception in thread Thread[GossipStage:1,5,main ]
       java.lang.NumberFormatException: For input string:  "127605887595351923798765477786913079296"
      ...
    • Cassandra 1.2ノードのアップグレード中、新しいsystem_authキースペースにミューテーションをプッシュしようとしているノードに関連するメッセージ:
      ERROR [WRITE-/192.168.123.11] 2013-06-22 14:13:42,336 OutboundTcpConnection.java (line 222)
       error writing to /192.168.123.11
      java.lang.RuntimeException: Can't serialize ColumnFamily ID 2d324e48-3275-3517-8dd5-9a2c5b0856c5
      to be used by version 5, because int <-> uuid mapping could not be established
      (CF was created in mixed version cluster).
      at org.apache.cassandra.db.ColumnFamilySerializer.cfIdSerializedSize(ColumnFamilySerializer.java:196)
    • Solrノードでのアップグレードの場合:
      ERROR 00:57:17,785 Cannot activate core: ks.cf_10000_keys_50_cols
      ERROR 00:57:17,786 <indexDefaults> and <mainIndex> configuration sections are discontinued.
       代わりに、<indexConfig>を使用します。
      ERROR 01:29:55,145 checksum mismatch in segments file (resource: 
        ChecksumIndexInput (MMapIndexInput ( path = "/var/lib/cassandra/data/solr.data/ks.   cf_10000_keys_50_cols/index/segments_6" )))
      ERROR 01:29:55,145 Solr index ks.cf_10000_keys_50_cols seems to be corrupted: 
        please CREATE the core again with  recovery = true to start reindexing data.
      ERROR 01:29:55,145 Cannot activate core: ks.cf_10000_keys_50_cols
      ERROR 01:29:55,146 checksum mismatch in segments file  (resource: ChecksumIndexInput
         (MMapIndexInput ( path = "/var/lib/cassandra/data/solr.data/ks.   cf_10000_keys_50_cols/index/segments_6" )))
      org.apache.lucene.index.CorruptIndexException: checksum mismatch in segments file
         (resource: ChecksumIndexInput (MMapIndexInput
         ( path = "/var/lib/cassandra/data/solr.data/ks.cf_10000_keys_50_cols/index/segments_6" )))
  10. 推奨される順序に従って、クラスター内の各ノードでアップグレードを繰り返します。
    • 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターに進みます。
    • データ・センター内のシード・ノードを最初にアップグレードします。
    • DSE Analyticsノードまたはデータ・センターを最初にアップグレードしてから、Cassandraノードまたはデータ・センター、DSE Searchノードまたはデータ・センターの順にアップグレードします。
    • DSE Analyticsノードでは、Job Trackerノードを最初にアップグレードします。次にHadoopノード、Sparkノードの順にアップグレードします。
  11. 3.1.xから3.2.0へのアップグレードの場合のみ、アップグレード後、各ノードを初めて再起動する前に、アップグレードされた各ノードがアップグレード待ちのノードに接続できるように、古いプロトコルを有効にします。
    1. パッケージ・インストールの場合は/etc/cassandra/cassandra-env.shから、tarボール・インストールの場合はインストール場所/conf/cassandra-env.shから、以下の行を削除します。
      VM_OPTS="$JVM_OPTS -Denable-old-dse-state=true
    2. cassandra-env.shからこの行を削除した後、2度目のローリング再起動を実行します。
  12. 3.0および3.1.xからのアップグレードの場合のみ旧バージョンからアップグレードする場合、最初にアップグレードしたノードはEverywhereStrategyを使用するためにdse_systemを自動的に変更し、nodetool repair dse_systemの実行を試みます。アップグレード中に他のノードがダウンしている場合、この操作は失敗する可能性があります。エラーまたは警告がないか、/var/log/cassandra/system.logを確認してください。自動切り替えが失敗した場合、すべてのノードが起動してから、EverywhereStrategyを使用するように、手動でdse_system keyspaceを更新します。cqlshで以下のように入力します。
    ALTER KEYSPACE dse_system WITH replication = {'class': 'EverywhereStrategy'};
    次に、すべてのノードで以下のコマンドを入力します。
    nodetool repair dse_system
  13. アップグレードに Cassandraのメジャー・バージョンが含まれている場合は、SSTableのアップグレードが必要です。DataStaxでは、一度に1つのノード(ラックを使用している場合は一度に1つのラック)のSSTableをアップグレードすることを推奨します。
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
    nodetool upgradesstables

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

    同時にアップグレードするSSTableの数を設定するには、--jobsオプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。DataStaxでは、一度に1つのノード(ラックを使用している場合は一度に1つのラック)で、upgradesstablesコマンドを実行することを推奨します。

    注: すべてのノードがアップグレードされる前にupgradesstablesコマンドを実行できます。ただし、このコマンドを一度に1つのノード(ラックを使用する場合は一度に1つのラック)のみで実行する場合に限ります。upgradesstablesを実行するノードが多すぎると、パフォーマンスが低下します。