DataStax Enterprise 5.1から6.7へのアップグレード

DSE 5.1から6.7へのアップグレード手順

logback.xml

logback.xmlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/logback.xml
tarボール・インストール installation_location/resources/cassandra/conf/logback.xml

dse.yaml

dse.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/dse.yaml
tarボール・インストール installation_location/resources/dse/conf/dse.yaml

cassandra.yaml

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra.yaml
tarボール・インストール installation_location/resources/cassandra/conf/cassandra.yaml

アップグレードの順序

ノードは以下の順序でアップグレードします。
  • 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
  • データ・センター内のシード・ノードを最初にアップグレードします。
  • ノードは以下の順序でアップグレードします。
    1. DSE Analyticsデータ・センター
    2. トランザクション/DSE Graphデータ・センター
    3. DSE Searchデータ・センター
OpsCenterバージョン DSEバージョン
6.7 6.7、6.0、5.1
6.5 6.0、5.1、5.0
6.1 5.1、5.0
6.0 5.0

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
追加のドライバーのドキュメント
すべてのドライバー バージョンの互換性

DataStax Enterpriseのアップグレード・プロセスは、ダウンタイムの最小化(ゼロ・ダウンタイムが理想)を実現します。プロセス中、他のノードがオンラインで稼働し続けている状態でノードを1つずつアップグレードして再起動します。若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。

DataStax Enterprise(DSE)5.1からDSE 6.7にアップグレードするには、以下の手順に従います。

すべての変更箇所については、DSE 6.0およびDSE 6.7のリリース・ノートを参照してください。

注: DataStaxインストーラーは、DSE 6.0以降ではサポートされていません。DataStaxインストーラーを使用してインストールされたDSE 5.1からアップグレードするにはまず、スタンドアロン・インストーラーでのインストールから同じバージョンのtarボールまたはパッケージ・インストールに変更する必要があります。「DataStaxインストーラー・インストールからDSE 6.0またはDSE 6.7へのアップグレード」を参照してください。

必ず現行バージョンの最新のパッチ・リリースにアップグレードしてから、新しいバージョンにアップグレードしてください。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが向上するか、スムーズになる場合があります。

DSEの最新の5.1xバージョンは5.1.12です。

重要: アップグレードの前にこれらの手順を読み、理解しておいてください。計画およびアップグレード手順を細かく確認しておくと、スムーズなアップグレードが保証され、不備や不満が生じるのを避けることができます。
重要: Thrift互換テーブル(コンパクト・ストレージ)のサポートが廃止されました。DSE 6.7にアップグレードする前に、コンパクト・ストレージを持つすべてのテーブルをCQLテーブル形式に移行する必要があります。Thrift互換テーブルをCQLテーブル形式に移行するには、ALTER TABLE DROP COMPACT STORAGEコマンドを使用します。このコマンドは、DSE 5.1.6以降で使用できます。

一般的な推奨事項

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

ヒント: OpsCenterでは、Backup Service(バックアップ・サービス)が提供されます。このサービスは、DataStax Enterpriseクラスターの企業全体のバックアップ操作と復元操作を管理します。OpsCenter 6.5以降が推奨されます。

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

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

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

アップグレード・プロセス中の一般的な制限事項
  • 新しい機能を有効にしないでください
  • nodetool repairを実行しないでください。OpsCenter Repair Serviceが構成されている場合は、Repair Serviceをオフにします
  • OpsCenterの互換性を確認してください。DSE 6.7クラスターを管理するには、OpsCenter 6.7が必要です。 互換性テーブルを参照してください。
  • アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
  • ローリング再起動中に、DDLTRUNCATEのような種類のCQLクエリーを実行しないでください。
  • NodeSyncは、すべてのノードがアップグレードされるまで起動を待機します。
  • DSE 5.1.0~5.1.6では、パフォーマンス・オブジェクトによって使用されるデフォルトのスレッドの数は1つです。DSE 5.1.7以降では、パフォーマンス・オブジェクトによって使用されるデフォルトのスレッドの数は4つです。アップグレード中、互換性のあるパフォーマンス・オブジェクトはアップグレード・プロセス中も機能し続けます。スキーマの変更を必要とする互換性のないパフォーマンス・オブジェクトは、レガシー・モードで動作するか、アップグレードが完了してから動作を開始します。アップグレード中に、パフォーマンス・オブジェクトの構成を変更しないでください。パフォーマンス・オブジェクトがアップグレード前に無効になっていた場合は、アップグレード中に有効にしないでください。DSE Performance Service(パフォーマンス・サービス)6.7 | 5.1 | OpsCenterを参照してください。
  • 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
注: アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
DSE拡張レプリケーション・ノードの制限事項
アップグレードは、DSE拡張レプリケーションV2でのみサポートされています。
DSE Analytic(Spark)ノードの制限事項
  • すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
  • SparkワーカーおよびSparkマスターが起動する前にクラスター内のすべてのノードを新しいバージョンにアップグレードしておく必要があります。
DSE Graphノードの制限事項
グラフノードには、実行するワークロードと同じ制限事項があります。アップグレード中はグラフ・スキーマを変更しないでください。アップグレード中にOLAPクエリーを実行しないなどの、ワークロードに固有の制限事項は、analyticsおよびsearchノードに適用されます。
DSE Searchアップグレードの制限事項
  • スキーマを更新しないでください。
  • アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
  • DSE 6.7は、DSE 5.0とは異なるLuceneコーデックを使用しています。この新しいコーデックで書かれたセグメントは、以前のバージョンのDSEでは読み取れません。以前のバージョンにダウングレードするには、問題となる可能性のある検索インデックスのデータ・ディレクトリー全体を消去する必要があります。
任意の種類のセキュリティを使用するノードの制限事項
  • すべてのノードでアップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。
  • Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。参照先: DataStaxドライバーの変更点
クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバーのバージョン互換性の喪失を回避するには、以下の回避策のいずれかを使用してください。
  • プロトコル・バージョン:一部のドライバーでは異なるプロトコル・バージョンを使用できるため、起動時にプロトコル・バージョンを強制します。たとえば、ドライバー・アップグレード中はJavaドライバーを現在のプロトコル・バージョンのままにしておきます。クラスター内のすべてのノードでアップグレードが完了してから、はじめてJavaドライバーを新しいプロトコル・バージョンに切り替えてください。
  • 初期のコンタクト・ポイント:初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。たとえば、初期のコンタクト・ポイントにはJavaドライバーv2のみが含まれます。
プロトコル・バージョンのネゴシエーションの詳細については、ご使用のJavaドライバー・バージョン(たとえばJavaドライバー)の「混在クラスターのあるプロトコル・バージョン」を参照してください。

アップグレードの準備

以下の手順に従い、DSE 5.1からDSE 6.7にアップグレードするために各ノードを準備します。
注: これらの手順は、現在のバージョンで実行され、DSE 5.1のマニュアルを使用します。
  1. DataStax Enterpriseのアップグレードの計画」を注意して確認してください。
  2. ITriggerおよびカスタム・インターフェイスを置き換えます。

    コア・ストレージ・エンジンのリファクタリングを必要とするために、いくつかの内部およびベータ拡張ポイントが変更されています。DSE 6.7にアップグレードする際は、以下のインターフェイスを含むすべてのカスタム実装を、サポート対象の実装に置き換える必要があります。DSE 6.7では、以下のインターフェイスのリライトが必要です。(ご不明な点がある場合は、DataStaxサービス・チームにお問い合わせください。)

    • org.apache.cassandra.triggers.ITriggerインターフェイスは、ノンブロッキング内部アーキテクチャーのためにaugmentからaugmentNonBlockingに変更されました。アップグレードされたノードでは、更新されたトリガーの実装が必要です。わからない場合は、アップグレードの前に既存のトリガーをすべて削除してください。既存のトリガーをチェックするには、次のようにします。
      SELECT * FROM system_schema.triggers
    • org.apache.cassandra.index.Indexインターフェイスは、コア・ストレージ・エンジンの変更に合わせて変更されました。更新された実装が必要です。わからない場合は、アップグレードの前に既存のカスタム・セカンダリ・インデックスをすべて削除してください。ただし、DSE Searchインデックスについては、置き換える必要はないため、削除する必要はありません。既存のインデックスをチェックするには、次のようにします。
      SELECT * FROM system_schema.indexes
    • org.apache.cassandra.cql3.QueryHandlerorg.apache.cassandra.db.commitlog.CommitLogReadHandler、およびその他の拡張ポイントが変更されています。「QueryHandlers」を参照してください。
  3. アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。

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

  4. このリリースの変更点と機能について十分理解してください。
  5. 現在の製品バージョンがDSE 5.1であることを確認してください。
    dse -v
    これらの手順は、DSE 5.1からDSE 6.7へのアップグレードにのみ有効です。
  6. 現行バージョンの最新のパッチ・リリースにアップグレードします。DSEの最新の5.1xバージョンは5.1.12です。

    必ず現行バージョンの最新のパッチ・リリースにアップグレードしてから、新しいバージョンにアップグレードしてください。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが向上するか、スムーズになる場合があります。

  7. 問題の発生の可能性を回避するには、すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
    nodetool upgradesstables

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

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

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

  9. Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
    java -version
    重要: Oracle JRE/JDK 8はサポートされていますが、DataStaxでは、OpenJDK 8でさらに広範なテストを実施しています。
  10. nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。
  11. 最適なパフォーマンスを得るためにlibaioパッケージをインストールしてください。
    RHELプラットフォーム:
    sudo yum install libaio
    Debian:
    sudo apt-get install libaio1
  12. DSE Analyticsノード:
    1. Thrift互換テーブル(コンパクト・ストレージ)のサポートが廃止されました。アップグレードする前に、DSE 5.x.xの実行中に手順に従って、コンパクト・ストレージを持つすべてのテーブルをCQLテーブル形式に移行してください。
      注: system.*テーブルは移行しないでください。コンパクト・ストレージはDSEによって内部で削除されています。
      DSE Analyticsについては、HiveMetaStoreおよびPortfolioDemoキースペース内のすべてのテーブルからコンパクト・ストレージを削除してください。
      コンパクト・ストレージが削除された後、「コンパクト・ストレージからの移行」で説明されているように、CQL互換テーブル形式への移行をサポートするためのカラムが追加されます。
      重要: コンパクト・ストレージ・テーブルが存在すると、DSE 6.0は起動しません。バージョンが混在しているクラスターでのコンパクト・ストレージ・テーブルの作成はサポートされていません。最新のDSE 5.0.xおよびDSE 5.1.xへのドライバー接続は、"NO_COMPACT"モードで実行され、コンパクト・フラグが既に削除されたかのようにコンパクト・テーブルが見えますが、これは現在のセッションの場合のみです。
    2. shuffleパラメーターをプログラムで設定する場合は、conf.set("spark.shuffle.service.port", port)を使用するアプリケーション用コードを変更する必要があります。代わりに、dse spark-submitを使用します。これによって、認証状態に基づいて正しいサービス・ポートが自動的に設定されます。詳細については、「Sparkの構成」を参照してください。
    3. DSEFSが有効であれば、CFS hivemetastoreディレクトリーをdseにコピーします。
      DSE_HOME/bin/dse hadoop fs -cp cfs://127.0.0.1/user/spark/warehouse/ dsefs://127.0.0.1/user/spark/warehouse/
      アップグレードの完了後、Spark SQLテーブル(使用している場合)を新しいHiveメタストア形式に移行します。
      dse client-tool spark metastore migrate --from 5.0.0 --to 6.0.0
    4. Cassandra File System(CFS)は削除されます。アップグレードの前に、cfsおよびcfs_archiveキースペースを削除します。詳細については、ブログの投稿「From CFS to DSEFS」および「CFSからDSEFSへのデータのコピー」ドキュメントを参照してください。
    5. SPARK_LOCAL_DIRSおよびSPARK_EXECUTOR_DIRS環境変数の使用が「環境変数の設定」の説明に従っていることを確認してください。
    6. 互換性のあるSpark Jobserver APIをDataStaxリポジトリで使用しているアプリケーションについては、ジョブをSparkHiveJobおよびSparkSqlJobからSparkSessionJobに移行してください。demosディレクトリーのDemoSparkSessionJobの例を参照してください。
      注: Spark Jobserverは、DSEカスタム・バージョン8.0.4.45です。
      demosディレクトリーの場所は、インストールのタイプによって異なります。
      • パッケージ・インストール:/usr/share/dse/demos
      • tarボール・インストール:installation_location/demos
  13. DSE Searchノード:
    • HTTPの書き込みのすべての使用が、更新および挿入のためのCQLコマンドを使用するように変更されていることを確認します。
    • 検索インデックス構成を編集し、必要に応じて以下の変更を行います。検索インデックスのクエリーの動作を変更するための有効なオプションについては、「検索インデックス構成」を参照してください。
      • サポートされていないdataDirオプションを削除します。検索インデックスの場所の設定は、引き続き行うことができます。
      • mergePolicy、maxMergeDocs、およびmergeFactorを削除します。例を次に示します。
        <mergeFactor>25</mergeFactor>
        <maxMergeDocs>...
        <mergePolicy>...
        代わりにmergePolicyFactoryを使用し、さらにmergeSchedulerを追加します。
        <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler">
            <int name="maxThreadCount">16</int>
            <int name="maxMergeCount">32</int>
        </mergeScheduler>
        ...
        <mergePolicyFactory class="org.apache.solr.index.TieredMergePolicyFactory">
          <int name="maxMergeAtOnce">10</int>
          <int name="segmentsPerTier">10</int>
        </mergePolicyFactory>
      • ExtractingRequestHandlerのインスタンスがある場合は、それを削除します。
      • DSENRTCachingDirectoryFactoryを削除します。次の部分
        <directoryFactory name="DirectoryFactory" class="com.datastax.bdp.search.solr.DSENRTCachingDirectoryFactory"/>
        を以下のように変更します。
        <directoryFactory name="DirectoryFactory" class="solr.StandardDirectoryFactory"/>
    • catalina.propertiesおよびcontext.xmlファイルがTomcat confディレクトリーにあることを確認します。これらのファイルが見つからない場合、DSEは起動しません。
      Tomcat confディレクトリーのデフォルトの場所は、インストールのタイプによって異なります。
      • パッケージ・インストール:/etc/dse/tomcat/conf
      • tarボール・インストール:installation_location/resources/tomcat/conf
    • 以前のDSEバージョンがSolr UI web.xmlのカスタム構成を使用している場合は、次の部分、
      <filter-class>com.datastax.bdp.search.solr.auth.DseAuthenticationFilter</filter-class>
      を、以下のように変更します。
      <filter-class>com.datastax.bdp.cassandra.auth.http.DseAuthenticationFilter</filter-class>
    • StallMetrics MBeanは削除されます。MBeanを使用する演算子を変更します。
  14. DSE Graphノード:
    • エッジ・ラベル名およびプロパティ・キー名が、サポートされている文字のみを使用していることを確認します。エッジ・ラベル名およびプロパティ・キー名に使用できるのは、[a-zA-Z0-9]、アンダースコア、ハイフン、およびピリオドのみです。以前のバージョンでは、エッジ・ラベル名およびプロパティ・キー名で、使用できるUnicodeに制限はほとんどありません。
      • schema.describe()は、不適切な名前がスキーマに含まれている場合でも、スキーマ全体を表示します。
      • インプレースのアップグレードでは、無効なエッジ・ラベル名およびプロパティ・キー名が含まれている既存のスキーマを許可します。
      • 不適切な名前が含まれるスキーマ要素は、更新または追加ができません。

アップグレード手順

DSE 5.1からDSE 6.7へアップグレードするには、推奨される順序に従って、各ノードで次の手順を実行します。 アップグレード・プロセス中、ノードは1つずつアップグレードして再起動してください。
注: これらの手順は、アップグレードされたバージョンで実行され、DSE 6.7のマニュアルを使用します。
  1. 古いインストールのコミット・ログをフラッシュするには、次のようにします。
    nodetool -h hostname drain
    この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。
    重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。
  2. ノードを停止します。「DataStax Enterpriseノードの停止」を参照してください。
    • サービスとして実行しているDataStax Enterpriseを停止する方法:
      sudo service dse stop
    • スタンドアローン・プロセスとして実行しているDataStax Enterpriseを停止する方法:
      bin/dse cassandra-stop
  3. 適切な方法を使用して、サポートされるプラットフォームに新しい製品バージョンをインストールします。
    注: システム上にある同じインストール・タイプを使用して新しい製品バージョンをインストールします。そうでない場合、問題が発生する可能性があります。
  4. 新しいバージョンを構成するには:
    1. バックアップ 構成 ファイルを新しい構成ファイルと比較します。
      • 廃止予定、削除済み、または変更済みの設定をcassandra.yaml およびdse.yamlで探します。

        アップグレード後、6.7.0で再起動する前に、廃止予定の設定を削除して、新しい設定を使用します。

        cassandra.yaml の変更点

        memtableの設定
        廃止予定のcassandra.yaml設定
        memtable_heap_space_in_mb
        memtable_offheap_space_in_mb
        これらは、次の設定に置き換わります。
        memtable_space_in_mb

        自動memtableフラッシュのしきい値を設定するために、ヒープおよびオフヒープのスペース割り当てを制御します。計算されたデフォルトは、ヒープ・サイズの1/4です。

        変更された設定
        memtable_allocation_type: offheap_objects

        データベースがmemtableメモリーの割り当てと管理に使用するデフォルトの方法は、offheap_objectsです。

        ユーザー定義関数(UDF)の設定
        廃止予定のcassandra.yaml設定
        user_defined_function_warn_timeout
        user_defined_function_fail_timeout
        これらは次の設定に置き換わります。
        user_defined_function_warn_micros: 500
        user_defined_function_fail_micros: 10000
        user_defined_function_warn_heap_mb: 200
        user_defined_function_fail_heap_mb: 500
        user_function_timeout_policy: die

        Java UDFの実行が高速であるため、設定はマイクロ秒単位で行います。新しいタイムアウトは廃止された設定と同等ではありません。

        ノード間の暗号化の設定
        廃止されるcassandra.yamlの設定
        server_encryption_options: 
            store_type:JKS
        これらは次の設定に置き換わります。
        server_encryption_options: 
            keystore_type: JKS
            truststore_type: JKS

        有効なタイプのオプションはJKS、JCEKS、PKCS12、またはPKCS11です。

        クライアントとノード間の暗号化の設定
        廃止されるcassandra.yamlの設定
        client_encryption_options: 
            store_type:JKS
        これらは次の設定に置き換わります。
        client_encryption_options: 
            keystore_type: JKS
            truststore_type: JKS

        有効なタイプのオプションはJKS、JCEKS、PKCS12、またはPKCS11です。

        認証情報キャッシュ
        廃止予定のcassandra.yaml設定
        credentials_validity_in_ms
        credentials_update_interval_in_ms
        これらの認証情報キャッシュの設定が存在する場合は、コメント・アウトするか、削除します。キャッシュは、これらの設定がなくても最適化されます。

        dse.yaml の変更点

        Sparkリソースおよび暗号化のオプション
        廃止されるdse.yamlの設定
        spark_ui_options: 
            server_encryption_options: 
            store_type: JKS
        これらは次の設定に置き換わります。
        spark_ui_options: 
            server_encryption_options: 
            keystore_type: JKS
            truststore_type: JKS

        有効なオプションはJKS、JCEKS、PKCS12、またはPKCS11です。

        DSE Searchノード
        廃止予定のdse.yaml設定
        以下のオプションを削除します。
        cql_solr_query_executor_threads
        enable_back_pressure_adaptive_nrt_commit
        max_solr_concurrency_per_core
        solr_indexing_error_log_options 
        DSE 6.7は、これらのオプションが存在すると起動しません。
    2. 該当する変更を新しいバージョンにマージします。
    3. キースペース・レプリケーション係数が環境に適していることを確認してください。
  5. ノードを起動します。
  6. アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
    nodetool status
  7. 警告、エラー、および例外がないか、ログを確認します。

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

  8. 推奨される 順序に従って、クラスター内の各ノードでアップグレードを繰り返します。

    各ノードでのアップグレードおよび再起動は、ローリング再起動と呼ばれます。

コンパクト・ストレージを削除しないでDSE 6.7にアップグレードした後の復元

Thrift互換テーブル(コンパクト・ストレージ)のサポートが廃止されました。DSE 6.7にアップグレードする前に、コンパクト・ストレージを使用しているテーブルをすべて削除するか、CQLテーブル形式に移行する必要があります。クラスターがDSE 6.7にアップグレードされており、コンパクト・ストレージ・テーブルがまだ存在する場合は、この手順に従って復元してアップグレードを進めてください。
  1. 既にDSE 6.7にアップグレードしたノードがあれば、それらを、DSE 5.0または5.1シリーズの最新バージョンにダウングレードします。
    • DSE 5.0.xの場合は、5.0.15以降にダウングレード
    • DSE 5.1.xの場合は、5.1.11以降にダウングレード
  2. DSE 6.7で起動しようとした各ノードで、-Dcassandra.commitlog.ignorereplayerrors=trueオプションを指定してDSEを起動します。
  3. クラスター内の1つのノード(任意のノード)で、コンパクト・ストレージを使用しているテーブルからコンパクト・ストレージを削除します。
  4. DSEを再起動し、DSE 6.7へのアップグレードを続行します。

アップグレード後

すべてのノードをアップグレードしてDSE 6.7で実行したら、以下の手順を完了します。

  1. OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。
  2. DSEインストールのクラスパスから、以前にインストールしたJTS JARファイルをすべて削除します。JTS(Java Topology Suite)はDSE 6.7とともに配布されます。
  3. すべてのノードがDSE 6.7上にあり、必要なスキーマ変更が行われたら、CassandraAuthorizerを使用した新しい許可によって、新しい列の使用が可能になります。
  4. DSE Searchのみ:
    • アペンダーSolrValidationErrorAppenderおよびロガー SolrValidationErrorLoggerは使用されなくなり、logback.xmlから安全に削除される可能性があります。
    • 以前のバージョンと異なり、DataStaxでは、back_pressure_threshold_per_coredse.yaml内)に新しいデフォルト値の1024を使用することを推奨しています。「インデックス作成のパフォーマンスの構成と調整」を参照してください。
    • 大きな暗号化インデックスがある場合にノードでの起動が遅くなる問題は解決されています。ただし、パフォーマンスの向上を実現するためにはアクションが必要です。お使いのクラスターの各ノードで、すべての暗号化検索インデックスを完全に再作成する必要があります。アップグレードが完了したら、ローリング方式でdeleteAll=trueを使用してインデックスを再作成するための時間を十分に取ってください。例を次に示します。
      dsetool reload_core keyspace_name.table_name distributed=false reindex=true deleteAll=true 
  5. DSE Analyticsのみ:
    • dse_analyticsキースペースのレプリケーション係数を確認してください。新しいキースペースにDSE Analyticsのすべての内部システム・データが格納されます。DataStaxでは、レプリケーション・ストラテジを、各DSE Analyticsデータ・センターで少なくとも3のレプリケーション係数を持つNetworkTopologyStrategy(NTS)に設定することを推奨しています。データ・センターにさらに多くのノードがある場合は、より大きなレプリケーション係数を検討する必要があります。
    • Spark Jobserverは、DSEカスタム・バージョン0.8.0.45を使用します。アプリケーションでは、DataStaxリポジトリから互換性のあるSpark Jobserver APIを使用する必要があります。

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

エラー・メッセージには、問題の特定に役立つ情報が記載されます。アップグレード中およびアップグレード後に表示される一部のログ・メッセージは無視できます。
  • DSE 6.7では、以前のバージョンのDSEの一部のgremlin_serverプロパティは不要になりました。DSE 6.7へのアップグレード後、プロパティが dse.yaml ファイルに存在する場合、ログに以下のような警告が表示されます。
    WARN  [main] 2017-08-31 12:25:30,523 GREMLIN DseWebSocketChannelizer.java:149 - Configuration for the org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0 serializer in dse.yaml overrides the DSE default - typically it is best to allow DSE to configure these.
    これらの警告を無視するか、dse.yamlを変更して必要なgremlinサーバーのプロパティのみが存在するようにすることができます。