DataStax Enterprise 4.7または4.8へのアップグレード

DataStax Enterprise 4.0、4.5、または4.6からDataStax Enterprise 4.7または4.8にアップグレードする手順。

DataStax Enterprise 4.0、4.5、または4.6からDataStax Enterprise 4.7または4.8にアップグレードするには、以下の手順に従います。

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

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

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

Cassandraのバージョン変更

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

DataStax Enterprise 4.7へのアップグレードには、Cassandraバージョン2.0から2.1への変更が含まれており、commitlog_total_space_in_mb値のデフォルト値(cassandra.yaml 内)を1024 MBから8192 MBに変更します。環境に合わせてcommitlog_total_space_in_mb設定を調整し、アップグレード後にディスク領域が不足しないようにします。

一般的な推奨事項

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

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

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

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

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

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

4.0、4.5、または4.6から4.7または4.8へのアップグレードの準備

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

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

  2. このリリースの変更点と機能について十分理解してください。
    • DataStax Enterprise 4.7および4.8のリリース・ノート。
    • 任意のバージョンのアップグレードに関する一般的なアドバイス、およびApache Cassandra™ 2.1の新機能については、NEWS.txtに記載されています。NEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
    • Apache Cassandra™での変更点については、CHANGES.txtに記載されています。
    • DataStax Enterprise 4.7または4.8の実稼働環境で認定済みのApache Cassandraに対する変更点。
  3. 現在の製品バージョンを確認します。4.7または4.8にアップグレードする前に、必要に応じて、以下のいずれかの中間バージョンにアップグレードします。
    • DataStax Enterprise 4.0以降
    • DataStax Communityまたはオープン・ソースのApache Cassandra™ 2.0.x
  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 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を使用する必要があります。
  6. nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。
  7. DSE Searchノード:

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

    必要に応じて、schema.xmlに変更を加え、Solrコアを再読み込みします。
  8. 使用する 構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。

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

4.0、4.5、または4.6から4.7または4.8へのアップグレード手順

ヒント: DataStaxインストーラーは、DataStax Enterpriseをアップグレードし、多数のアップグレード・タスクを自動的に実行します。
DataStax Enterprise 4.0、4.5、または4.6からDataStax Enterprise 4.7または4.8にアップグレードするには、各ノード上で以下の手順に従います。
  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ノード:以下の考慮事項を確認して、適切なアクションを実行します。
    • schema.xmldocValuesFormat="Disk"を使用するfieldTypesが含まれる場合、docValuesFormat属性を削除するためにファイルを変更する必要があります。その後、インデックスを再度読み込み、最適化してデフォルトのコーデックに再度書き込みます。これはSolr 4.10以上で必要な作業です。
    • 4.6のクエリー動作を維持するには:

      dse.yamlファイルを編集し、cql_solr_query_paging: offを設定することで、ドライバーのページネーションを無効にします。DataStax Enterprise 4.7または4.8では、ネイティブのドライバー・ページングとSolrのカーソルベースのページングが統合されています(4.74.8)。アップグレードを確認した後、ページングをオンにすることができます。

    • 4.0.0からのアップグレードの場合:特別な手順について「DataStax Enterprise 4.0.0からのアップグレードのための特別な手順」を参照してください。
  4. 次のようにnodetool drainを実行し、古いインストールのコミット・ログをフラッシュします。
    $ nodetool drain -h hostname
    この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。
    重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。
  5. ノードを停止します(4.74.8)。
  6. 適切な方法を使用して、サポートされるプラットフォームに新しい製品バージョンをインストールします。
    注: システム上にある同じインストール・タイプを使用して新しい製品バージョンをインストールします。アップグレードではインストール・タイプに関係なくインストールを行うため、問題が発生することがあります。
  7. 新しい製品バージョンを構成するには:
    1. バックアップ 構成 ファイルを新しい構成ファイルと比較します。
      • 廃止予定、削除済み、または変更済みの設定を探します。
      • 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
    2. 該当する変更を新しいバージョンにマージします。
  8. ノードを起動します。
    • Installer-Servicesおよびパッケージのインストール:「DataStax Enterpriseをサービスとして起動」(4.74.8)を参照してください。
    • Installer-No Servicesおよびtarボールのインストール:「DataStax Enterpriseをスタンドアローン・プロセスとして起動」(4.74.8)を参照してください。
  9. アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
    $ nodetool status
  10. 警告、エラー、および例外がないか、ログを確認します。

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

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

    DataStax Enterprise 4.7および4.8ではCassandra 2.1を使用するため、output.logには次の警告が含まれます。
    • Deprecated cassandra.yaml options are removed
      • multithreaded_compaction
      • memtable_flush_queue_size
      • compaction_preheat_key_cache
      • in_memory_compaction_limit_in_mb
      • preheat_kernel_page_cache
    • cassandra-env.sh

      JVM_OPTS="$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar"

      から次に変更します:

      JVM_OPTS="$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.3.0.jar"

  11. DataStax Enterprise 4.8では、オーディット・ログ・テーブルはDateTieredCompactionStrategy(DTCS)を使用します。前のリリースで作成されたテーブルを変更してDTCSを使用することを推奨します。
    ALTER TABLE dse_audit.audit_log WITH COMPACTION={'class':'DateTieredCompactionStrategy'};
  12. 推奨される順序に従って、クラスター内の各ノードでアップグレードを 繰り返します
  13. 既存のテーブルでDSEインメモリー・オプションを使用する場合:
    1. SSTable圧縮をオフにします。
      ALTER TABLE <tablename> WITH compression = {'sstable_compression' : ''} ;
    2. 圧縮なしで既存のSSTableを再度書き込みます。
      $ nodetool upgradesstables -a <keyspacename> <tablename>

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

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

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

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

アップグレード順序

ノードは以下の順序でアップグレードします。
  • 複数データ・センター・クラスターでは、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を使用します。

cassandra.yaml

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール

/etc/cassandra/cassandra.yaml

tarボール・インストールInstaller-No Servicesインストール

install_location/conf/cassandra.yaml