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

• Delete-by-idが削除されました。代わりに、プライマリ・キーによるCQL DELETEを使用してください。
• Delete-by-queryはワイルドカードをサポートしなくなりました。代わりに、CQL TRUNCATEを使用してください。

shard_transport_options: 
    netty_client_request_timeout: 60000

• IsDisjointToはSpatialRecursivePrefixTreeFieldTypeのクエリーに対してはサポートされなくなりました。IsDisjointToはIntersects以外のクエリーに置き換えてください。例を次に示します。

  foo:0,0 TO 1000,1000 AND -"Intersects(POLYGON((338 211, 338 305, 404 305, 404 211, 338 211)))")

• SpatialRecursivePrefixTreeFieldTypeフィールドに対するWKTスタイルのクエリーには、ENVELOPE構文が必要になりました。ENVELOPE(10, 15, 15, 10)と指定する必要があります。以前のリリースのクエリーでは10 10 15 15のように指定できました。

• 次のサポートされていないSolr requestHandlersを削除します。
  • XmlUpdateRequestHandler
  • BinaryUpdateRequestHandler
  • CSVRequestHandler
  • JsonUpdateRequestHandler
  • DataImportHandler

  例を次に示します。

  <requestHandler name="/dataimport" class="solr.DataImportHandler"/>

  または

  <requestHandler name="/update" class="solr.XmlUpdateRequestHandler"/>

• directoryFactoryの以下の部分を変更します。

  <directoryFactory name="DirectoryFactory" class="${solr.directoryFactory:solr.StandardDirectoryFactory}"/>

  以下のように変更します。

  <directoryFactory name="DirectoryFactory" class="solr.StandardDirectoryFactory"/>

• <unlockOnStartup>はLUCENE-6508とSOLR-7942の結果、サポートされなくなりました。
• updateLogの以下の部分を変更します。

  <updateLog class="solr.FSUpdateLog" force="false">

  以下のように変更します。

  <updateLog force="false">

1. クエリー対象のデータ・センター内のノードがすべてアップグレードされるまで、削除されたSolrフィールド型をソートしないようにします。
   ヒント: 2つの検索データ・センターを使用している場合は、1つのデータ・センターに対するクエリーを分離してからスキーマを変更し、もう一方のデータ・センターのインデックスを再作成します。次に、スキーマを変更し、最初のデータ・センターをアップグレードする間に、新たにインデックスを再作成したデータ・センターに対するクエリーを分離します。
2. BCDIntFieldまたはBCDLongFieldを使用している場合は、スキーマを更新し、サポートされているSolr型であるTrieIntFieldおよびTrieLongFieldとソート互換性がある型にBCDIntFieldとBCDLongFieldを置き換えます。

   削除されたSolrフィールド型	ソート互換性がある、サポートされている中間Solrフィールド型
   BCDIntField	SortableIntField
   BCDLongField	SortableLongField

   スキーマを分散的に変更し、インデックスは再作成しません。すべてのノードでスキーマが更新されたら、9に進みます。

• スキーマを更新し、サポートされていないSolrフィールド型をサポートされているSolrフィールド型に置換します。

  削除されたSolrフィールド型	サポートされているSolrフィールド型
  ByteField	TrieIntField
  DateField	TrieDateField
  DoubleField	TrieDoubleField
  FloatField	TrieFloatField
  IntField	TrieIntField
  LongField	TrieLongField
  ShortField	TrieIntField
  SortableDoubleField	TrieDoubleField
  SortableFloatField	TrieFloatField
  SortableIntField	TrieIntField
  SortableLongField	TrieLongField
  BCDIntField	TrieIntField
  BCDLongField	TrieLongField
  BCDStrField（使用されている場合は10を参照）	TrieIntField

• 型マッピング・バージョン0を使用しているか、型マッパーを指定しない場合は、solrconfig.xmlを検証するか、dseTypeMappingVersion 1を使用するように更新します。

  <dseTypeMappingVersion>1</dseTypeMappingVersion>

  SolrコアがCQLテーブルによってサポートされており、型マッピングが指定されていない場合は、型マッピング・バージョン2を使用します。
• コアを再度読み込みます。

  dsetool reload_core keyspace_name.table_name schema=filepath solrconfig=filepath

  サポートされていないデータ型を使用していた場合は、ノードごとにインデックスを完全に再作成します。

  dsetool reload_core keyspace_name.table_name schema=filepath solrconfig=filepath reindex=true deleteAll=true distributed=false

コンパイル・ターゲットを変更するには、ビルド・ファイル内のdse-spark-dependenciesを変更するだけでは十分ではありません。ビルド・ファイルの設定方法については、プロジェクト例を参照してください。

SparkマスターのIPアドレスまたはホスト名を、dse://URLの使用時に指定する必要はなくなりました。Sparkノードに接続すると、要求がマスター・ノードにリダイレクトされます。

たとえば、DSE 5.0で機能していた以下のコードはDSE 5.1以降では機能しません。

val conf = new SparkConf(true) 
.setMaster("spark://192.168.123.10:7077") 
.setAppName("cassandra-demo") 
.set("cassandra.connection.host" , "192.168.123.10") // initial contact 
.set("cassandra.username", "cassandra") 
.set("cassandra.password", "cassandra") 
val sc = new SparkContext(conf)

DSE 6.7に接続するために、setMasterを呼び出す必要はなくなりました。

val conf = new SparkConf(true)
.setAppName("cassandra-demo") 
.set("cassandra.connection.host" , "192.168.123.10") // initial contact 
.set("cassandra.username", "cassandra") 
.set("cassandra.password", "cassandra") 
val sc = new SparkContext(conf)

setMasterを使用してマスターを指定するには、dse:// URL形式を使用してください。

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

• DataStax Enterprise 6.7のリリース・ノート。
• 任意のバージョンのアップグレードに関する一般的なアドバイス。NEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
• DataStax Enterpriseの変更点については、CHANGES.txtに記載されています。
• DataStaxドライバーの変更点。

コア・ストレージ・エンジンのリファクタリングを必要とするために、いくつかの内部およびベータ拡張ポイントが変更されています。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.QueryHandler、org.apache.cassandra.db.commitlog.CommitLogReadHandler、およびその他の拡張ポイントが変更されています。「QueryHandlers」を参照してください。

ALTER TABLE dse_audit.audit_log ADD authenticated text;
ALTER TABLE dse_audit.audit_log ADD consistency text;

nodetool upgradesstables

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

java -version

• 推奨。OpenJDK 8（1.8.0_151以上）
  注: Oracle JRE/JDK 8の公開更新が終了したため、推奨が変更になりました。Oracle Java SE Support Roadmapを参照してください。
• サポートされているもの。Oracle Java SE 8（JREまたはJDK）（1.8.0_151以上）

• shuffleパラメーターをプログラムで設定する場合は、conf.set("spark.shuffle.service.port", port)を使用するアプリケーション用コードを変更する必要があります。代わりに、dse spark-submitを使用します。これによって、認証状態に基づいて正しいサービス・ポートが自動的に設定されます。詳細については、「Sparkの構成」を参照してください。

• 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

• Cassandra File System（CFS）は削除されます。アップグレードの前に、cfsおよびcfs_archiveキースペースを削除します。詳細については、ブログの投稿「From CFS to DSEFS」および「CFSからDSEFSへのデータのコピー」ドキュメントを参照してください。

• DSE 6.7のDSE SearchはApache Solr™ 6.0を使用します。「DSE SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備」のすべての手順を完了します。
• 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を使用する演算子を変更します。

• gremlinを使用して追加した検索インデックスがグラフ・ノードに含まれている場合は、「検索インデックス付きDSE Graphノードをアップグレードするための高度な準備」の手順を完了します。
• エッジ・ラベル名およびプロパティ・キー名が、サポートされている文字のみを使用していることを確認します。エッジ・ラベル名およびプロパティ・キー名に使用できるのは、[a-zA-Z0-9]、アンダースコア、ハイフン、およびピリオドのみです。以前のバージョンでは、エッジ・ラベル名およびプロパティ・キー名で、使用できるUnicodeに制限はほとんどありません。
  • schema.describe()は、不適切な名前がスキーマに含まれている場合でも、スキーマ全体を表示します。
  • インプレースのアップグレードでは、無効なエッジ・ラベル名およびプロパティ・キー名が含まれている既存のスキーマを許可します。
  • 不適切な名前が含まれるスキーマ要素は、更新または追加ができません。

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

nodetool -h hostname drain

• YUMを使用したパッケージ・インストーラー
• APTを使用したパッケージ・インストーラー
• バイナリーtarボール・インストーラー

1. バックアップ 構成 ファイルを新しい構成ファイルと比較します。
   • cassandra.yaml およびdse.yamlの変更を確認します。

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

     cassandra.yaml changes

     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です。

     dse.yaml changes

   • 廃止予定、削除済み、または変更済みの設定を探します。

     シャード・トランスポート

     廃止予定のdse.yaml設定

     shard_transport_options: type: netty netty_server_port: 8984 netty_server_acceptor_threads: netty_server_worker_threads: netty_client_worker_threads: netty_client_max_connections: netty_client_request_timeout: httpトランスポート・タイプが削除されました。 shard_transport_options: type: http http_shard_client_conn_timeout: 0 http_shard_client_socket_timeout: 0

     新しいdse.yaml設定

     shard_transport_options: netty_client_request_timeout: 60000 shard_transport_optionsは、netty_client_request_timeoutのみをサポートします。Remove any other options under shard_transport_optionsの下にある他のオプションをすべて削除します。

     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は、これらのオプションが存在すると起動しません。

     DSE Analyticsノード：DSEFSの設定

     変更されたdse.yaml設定

     DSEFSはデフォルトで有効になっていますが、dsefs.enabled設定はコメント・アウトされています。DSEFSを有効にするには、すべてのdsefs_options設定のコメントを解除します。

   • キースペース・レプリケーション係数が環境に適していることを確認してください。
     • analytics キースペースのキースペース・レプリケーション係数を確認してください。
     • system_authおよびdse_securityキースペースのキースペース・レプリケーション係数を確認してください。
   • アップグレードによって、新しい server.xml がTomcat 8用にインストールされます。既存のserver.xmlにカスタム・コネクターが含まれている場合は、これらのコネクターを新しいserver.xmlに移行してから、アップグレードされたノードを起動してください。
   • 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。

• Analytics Hadoopモードで実行されているデータ・センター内のノードに対し、これらのノードをSparkモードで起動します。
• 特殊な起動時のパラメーターである-Dcassandra.ignore_dc=trueを各ノードに対して追加してから、cassandraモードで起動します。このフラグはアップグレードした後に一度だけ必要です。それ以降の再起動ではこのフラグは使用されません。各ノードを初めて再起動した後は、フラグを構成ファイル内に残しておくことも、削除することもできます。

• パッケージ・インストール
• tarボール・インストール

nodetool status

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

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

nodetool upgradesstables

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

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

• DSE 5.0.xの場合は、5.0.14以降にダウングレード
• DSE 5.1.xの場合は、5.1.12以降にダウングレード

-Dcassandra.commitlog.ignorereplayerrors=true