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

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

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

dse.yaml

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

パッケージ・インストール
                  Installer-Servicesのインストール(DSE 4.5~5.1)

/etc/dse/dse.yaml

tarボール・インストール
                   Installer-No Servicesのインストール(DSE 4.5~5.1)

install_location/resources/dse/conf/dse.yaml

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.yaml

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

パッケージ・インストール
                  Installer-Servicesのインストール(DSE 4.5~5.1)

/etc/cassandra/cassandra.yaml

tarボール・インストール
                   Installer-No Servicesのインストール(DSE 4.5~5.1)

install_location/conf/cassandra.yaml

server.xml

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

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を使用します。

アップグレードの順序

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

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

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

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

警告: TTLの期限切れのタイムスタンプは、2038年問題の影響を受けやすくなります。TTL値が長く、最大しきい値の2038-01-19T03:14:06+00:00より大きい期限切れの日付である場合、そのデータはすぐに期限切れとなり、次のコンパクションでパージされます。DataStaxでは、 気付かないうちにデータがなくならないように、DSE 5.1.7以降にアップグレードし、必要な措置を講じることを強く推奨します。(DSP-15412)。
重要: アップグレードの前にこれらの手順を読み、理解しておいてください。計画およびアップグレード手順を細かく確認しておくと、スムーズなアップグレードが保証され、不備や不満が生じるのを避けることができます。

Apache Cassandraのバージョン変更

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

一般的な推奨事項

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

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

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

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

これらの例外により、クラスター内のすべてのノードがアップグレードされるまで、クラスターは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がアップグレードされるまで完了しません。
DSE 5.0.10以降からアップグレードする場合の制限事項
重要: 5.1.3より前のDSEバージョンへのアップグレードは推奨されません。以下を参照してください。
DSE 5.1.3にアップグレードする際の制限事項
  • ビュー行の活性は、フィルターが適用された複数のベース非キー・カラムと、ビューのプライマリ・キーで使用されているベース非キー・カラムに依存するため、非プライマリ・キー・ベース・カラム(CASSANDRA-10368)にフィルターを適用したマテリアライズド・ビューの作成は無効になっています。このセマンティクスは、ストレージ形式を変更しなければサポートされません(CASSANDRA-13826)。追加書き込みのみのユース・ケースの場合は、システム・プロパティ・スイッチでこの機能を使用できます。
    -Dcassandra.mv.allow_filtering_nonkey_columns_unsafe=true
  • テーブルsystem_auth.resource_role_permissons_indexは使用されなくなったため、すべてのノードが5.1.3になったら削除する必要があります。
  • nodetool repairでオプションが指定されていない場合は、リペア対象のテーブル/キースペースで既にインクリメンタル・リペアが実行されていない限り、後方互換性を保つためにインクリメンタル以外のフル・リペアがデフォルトになります。新しいテーブルでインクリメンタル・リペアを実行するには、-incオプションを使用します。
DSE Analytic(Spark)ノードの制限事項
  • すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
  • ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。
DSEFSに関する制限事項
DSE 5.1.3以降へのアップグレード・プロセス中、バージョンの混在はサポートされていません。
  • すべてのノードでのアップグレードを完了してからfsckを実行してください。DSE 5.1.3以降では、fsckを実行しているノードに対して、すべてのノードが適切なブロック・ステータスを報告できる必要があります。バージョンが混在しているクラスターでアップグレードされたノードに対してfsckを実行する場合、DSE 5.1.3より前のバージョンのノードはブロック・ステータスを適切に報告せず、データが破損しているか使用できないとfsckが誤って解釈することになります。fsckは誤った方法でノードのリペアを試みます。
  • DSE 5.1.3のプロトコルの変更により、DSEFSサーバーとクライアント間でのJSON配列のやり取りの効率が向上します。DSEFSシェルを使用して、クラスター内のすべてのノードをアップグレードします。
DSE Graphに関する制限事項
グラフノードには、実行するワークロードと同じ制限事項があります。アップグレード中にグラフ・スキーマを変更しないなどの、一般的なグラフの制限事項がすべてのノードに適用されます。アップグレード中にOLAPクエリーを実行しないなどの、ワークロードに固有の制限事項は、analyticsおよびsearchノードに適用されます。
DSE Searchに関する制限事項
DataStax Enterprise 5.1のDSE SearchはApache Solr 6.0を使用します。この大幅な変更により、アップグレードの前後で、事前の計画と特定の措置が求められます。
重要: DSE SearchまたはSearchAnalyticsワークロードをアップグレードする前に、「DSE SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備」の特定の手順に従う必要があります。
任意の種類のセキュリティを使用するノードの制限事項
  • すべてのノードでアップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。
  • Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
セキュリティの変更
DSE 5.1にアップグレードした後のデフォルトのオーセンティケーターはDseAuthenticatorで、デフォルトのオーソライザーはcassandra.yaml内のDseAuthorizerです。他のオーソライザーやオーセンティケーターはサポートされなくなりました。「アップグレード後」の手順に従ってください。
注: アップグレード後、DataStaxでは、オーセンティケーター設定をcassandra.yaml 内ではDseAuthenticatorにすることをお勧めします。

内部認証スキーマは、PasswordAuthenticatorと互換性がありますが、DSE統合認証で提供されている高度なセキュリティ機能はサポートされていません。

ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。参照先: DataStaxドライバーの変更点
クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバーのバージョン互換性の喪失を回避するには、以下の回避策のいずれかを使用してください。
  • プロトコル・バージョン:一部のドライバーでは異なるプロトコル・バージョンを使用できるため、起動時にプロトコル・バージョンを強制します。たとえば、ドライバー・アップグレード中はJavaドライバーを現在のプロトコル・バージョンのままにしておきます。クラスター内のすべてのノードでアップグレードが完了してから、はじめてJavaドライバーを新しいプロトコル・バージョンに切り替えてください。
  • 初期のコンタクト・ポイント:初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。たとえば、初期のコンタクト・ポイントにはJavaドライバーv2のみが含まれます。
プロトコル・バージョンのネゴシエーションの詳細については、ご使用のJavaドライバー・バージョン(たとえばJavaドライバー)の「混在クラスターのあるプロトコル・バージョン」を参照してください。

DSE SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備

アップグレードの準備」の手順を開始する前に、DSE 5.0をまだ実行している間に、DSE SearchおよびSearchAnalyticsノードに対して行う高度な準備手順をすべて完了します。

アップグレード前に、必要な変更を実装し、テストするための十分な時間を確保してください。
  • スキーマを変更するには、インデックスを完全に作成し直す必要があります。
  • 構成の変更にはコアの再読み込みが必要です。
  1. SolrコアがDSE 4.6以前のバージョンで作成されており、DSE 4.7以降にアップグレードした後にインデックスが再作成されていない場合は、DSE 5.0でインデックスを再作成してからDSE 5.1にアップグレードする必要があります。
  2. shard_transport_optionsdse.yaml 内でnetty_client_request_timeoutに対してのみ設定されていることを確認してください。
    shard_transport_options: 
        netty_client_request_timeout: 60000
    DSE 5.1のシャード・トランスポート・オプションは、netty_client_request_timeoutのみをサポートしています。他のshard_transport_optionsは削除してください。
  3. catalina.propertiesおよびcontext.xmlファイルがTomcat confディレクトリーにあることを確認します。これらのファイルが見つからない場合、DSEは起動しません。
    Tomcat confディレクトリーのデフォルトの場所は、インストールのタイプによって異なります。
    • パッケージ・インストール:/etc/dse/tomcat/conf
    • tarボール・インストール:installation_location/resources/tomcat/conf
  4. Apache Solr SolrJを使用している場合、必要な最小バージョンは6.0.0です。
  5. 検索スキーマ内のSpatialRecursivePrefixTreeFieldType(RPT)に対しては、次の変更に合わせてクエリーを調整する必要があります。
    • 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のように指定できました。
    空間クエリーでdistanceUnitsを使用した場合の詳細については、「空間検索」を参照してください。
  6. Stored=trueコピー・フィールドはサポートされておらず、スキーマの検証は失敗に終わります。stored=true copyFieldディレクティブはDSE 4.7からサポートされていないため、Stored=trueコピー・フィールドは使用していないはずです。使用している場合:
    • schema.xmlファイル内のすべてのcopyFieldディレクティブのstored属性値をtrueからfalseに変更してから、dsetool reload_coreを使用して変更されたスキーマを再度読み込みます。
    • アプリケーションの設計と実装でこの変更が認識されるようにする必要があります。
  7. solrconfig.xmlファイルを編集し、必要に応じて以下の変更を行います。
    • requestHandlers(XmlUpdateRequestHandler、BinaryUpdateRequestHandler、CSVRequestHandler、JsonUpdateRequestHandler、DataImportHandler)を削除します。Solrでは、これらのrequestHandlersは廃止され削除されました。

      例を次に示します。

      <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-6508SOLR-7942の結果、サポートされなくなりました。
    • updateLogの以下の部分を変更します。
      <updateLog class="solr.FSUpdateLog" force="false">
      以下のように変更します。
      <updateLog force="false">
  8. DSE searchノードをDSE 5.1にアップグレードするには、サポートされていないSolr型をサポートされている型に置換する必要があります。
    注: BCDStrFieldに対しても特別な取り扱いが必要です。これについては10で説明されています。
    削除された一部のSolr型は、分散クエリー中に値をマーシャルソートする方法が原因で(推奨される新しい型によって値がアンマーシャルソートされる方法との兼ね合いで)、一部のノードがサポートされていない型を使用し、他のノードが推奨される新しい型を使用する場合には、ローリング・アップグレード中にソートできません。次の型の移行では問題が生じる場合があります。
    削除されたSolrフィールド型 サポートされているSolrフィールド型
    ByteField TrieIntField
    DateField TrieDateField
    BCDIntField TrieIntField
    BCDLongField TrieLongField
    以下の2つのオプションを使用できます。
    1. クエリー対象のデータ・センター内のノードがすべてDSE 5.1にアップグレードされるまで、削除されたSolrフィールド型をソートしないようにします。
      ヒント: 2つの検索データ・センターを使用している場合は、1つのデータ・センターに対するクエリーを分離してからスキーマを変更し、もう一方のデータ・センターのインデックスを再作成します。次に、スキーマを変更し、最初のデータ・センターをアップグレードする間に、新たにインデックスを再作成したデータ・センターに対するクエリーを分離します。
    2. BCDIntFieldまたはBCDLongFieldを使用している場合は、スキーマを更新し、サポートされているSolr型であるTrieIntFieldおよびTrieLongFieldとソート互換性がある型にBCDIntFieldとBCDLongFieldを置き換えます。
      削除されたSolrフィールド型 ソート互換性がある、サポートされている中間Solrフィールド型
      BCDIntField SortableIntField
      BCDLongField SortableLongField
      スキーマを分散的に変更し、インデックスは再作成しません。すべてのノードでスキーマが更新されたら、9に進みます。
  9. Solr 5.5以降から削除されているSolrフィールド型に対してスキーマと構成を更新します。
    • スキーマを更新し、サポートされていない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 5.1では、自動生成されたスキーマはデータ型マッパー2を使用します。
  10. BCDStrFieldを使用している場合:DSE 5.0以前では、DSEはCassandraテキスト・カラムをBCDStrFieldにマッピングしていました。BCDStrFieldは廃止され、DSE 5.1.0で削除されています。
    推奨される戦略は、データ型をTrieIntFieldにアップグレードすることです。ただし、DSEではテキストをTrieIntFieldに直接マッピングできません。BCDStrFieldを使用している場合は、以下のいずれかのオプションを完了してからアップグレードする必要があります。
    1. BCDStrFieldが使用されなくなった場合は、BCDStrFieldフィールドをSolrスキーマから削除します。インデックスの再作成は不要です。
    2. フィールドのインデックスをTrieIntFieldとして作成する必要があり、インデックスの完全な再作成が可能な場合は、基になるデータベース・カラムを変更してint型を使用します。
    3. データベース・カラムをテキストのまま保持しながらインデックス付きのフィールドで単純な一致クエリーを実行する場合は、スキーマ内のBCDStrFieldをStrFieldに切り替えます。インデックスの作成は必須ではありませんが、このフィールドは数値範囲クエリーまたはソートに適さなくなります。StrFieldは数値順序ではなく辞書式順序を使用するためです。
    4. この方法は推奨されません:データベース・カラムをテキストのまま保持しながら、以前のBCDStrFieldに対して数値範囲クエリーやソートを実行する必要があるが、完全にインデックスを再作成するのではなくアプリケーションを変更したい場合:
      • indexed=falseを指定して、Solrスキーマ内のフィールドをStrFieldに変更します。
      • 元のBCDStrFieldから提供された値を持つTrieIntField型を指定した新しいコピー・フィールドを追加します。
      コピー・フィールドのターゲットにデータを追加する必要があるため、このソリューションには、依然としてインデックスの再作成が必要です。この非推奨オプションは、次善のデータ・モデルをサポートするためにのみ提供されています。たとえば、intのみに収まる値があるテキスト・カラムなどです。
    これらのスキーマの変更を行った後は、reindex=true、distributed=false、およびdeleteAll=trueを指定して、ノードごとにローリングdsetool reload_coreを実行します。
    注: データ・センターが2つあり、これらを1つずつアップグレードする場合は、distributed=true deleteAll=trueを指定してコアを再度読み込みます。
  11. アップグレードの前にスキーマを調整してください。DSE 5.1.4以降では、フィールドにインデックスが付いていなくても、スキーマ内のすべてのフィールド定義が検証され、DSE Searchと互換性があり、docValuesが適用されるか、コピー・フィールド・ソースに使用される必要があります。自動リソース生成のデフォルトの動作には、すべてのカラムが含まれます。パフォーマンスを改善するには、フィールドがデータベースから読み込まれないように対策を講じます。スキーマ内の使用されていないフィールドを削除するかコメント・アウトして、スキーマ内の必要なフィールドのみを含めます。

検索インデックス付きDSE Graphノードをアップグレードするための高度な準備

以下の手順は検索インデックスを含むグラフ・ノードに適用されます。「アップグレードの準備」の手順を開始する前に、DSE 5.0をまだ実行している間に、高度な準備手順をすべて完了します。

検索インデックスを含むDSE Graphノードをアップグレードするには、solrconfigファイルを以下のように編集する必要があります。構成の変更にはコアの再読み込みが必要です。アップグレード前に、必要な変更を実装し、テストするための十分な時間を確保してください。

solrconfig.xmlファイルを編集し、必要に応じて以下の変更を行います。
  • requestHandlers(XmlUpdateRequestHandler、BinaryUpdateRequestHandler、CSVRequestHandler、JsonUpdateRequestHandler、およびDataImportHandler)を削除します。Solrでは、これらのrequestHandlersは廃止され削除されました。

    例を次に示します。

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

    または

    <requestHandler name="/update" class="solr.XmlUpdateRequestHandler">/>
  • <unlockOnStartup>はLUCENE-6508SOLR-7942の結果、サポートされなくなりました。
  • コアを再度読み込んで、この構成の変更を適用します。
    dsetool reload_core keyspace_name.table_name reindex=false

DSE Analyticsノードをアップグレードするための高度な準備

DSE 5.1には、Spark 2.0へのメジャー・アップグレードに加えて、DSEおよびSpark間の緊密な統合が含まれています。Spark 2.0の詳細については、Sparkのドキュメントを参照してください。Spark 2.0はScala 2.11を使用しています。

DSE 5.1には、DataStax Java Driverと、DSE Sparkノード間の通信を管理するためのネイティブのCQLプロトコルを使用する新しいSparkリソース・マネージャーが含まれています。DSE 5.0ではSpark RPCを使用していました。これは、DSE 5.0で実行されていたSparkアプリケーションに影響を及ぼします。
  1. Spark 2.0はScala 2.11を使用しています。すべてのDSE 5.0 Scala Sparkアプリケーションは、Scala 2.11に対してリコンパイルし、Scala 2.11のサードパーティ・ライブラリのみを使用する必要があります。

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

  2. Sparkアプリケーションは、dse://URLを使用する必要があります。これは、「Spark URLの指定」で説明しているように、spark://spark master IP:Spark RPC port number URLの代わりです。

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

  3. 接続の目的でspark://Spark master IP:Spark RPC portを使用する既存の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)

    5.1でDSEに接続するために、setMasterを呼び出す必要はなくなりました。このコードはDSE 5.1で機能します。

    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形式を使用してください。

  4. DSE 5.1以降では、Sparkジョブを特定のデータベースのロールに制限できます。「DSE Sparkアプリケーションのパーミッションの設定」を参照してください。
  5. 個別のユーザーとしてのSparkプロセスの実行」で説明されているように、DSE 5.1以降では、Sparkエグゼキューター・プロセス所有者を設定できます。
  6. Sparkアプリケーションを送信するユーザーを同じデータベース・ロールにする必要はなくなりました。マスター接続送信を変更して、データベース接続とは異なるユーザーまたはクラスターを使用する方法については、「Sparkアプリケーションのパーミッションの管理」を参照してください。
DSEFSデータのバックアップ

以下の手順はDSEFSを使用するノードのみに適用されます。アップグレードの準備の手順を開始する前に、以下の高度な準備手順を完了してください。

データベースで使用されるDSEFSスキーマはDSE 5.1で向上していますが、以前のスキーマも引き続きサポートされており、アップグレード中に変更されることはありません。既存のDSEFSデータで新しいDSEFSスキーマを使用するには、DSEFSデータをバックアップしてからアップグレードする必要があります。

dse hadoop fs -cpコマンドを使用して現在のDSEFSデータをローカル・ストレージにバックアップします。

dse hadoop fs -cp /* /local_backup_location

アップグレードの準備

以下の手順に従い、DataStax Enterprise 5.0からDataStax Enterprise 5.1にアップグレードするために各ノードを準備します。
注: これらの手順は、現在のバージョンで実行され、DSE 5.0のマニュアルを使用します。
  1. 現行バージョンの最新のパッチ・リリースにアップグレードします。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが簡略化される場合があります。
  2. アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。

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

  3. このリリースの変更点と機能について十分理解してください。
  4. 現在の製品バージョンを確認します。必要に応じて、中間バージョンにアップグレードします。
    現在のバージョン アップグレード・バージョン
    DataStax Enterprise 5.0 DataStax Enterprise 5.1
    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 DataStax Enterprise 5.1
    Apache Cassandra 3.xのDataStaxディストリビューション DataStax Enterprise 5.0
  5. すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
    nodetool upgradesstables
    これは、 Cassandraのメジャー・バージョン の変更を含むDataStax Enterpriseのアップグレードに必要です。
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。

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

  6. Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
    java -version
    JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。
    重要: Oracle JRE/JDK 8はサポートされていますが、DataStaxでは、DSE 5.1.11で起動するOpenJDK 8でさらに広範なテストを実施しています。
  7. nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。
  8. DSE Analyticsノード:shuffleパラメーターをプログラムで設定する場合は、conf.set("spark.shuffle.service.port", portを使用するアプリケーション用コードを変更する必要があります。代わりに、dse spark-submitを使用します。これによって、認証状態に基づいて正しいサービス・ポートが自動的に設定されます。「Spark構成」を参照してください。
  9. DSE Searchノード: DataStax Enterprise 5.1のDSE SearchはApache Solr 6.0を使用します。この大幅な変更により、アップグレードの前後で、事前の計画と特定の措置が求められます。DSE SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備」のすべての手順を完了します。
  10. DSE Graphノード:gremlinを使用して追加した検索インデックスがグラフ・ノードに含まれている場合は、「検索インデックス付きDSE Graphノードをアップグレードするための高度な準備」の手順を完了します。
  11. 使用する 構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。

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

  12. 5.0.0から5.0.8ならびにDSE 5.1.0および5.1.1からDSE 5.1.2およびそれ以降のDSE 5.1.xリリースへのアップグレード

    DSE 5.1.2のメッセージング・プロトコル・バージョンは、VERSION_3014に変更されています。スキーマの移行は正確なメッセージング・プロトコル・バージョンに依存します。アップグレード中に発生する可能性のあるスキーマの変更に対応するには、後方互換性メッセージング・プロトコルを強制的に使用します。

    アップグレードに、次の起動時のパラメーターを使用してノードを再起動します。
    -Dcassandra.force_3_0_protocol_version=true
    例を次に示します。
    installation_location/bin/dse cassandra -Dcassandra.force_3_0_protocol_version=true
    注: アップグレード時にはバージョンが混在しますが、既存のテーブルのカラムを追加したり削除したりしないでください。

    すべてのノードでアップグレードが完了したに、このフラグを使用せずにノードを再起動します。

アップグレード手順

ヒント: DataStaxインストーラーは、DataStax Enterpriseをアップグレードし、多数のアップグレード・タスクを自動的に実行します。
DataStax Enterprise 5.0からDataStax Enterprise 5.1にアップグレードするには、各ノードで以下の手順に従います。
注: これらの手順は、アップグレードされたバージョンで実行され、DSE 6.7のマニュアルを使用します。
注: アップグレード中およびアップグレード後に表示される警告メッセージの一部は無視してかまいません。
  1. DSE Analyticsノード:すべてのSparkワーカー・プロセスを強制終了します。
  2. 古いインストールのコミット・ログをフラッシュするには、次のようにします。
    nodetool -h hostname drain
    この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。
    重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。
  3. ノードを停止します
  4. 適切な方法を使用して、サポートされるプラットフォームに新しい製品バージョンをインストールします。

    各インストール方法のインストール手順を読んで従ってください。

    注: システム上にある同じインストール方法を使用して新しい製品バージョンをインストールします。アップグレードではインストール方法に関係なくインストールを行うため、問題が発生することがあります。
  5. 新しい製品バージョンを構成するには:
    1. バックアップ 構成 ファイルを新しい構成ファイルと比較します。
      • 廃止予定、削除済み、または変更済みの設定を探します。
        注: DSE 5.1.0ではDSEFSはデフォルトで有効になっていますが、新しいDSE 5.1.0 dse.yamlファイルではdsefs.enabled設定はコメント・アウトされています。DSEFSを有効にするには、DSE 5.1.0にアップグレードした後にdsefs_options.enabled設定のコメントを解除します。(DSP-13310)
      • アップグレードによって、新しい server.xml がTomcat 8用にインストールされます。既存のserver.xmlにカスタム・コネクターが含まれている場合は、これらのコネクターを新しいDSE 5.1のserver.xmlに移行してから、アップグレードされたノードを起動してください。
      • 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
      • キースペース・レプリケーション係数が環境に適していることを確認してください。
    2. 該当する変更を新しいバージョンにマージします。
  6. DSE Analyticsノード:
    DSE 5.1以降は、analyticsノードをSparkモードで実行します。DSE 5.0クラスターに、Analytics Hadoopモードで実行されているデータ・センターが存在し、DseSimpleSnitchが使用されていた場合は、以下のいずれかを実行する必要があります。
    • Analytics Hadoopモードで実行されているデータ・センター内のノードに対し、これらのノードをSparkモードで起動します。
    • 特殊な起動時のパラメーターである-Dcassandra.ignore_dc=trueを各ノードに対して追加してから、cassandraモードで起動します。このフラグはDSE 5.1にアップグレードした後に一度だけ必要です。それ以降の再起動ではこのフラグは使用されません。各ノードを初めて再起動した後は、フラグを構成ファイル内に残しておくことも、削除することもできます。
  7. ノードを起動します。
  8. アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
    nodetool status
  9. 警告、エラー、および例外がないか、ログを確認します。

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

  10. 推奨される 順序に従って、クラスター内の各ノードでアップグレードを繰り返します。
  11. アップグレードに Cassandraのメジャー・バージョンが含まれている場合は、SSTableのアップグレードが必要です。DataStaxでは、一度に1つのノード(ラックを使用している場合は一度に1つのラック)のSSTableをアップグレードすることを推奨します。
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
    nodetool upgradesstables

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

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

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

アップグレード後

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

  1. セキュリティ構成を確認します。セキュリティを使用するには、DSE Unified Authenticationを有効にして構成します。

    cassandra.yamlでは、デフォルトのオーセンティケーターはDseAuthenticatorで、デフォルトのオーソライザーはDseAuthorizerです。他のオーセンティケーターやオーソライザーはサポートされなくなりました。dse.yaml内ではセキュリティはデフォルトで無効になっています。

  2. TimeWindowCompactionStrategy(TWCS)は新しいdse_perfテーブルのみで設定されます。前のリリースで作成されたdse_perfテーブルを手動で変更して、TWCSを使用します。例を次に示します。
    ALTER TABLE dse_perf.read_latency_histograms WITH COMPACTION={'class':'TimeWindowCompactionStrategy'};
  3. OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。
  4. DSE Searchのみ:
    • インデックス作成時のブーストのサポートは、DSE 5.1.1以降はなくなります。代わりにクエリー時のブーストを使用してください。バッキングCQLテーブルに_docBoostカラムがある場合は、それらを削除します。

      _docBoostカラムが存在していたThriftテーブルは許容されますが、_docBoostは無視されます。Thriftテーブルはこのカラムを削除できません。

    • SpatialRecursivePrefixTreeFieldType(RPT)を検索スキーマで使用する場合は、単位のフィールド型を適切な(度、キロメートル、またはマイル)distanceUnitsに置換してから、空間クエリーが期待どおりに動作することを確認します。
    • マルチポリゴン・シェイプのインデックスを最適化するには、useJtsMulti="false"を設定する必要があります。例を次に示します。
      <fieldType autoIndex="true" useJtsMulti="false" 
      class="solr.SpatialRecursivePrefixTreeFieldType" distErrPct="0.0125" 
      distanceUnits="kilometers" geo="true" name="WktField" spatialContextFactory="org.locationtech.
      spatial4j.context.jts.JtsSpatialContextFactory"/>
  5. DSE 5.1.6以降の場合のDSE Searchのみ
    • 大きな暗号化インデックスがある場合にノードでの起動が遅くなる問題は解決されています。ただし、パフォーマンスの向上を実現するためにはアクションが必要です。お使いのクラスターの各ノードで、すべての暗号化検索インデックスを完全に再作成する必要があります。アップグレードが完了したら、ローリング方式でdeleteAll=trueを使用してインデックスを再作成するための時間を十分に取ってください。例を次に示します。
      dsetool reload_core keyspace_name.table_name distributed=false reindex=true deleteAll=true 
    • JSONドキュメントでのHTTP書き込み(廃止予定)を使用している場合にのみ適用されます。5.1.0へのアップグレード後、既知の問題により、自動生成されたsolrconfig.xmlのrequestHandlerがJSONコアの作成に対して無効になります。自動生成されたsolrconfig.xmlの以下の部分を変更します。
      <requestHandler name="/update/json" class="solr.UpdateUpdateRequestHandler" startup="lazy"/>
      以下のように変更します。
      <requestHandler name="/update/json" class="solr.UpdateRequestHandler" startup="lazy"/>
  6. DSEFSのみ:新しいスキーマがDSEFSに対して用意されています。
    警告: キースペースを削除すると、バックアップがない限り復元できません。一時データ以外のデータがある場合は、dsefsキースペースを削除しないでください。アクションは不要です。DSEFSは引き続きDSE 5.0スキーマを使用して機能します。
    DSEFSにデータがないか、一時データに対してのみDSEFSを使用している場合は、以下の手順に従って新しいスキーマを使用します。
    1. すべてのノードでDSEFSを停止します。dse.yamldsefs_optionsセクションで、enabled: falseを設定します。
    2. dsefsキースペースを削除します。
      DROP KEYSPACE dsefs
    3. 各ノードでdsefsデータ・ディレクトリーを消去します。
      たとえば、dse.yamlのdsefs_optionsセクションに次のように構成されているdata_directoriesがあるとします。
      dsefs_options: 
           ...
           data_directories: 
               - dir: /var/lib/dsefs/data
      このコマンドは以下のディレクトリーを削除します。
      rm -r /var/lib/dsefs/data/*
    4. DSE 5.1でDSEFSを起動して、新しいスキーマを使用します。
    5. アップグレード前に既存のDSEFSデータをバックアップした場合は、ローカル・ストレージからデータをDSEFSにコピーして戻します。
  7. DSE Analyticsのみ:Spark SQLテーブルを使用している場合は、dse spark-sql-metastore-migrateコマンドを使用して、Spark SQLで使用されている新しいHiveメタストア形式にこのテーブルを移行します。
    dse spark-sql-metatore-migrate
  8. DSE Advanced Replicationのみ:DSE Advanced Replicationは大幅に改訂されているため、DSE 5.1の新しいバージョンに移行する必要があります。V1とV2の両方はDSE 5.1で並行して実行され、移行されます。
    1. V1で構成されているハブに対してV2の移行先を作成します。
      dse advrep destination create --name upgradedest --addresses 10.200.100.250 --transmission-enabled falase
    2. 各V1チャネルに対応するV2チャネルを作成します。
      dse advrep channel create --source-keyspace demo --source-table sensor_readings --destination upgradedest --source-id edge1 --source-id-column hub_id --priority 1
    3. 収集と転送を再開します。
      dse advrep channel resume --source-keyspace demo --source-table sensor_readings --collection-enabled true --transmission-enabled true 
    4. V2が実行され、レプリケートされていることを確認してから、V1チャネルでの収集を無効にします。
      dse advrep --v1 edge channel pause --keyspace demo --table sensor_readings
    5. ゼロ・カウントを確認することで、V1がV1レプリケーション・ログをドレーンするまで待機します。
      dse advrep --v1 edge rl-count
    6. V1チャネルを削除し、V1ハブを無効にします。
      for f in `dse advrep --v1 edge list-conf|cut -f1 -d' '|sed 1,2d | sed s/_/-/g`; do dse advrep --v1 edge remove-conf --$f; done;

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

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

  • DSE Advanced Replicationを含むノードをアップグレードする際に、ノードのバージョンが混在している場合、ローリング・アップグレード中にWriteTimeoutExceptionが発生することがあります。ノードのバージョンが混在している間は、書き込みの整合性の制限がいくつか適用されます。WriteTimeoutの問題は、すべてのノードがアップグレードされると解決されます。
エラー・メッセージには、問題の特定に役立つ情報が記載されます。
  • 次のようなエラー・メッセージが表示された場合:
    ERROR [main] 2016-07-21 13:52:46,941  CassandraDaemon.java:737 - Cannot start node if snitch's data center (Cassandra) differs from previous data center (Analytics).Please fix the snitch configuration, decommission and rebootstrap this node or use the flag -Dcassandra.ignore_dc=true.
    6のアップグレード手順に従います。Sparkモードで起動するか、特殊な起動時のパラメーターである-Dcassandra.ignore_dc=trueを各ノードに追加する必要があります。