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

DataStax Enterprise 4.7または4.8から5.0へのアップグレード手順。

hive-site.xml

Sparkを使用する場合のhive-site.xmlファイルのデフォルトの場所:
パッケージ・インストール /etc/dse/spark/hive-site.xml
tarボール・インストール installation_location/resources/spark/conf/hive-site.xml

アップグレードの順序

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

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

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

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

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

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

Apache Cassandra™のバージョン変更

DataStax Enterprise 4.7または4.8から5.0へのアップグレードには、Cassandraのメジャー・バージョン変更が含まれます。
  • Apache Cassandraのメジャー・リリースを含むアップグレードには、SSTableのアップグレードが必要です。
    • 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では、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がアップグレードされるまで完了しません。
注: アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
  • NodeSyncは、すべてのノードがアップグレードされるまで起動を待機します。
  • バージョンが混在しているクラスターではChange Data Capture(CDC)を有効にしないでください。すべてのノードをアップグレードしてからCDCを有効にしてください。
DSE Analytic(HadoopおよびSpark)ノードの制限事項
  • すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
  • ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。
DSE Search(Solr)アップグレードの制限事項
  • スキーマを更新しないでください。
  • アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
  • ローリング再起動中に、DDLTRUNCATEのような種類のクエリーを実行しないでください。
  • アップグレード中にノードのバージョンが混合している間、DataStax Enterpriseでは後方互換性を提供するための2つの異なるサーバーを実行します。1つはshard_transport_optionsに基づいており、もう1つはinternode_messaging_optionsに基づいています(これらのオプションはdse.yamlに含まれています)。すべてのノードが5.0にアップグレードされると、internode_messaging_optionsが使用されます。internode_messaging_optionsは、DataStax Enterpriseの複数のコンポーネントによって使用されます。5.0以降では、すべてのノード間メッセージング要求でこのサービスが使用されます。
任意の種類のセキュリティを使用するノードの制限事項
  • すべてのノードでアップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。
  • Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。参照先: DataStaxドライバーの変更点
クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバーのバージョン互換性の喪失を回避するには、以下の回避策のいずれかを使用してください。
  • プロトコル・バージョン:一部のドライバーでは異なるプロトコル・バージョンを使用できるため、起動時にプロトコル・バージョンを強制します。たとえば、ドライバー・アップグレード中はJavaドライバーを現在のプロトコル・バージョンのままにしておきます。クラスター内のすべてのノードでアップグレードが完了してから、はじめてJavaドライバーを新しいプロトコル・バージョンに切り替えてください。
  • 初期のコンタクト・ポイント:初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。たとえば、初期のコンタクト・ポイントにはJavaドライバーv2のみが含まれます。
プロトコル・バージョンのネゴシエーションの詳細については、ご使用のJavaドライバー・バージョン(たとえばJavaドライバー)の「混在クラスターのあるプロトコル・バージョン」を参照してください。

アップグレードの準備

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

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

  2. このリリースの変更点と機能について十分理解してください。
  3. 現在の製品バージョンを確認します。必要に応じて、中間バージョンにアップグレードします。
    現在のバージョン アップグレード・バージョン
    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.1.x DataStax Enterprise 4.8
    DataStax Community 3.0.x 中間バージョンは不要です。
    Apache Cassandra™ 3.xのDataStaxディストリビューション アップグレードは利用できません。
  4. すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
    これは、 Cassandraのメジャー・バージョンの変更を含むDataStax Enterpriseのアップグレードに必要です。
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。
    nodetool upgradesstables

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

    同時にアップグレードするSSTableの数を設定するには、--jobsオプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。

    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。
  5. Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
    java -version

    開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。

    重要: Oracle JRE/JDK 8はサポートされていますが、DataStaxでは、DSE 5.0.15で起動するOpenJDK 8でさらに広範なテストを実施しています。
  6. nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。
  7. DSE Searchノード:
    • Luceneフィールド・キャッシュ(solr_field_cache_enabled)ファイルは廃止予定です。このフィールドはdse.yamlファイルに含まれています。代わりに、ソート、ファセット、またはグループ分けされるフィールドに対して、schema.xmlファイル内のフィールドにdocValues="true"を設定します。次に、コアを再度読み込んでインデックスを再作成します。デフォルト値はfalseです。falseをオーバーライドするには、Solr要求内にuseFieldCache=trueを設定します。

      バージョンが混在しているアップグレード中は、フィールド・キャッシュ(solr_field_cache_enabled: true)を再度有効にして、インデックスを再作成せずに、クエリーを実行できるようにします。

    • ユニーク・キー要素はすべてSolrスキーマでインデックスを付ける必要があります。

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

    • HTTPベースのSolrシャード・トランスポート・オプションは廃止予定です。代わりにノード間メッセージング・オプションを使用してください。5.0では、すべてのノード間メッセージング要求でこの内部メッセージング・サービスが使用されます。HTTPは5.1では削除されます。
    • アップグレードの前にスキーマを調整してください。DSE 5.0.10以降では、スキーマ内のすべてのフィールド定義が検証されます。フィールドにインデックスがないか、docValuesを適用するか、これらがコピー・フィールド・ソースに対して使用される場合であっても、DSE Searchがサポートされている必要があります。自動リソース生成のデフォルトの動作には、すべてのカラムが含まれます。パフォーマンスを改善するには、フィールドがデータベースから読み込まれないように対策を講じます。スキーマ内の使用されていないフィールドを削除するかコメント・アウトして、スキーマ内の必要なフィールドのみを含めます。 スキーマを変更したら、Solrコアを再読み込みします。
  8. DSE Searchパーティション・キー名
    DSE SearchインデックスによってサポートされているCOMPACT STORAGEテーブルのパーティション・キー名は、schema.xml内のuniqueKeyに一致します。たとえば、コンパクト・ストレージで次のテーブルを作成するとします。
    CREATE TABLE keyspace_name.table_name (key text PRIMARY KEY, foo text, solr_query text) 
    WITH COMPACT STORAGE
    Solr schema.xmlは次のとおりです。
    ...
    <uniqueKey>id</uniqueKey>
    ...
    次に、テーブル内のキー名をスキーマに合わせて変更します。
    ALTER TABLE ks.table RENAME key TO id;
  9. DSE Analyticsノード

    DSE 4.8からDSE 5.0へのローリング・アップグレードをデータ・センターで実行する場合は、hive-site.xmlのSparkで使用されるメタストア・テーブルの名前を手動で更新してください。

    注: この手順は、データ・センター全体がアップグレードされる前に、中断せずにローリング・アップグレードする場合にのみ実行します。DSE 5.0は、 hive-site.xmlを手動で更新しない場合に、データ・センター全体がアップグレードされた後、Spark Masterを選択します。

    tarボール・インストールの場合:

    sudo perl -i -pe 's|cfs:///user/spark/warehouse|cfs:///user/hive/warehouse|g' /etc/dse/spark/hive-site.xml
    
    sudo perl -i -pe 's|sparkmetastore|MetaStore|g' /etc/dse/spark/hive-site.xml

    パッケージ・インストールの場合:

    sudo perl -i -pe 's|cfs:///user/spark/warehouse|cfs:///user/hive/warehouse|g' /usr/local/lib/dse/resources/spark/conf/hive-site.xml
    
    sudo perl -i -pe 's|sparkmetastore|MetaStore|g' /usr/local/lib/dse/resources/spark/conf/hive-site.xml

    DSE 5.0より前では、SparkはHiveメタストア・テーブルHiveMetaStore.MetaStoreを使用していました。 DSE 5.0以降、Hiveメタストア・テーブルとSparkメタストア・テーブルは分離され、SparkはHiveMetaStore.sparkmetastoreテーブルを使用します。DSE 5.0が起動し、メタストア・テーブルが見つからない場合、最初にメタストア・テーブルを作成する必要があるため、ノードはSparkを起動する前にクラスター全体がアップグレードされるのを待ちます。 手動で設定を更新すると、Sparkノードはメタストア・テーブルを作成し、混在データ・センターでMasterを選択できるようになります。

    ローリング・アップグレード中は不便な点がいくつかあります。Sparkコンタクト・ポイントがDSE 5.0ノードに設定されている場合、データへのアクセスに使用できるのはDSE 5.0レプリカだけです。ただし、コンタクト・ポイントがDSE 4.8に設定されている場合は、クラスター内のすべてのレプリカのデータにアクセスできます。

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

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

アップグレード手順

ヒント: DataStaxインストーラーは、DataStax Enterpriseをアップグレードし、多数のアップグレード・タスクを自動的に実行します。

DataStax Enterprise 4.7または4.8からDataStax Enterprise 5.0にアップグレードするには、各ノードで以下の手順に従います。一部の警告メッセージがアップグレード中とアップグレード後に表示されます

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

  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. 古いインストールのコミット・ログをフラッシュするには、次のようにします。
    nodetool -h hostname drain
    この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。
    重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。
  4. ノードを停止します
  5. 適切な方法を使用して、サポートされるプラットフォームにDSE 5.0をインストールします。
    注: システム上にある同じインストール方法を使用して新しい製品バージョンをインストールします。アップグレードではインストール方法に関係なくインストールを行うため、問題が発生することがあります。
  6. クラスターがセキュアなKerberos環境でHadoopを実行する場合は、task-controllerファイルの所有権をrootに変更し、アクセス・パーミッションを4750に変更します。例を次に示します。
    sudo chown root /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller
    $ sudo chmod 4750 /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller

    パッケージ・インストールのみ:task-controllerファイルのデフォルトの場所を/usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controllerに設定する必要があります。

  7. 新しい製品バージョンを構成するには:
    1. バックアップ 構成 ファイルを新しい構成ファイルと比較します。
      • 廃止予定、削除済み、または変更済みの設定を探します。
      • 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
      • キースペース・レプリケーション係数が環境に適していることを確認してください。
    2. 該当する変更を新しいバージョンにマージします。
  8. ノードを起動します。
  9. アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
    nodetool status
  10. 警告、エラー、および例外がないか、ログを確認します。 DataStax Enterprise 5.0はCassandra 3.0を使用するため、output.logには以下に関する警告が含まれる場合があります。
    • sstable_compression
    • chunk_length_kb
    • memory_allocator
    • memtable_allocation_type
    • offheap_objects
    • netty_server_port - 5.0へのアップグレード中にのみ使用。すべてのノードが5.0を実行するようになると、このノードによってコーディネートされる要求はこのポートで他のノードに連絡しなくなります。代わりに、要求にはノード間メッセージング・オプションが使用されます。internode_messaging_optionsは、DataStax Enterpriseの複数のコンポーネントによって使用されます。5.0以降では、すべてのノード間メッセージング要求でこのサービスが使用されます。

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

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

  11. 推奨される 順序に従って、クラスター内の各ノードでアップグレードを繰り返します。
  12. すべてのノードがアップグレードされたら、レガシー・テーブル(system_auth.users、system_auth.credentials、system_auth.permissions)を削除する必要があります。この手順は、レガシー・テーブルが存在する場合、すべてのワークロードに必要です

    CassandraのNEWS.txtに説明されているように、認証および権限管理サブシステムはロールベースのアクセス制御(RBAC)をサポートするように再設計されています。これにより、system_authキースペースのスキーマが変更されます。

  13. DSE 5.0.12以降のDSE Searchのみ:アップグレード後、お使いのクラスターの各ノードで、すべての暗号化検索インデックスを完全に再作成する必要があります。大きな暗号化インデックスがある場合にノードでの起動が遅くなる問題は解決されています。ただし、パフォーマンスの向上を実現するためにはアクションが必要です。アップグレードが完了したら、ローリング方式でdeleteAll=trueを使用してインデックスを再作成するための時間を十分に取ってください。例を次に示します。
    dsetool reload_core keyspace_name.table_name distributed=false reindex=true deleteAll=true 
  14. 新しいバージョンがすべてのノードにインストールされたら、次のSSTableをアップグレードします。
    nodetool upgradesstables
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。

    同時にアップグレードするSSTableの数を設定するには、--jobsオプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。

  15. 複数のデータ・センターのデプロイでは、system_distributedキースペースのレプリケーション係数をNetworkTopologyStrategyに変更します。
  16. OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。

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

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

DataStax Enterprise 5.0にアップグレードする直前にスキーマを変更した場合は、以下のようなログ・メッセージがアップグレード後に表示される場合があります。
WARN  [main] 2016-06-23 12:01:59,693  CommitLogReplayer.java:154 - Skipped 31 mutations from unknown (probably removed) CF with id b0f22357-4458-3cdb-9631-c43e59ce3676
WARN  [main] 2016-06-23 12:01:59,693  CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 3aa75225-4f82-350b-8d5c-430fa221fa0a
WARN  [main] 2016-06-23 12:01:59,696  CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 45f5b360-24bc-3f83-a363-1034ea4fa697
WARN  [main] 2016-06-23 12:01:59,696  CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 0359bc71-7123-3ee1-9a4a-b9dfb11fc125
WARN  [main] 2016-06-23 12:01:59,697  CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 296e9c04-9bec-3085-827d-c17d3df2122a
これらのログ・メッセージは無視しても差し支えありません。