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

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

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

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

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

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

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

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

Apache Cassandra™のバージョン変更

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

一般的な推奨事項

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

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

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

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

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

一般的なアップグレード制限事項
  • 新しい機能を有効にしないでください
  • nodetool repairを実行しないでください。OpsCenter Repair Serviceが構成されている場合は、Repair Serviceをオフにします。
  • アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
  • ローリング再起動中に、DDLTRUNCATEのような種類のCQLクエリーを実行しないでください。
  • アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
  • 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
  • バージョンが混在しているクラスターではCDCを有効にしないでください。すべてのノードをDataStax Enterprise 5.1にアップグレードしてからCDCを有効にしてください。
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ノードをアップグレードするための高度な準備」の特定の手順に従う必要があります。
DSE 5.1.0~5.1.5にアップグレードする際の制限事項
DSE Searchでは、バージョンが混在するクラスターのトークンフィルターが見落とされる場合があります。トークンフィルター処理が正しく行われるようにするには、すべてのノードをDSE 5.1.6以降にアップグレードします。
任意の種類のセキュリティを使用するノードの制限事項
  • アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。
  • Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
セキュリティの変更
DSE 5.1にアップグレードした後のデフォルトのオーセンティケーターはDseAuthenticatorで、デフォルトのオーソライザーは cassandra.yaml内のDseAuthorizerです。他のオーソライザーやオーセンティケーターはサポートされなくなりました。「アップグレード後」の手順に従ってください。
ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。DataStaxドライバーのアップグレード」を参照してください。
クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバー・バージョンの非互換性を回避するには、以下の回避策のいずれかを使用してください。
  • 起動時のプロトコル・バージョンを強制する。たとえば、アップグレード中はJavaドライバーをv2のままにしておきます。クラスター全体がアップグレードしてから、はじめてJavaドライバーv3に切り替えてください。
  • 初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。たとえば、初期のコンタクト・ポイントには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. Apache Solr SolrJを使用している場合、必要な最小バージョンは6.0.0です。
  4. 検索スキーマ内の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を使用した場合の詳細については、「空間検索」を参照してください。
  5. Stored=trueコピー・フィールドはサポートされておらず、スキーマの検証は失敗に終わります。stored=true copyFieldディレクティブはDSE 4.7からサポートされていないため、Stored=trueコピー・フィールドは使用していないはずです。使用している場合:
    • schema.xmlファイル内のすべてのcopyFieldディレクティブのstored属性値をtrueからfalseに変更してから、dsetool reload_coreを使用して検索インデックス・スキーマを再度読み込みます。
    • アプリケーションの設計と実装でこの変更が認識されるようにする必要があります。
  6. 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">
  7. DSE searchノードをDSE 5.1にアップグレードするには、サポートされていないSolr型をサポートされている型に置換する必要があります。
    注: BCDStrFieldに対しても特別な取り扱いが必要です。これについては「9」で説明されています。
    削除された一部の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
      スキーマを分散的に変更し、インデックスは再作成しません。すべてのノードでスキーマが更新されたら、「8」に進みます。
  8. 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(使用されている場合は「9」を参照) 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を使用します。
  9. 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を指定して、ノードごとにローリングreload_coreを実行します。
    注: データ・センターが2つあり、これらを1つずつアップグレードする場合は、distributed=true deleteAll=trueを指定してコアを再度読み込みます。
  10. アップグレードの前にスキーマを調整してください。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://spark master IP:Spark RPC port number URLの代わりに使用する必要があります。これについては「Spark 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ジョブを特定のデータベースのロールに制限できます。「Sparkアプリケーションのパーミッションの管理」を参照してください。
  5. 個別のユーザーとしてのSparkプロセスの実行」で説明されているように、DSE 5.1以降では、Sparkエグゼキューター・プロセス所有者を設定できます。
  6. Sparkアプリケーションを送信するユーザーを同じデータベース・ロールにする必要はなくなりました。マスター接続送信を変更して、データベース接続とは異なるユーザーまたはクラスターを使用する方法については、「Spark URLの指定」を参照してください。
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にアップグレードするために各ノードを準備します。
  1. 現行バージョンの最新のパッチ・リリースにアップグレードします。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが簡略化される場合があります。
  2. アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。

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

  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.1
  5. すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
    $ nodetool upgradesstables
    これは、Cassandraのメジャー・バージョン の変更を含むDataStax Enterpriseのアップグレードに必要です。
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。

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

  6. Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
    $ java -version

    Oracle Java SE Runtime Environment 8(最低1.8.0_40)またはOpenJDK 8の最新バージョンが推奨されます。開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。

  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にアップグレードするには、各ノードで以下の手順に従います。一部の警告メッセージがアップグレード中とアップグレード後に表示されます

  1. DSE Analyticsノード:すべてのSparkワーカー・プロセスを強制終了します。
  2. 次のようにnodetool drainを実行し、古いインストールのコミット・ログをフラッシュします。
    $ nodetool drain -h hostname
    この手順により、アップグレード後のノードの起動時に時間が節約されるほか、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.0クラスターに、Analytics Hadoopモードで実行されているデータ・センターが存在し、DseSimpleSnitchが使用されていた場合は、以下のいずれかを実行する必要があります。
    • Analytics Hadoopモードで実行されているデータ・センター内のノードに対し、これらのノードをSparkモードで起動します。
    • 特殊な起動時のパラメーターである-Dcassandra.ignore_dc=trueを各ノードに対して追加してから、cassandraモードで起動します。このフラグはDSE 5.1にアップグレードした後に一度だけ必要です。それ以降の再起動ではこのフラグは使用されません。各ノードを初めて再起動した後は、フラグを構成ファイル内に残しておくことも、削除することもできます。
  7. ノードを起動します。
  8. アップグレードにCassandraのメジャー・バージョンが含まれる場合は、新しいバージョンのインストール後にSSTableをアップグレードしてください。
    $ nodetool upgradesstables
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。

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

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

  9. アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
    $ nodetool status
  10. 警告、エラー、および例外がないか、ログを確認します。

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

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

アップグレード後

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

  1. 次のレガシー・テーブルを削除します:system_auth.users、system_auth.credentials、およびsystem_auth.permissions。

    NEWS.txt」に説明されているように、認証および権限管理サブシステムはロールベースのアクセス制御(RBAC)をサポートするようになりました。

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

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

  3. TimeWindowCompactionStrategy(TWCS)は新しいdse_perfテーブルのみで設定されます。前のリリースで作成されたdse_perfテーブルを手動で変更して、TWCSを使用します。例を次に示します。
    ALTER TABLE dse_perf.read_latency_histograms WITH COMPACTION={'class':'TimeWindowCompactionStrategy'};
  4. OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。
  5. DSE Searchのみ:SpatialRecursivePrefixTreeFieldType(RPT)を検索スキーマで使用する場合は、単位のフィールド型を適切な(度、キロメートル、またはマイル)distanceUnitsに置換してから、空間クエリーが期待どおりに動作することを確認します。
  6. DSE Searchのみ: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"/>
  7. 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にコピーして戻します。
  8. DSE Analyticsのみ:Spark SQLテーブルを使用している場合は、dse spark-sql-metastore-migrateコマンドを使用して、Spark SQLで使用されている新しいHiveメタストア形式にこのテーブルを移行します。
    $ dse spark-sql-metatore-migrate
  9. 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を各ノードに追加する必要があります。

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
OpsCenter Backup Service

dse.yaml

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

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

/etc/dse/dse.yaml

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

install_location/resources/dse/conf/dse.yaml

cassandra.yaml

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

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

/etc/cassandra/cassandra.yaml

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

install_location/conf/cassandra.yaml

アップグレード順序

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