DataStax Enterprise 5.0から6.0へのアップグレード
DSE 5.0から6.0へのアップグレード手順
dse.yaml
dse.yamlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/dse.yaml |
tarボール・インストール | installation_location/resources/dse/conf/dse.yaml |
DataStaxドライバーの変更点
DataStaxドライバーには2つのタイプがあります。
- DataStax Enterprise用DataStaxドライバー:DSE 4.8以降用
- Apache Cassandra™用DataStaxドライバー:Apache Cassandra™およびDSE 4.7以前のバージョン用
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を使用します。
アップグレードの順序
ノードは以下の順序でアップグレードします。- 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
- データ・センター内のシード・ノードを最初にアップグレードします。
- ノードは以下の順序でアップグレードします。
- DSE Analyticsデータ・センター
- トランザクション/DSE Graphデータ・センター
- 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 |
logback.xml
logback.xmlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/cassandra/logback.xml |
tarボール・インストール | installation_location/resources/cassandra/conf/logback.xml |
server.xml
Tomcat server.xmlファイルのデフォルトの場所は、インストール・タイプによって異なります。パッケージ・インストール | /etc/dse/tomcat/conf/server.xml |
tarボール・インストール | installation_location/resources/tomcat/conf/server.xml |
cassandra.yaml
cassandra.yamlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/cassandra/cassandra.yaml |
tarボール・インストール | installation_location/resources/cassandra/conf/cassandra.yaml |
DataStax Enterpriseのアップグレード・プロセスは、ダウンタイムの最小化(ゼロ・ダウンタイムが理想)を実現します。プロセス中、他のノードがオンラインで稼働し続けている状態でノードを1つずつアップグレードして再起動します。若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
DataStax Enterprise 5.0からDataStax Enterprise 6.0にアップグレードするには、以下の手順に従います。
DSE 4.8以前をお使いの場合は、続行する前に5.0の最新バージョンにアップグレードしてください。
必ず現行バージョンの最新のパッチ・リリースにアップグレードしてから、新しいバージョンにアップグレードしてください。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが向上するか、スムーズになる場合があります。
DSE 5.0の最新バージョンは5.0.14です。
Apache Cassandra™のバージョン変更
- DataStax Enterprise 6.0はCassandra 3.11と互換性があります。
- DataStax Enterprise 5.0はCassandra 3.0を使用します。
一般的な推奨事項
DataStaxでは、バージョン・アップグレードの前に、ログ、カスタム構成などのデータをバックアップすることを推奨しています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。
アップグレード・プロセス中の一般的な制限事項
制限事項は、クラスターの一部が部分的にアップグレードされている状態で適用されます。
これらの例外により、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
- 一般的なアップグレード制限事項
-
- 新しい機能を有効にしないでください。
- nodetool repairを実行しないでください。OpsCenter Repair Serviceが構成されている場合は、Repair Serviceをオフにします。
- OpsCenterの互換性を確認してください。DSE 6.0クラスターを管理するには、OpsCenter 6.5が必要です。「DataStax OpsCenterとDataStax Enterpriseの互換性」を参照してください。
- アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
- ローリング再起動中に、DDL、TRUNCATEのような種類のCQLクエリーを実行しないでください。
- NodeSyncは、すべてのノードがアップグレードされるまで起動を待機します。
- バージョンが混在しているクラスターではChange Data Capture(CDC)を有効にしないでください。すべてのノードをDSE 5.1以降にアップグレードしてからCDCを有効にしてください。
- 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
注: アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
- DSE Analytic(Spark)ノードの制限事項
-
- すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
- ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。
- DSE拡張レプリケーションの制限事項
-
- DSE 5.0のDSE拡張レプリケーションV1のサポートは削除されました。DSE拡張レプリケーションV2は大幅に改訂されているため、V1インストールの場合はまず、DSE 5.1.xにアップグレードし、DSE拡張レプリケーションをV2に移行してから、DSE 6.0にアップグレードする必要があります。
- DSEFSに関する制限事項
- アップグレード・プロセス中は、バージョンが混在しているDSEFSはサポートされません。
- すべてのノードでのアップグレードを完了してから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に関する制限事項
-
- スキーマを更新しないでください。
- アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
- DSE 6.0では、新しいLuceneコーデックが導入されました。この新しいコーデックで書かれたセグメントは、以前のバージョンのDSEでは読み取れません。以前のバージョンにダウングレードするには、問題となる可能性のある検索インデックスのデータ・ディレクトリー全体を消去する必要があります。
- DataStax Enterprise 6.0のDSE SearchはApache Solr 6.0を使用します。この大幅な変更により、アップグレードの前後で、事前の計画と特定の措置が求められます。重要: DSE SearchまたはSearchAnalyticsワークロードをアップグレードする前に、「DSE SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備」の特定の手順に従う必要があります。
- 任意の種類のセキュリティを使用するノードの制限事項
-
- すべてのノードでアップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。
- Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
- セキュリティの変更
- アップグレードした後のデフォルトのオーセンティケーターはDseAuthenticatorで、デフォルトのオーソライザーは cassandra.yaml内のDseAuthorizerです。他のオーソライザーやオーセンティケーターはサポートされなくなりました。「アップグレード後」のこの手順に従ってください。
- ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
- ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。参照先: DataStaxドライバーの変更点。
DSE SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備
「アップグレードの準備」の手順を開始する前に、DSE 5.0をまだ実行している間に、DSE SearchおよびSearchAnalyticsノードに対して行う高度な準備手順をすべて完了します。
- スキーマを変更するには、インデックスを完全に作成し直す必要があります。
- 構成の変更にはコアの再読み込みが必要です。
- HTTPクエリーをCQLに変更します。
- Delete-by-idが削除されました。代わりに、プライマリ・キーによるCQL DELETEを使用してください。
- Delete-by-queryはワイルドカードをサポートしなくなりました。代わりに、CQL TRUNCATEを使用してください。
- SolrコアがDSE 4.6以前のバージョンで作成されており、DSE 4.7以降にアップグレードした後にインデックスが再作成されていない場合は、DSE 5.0でインデックスを再作成してからDSE 5.1以降にアップグレードする必要があります。
- shard_transport_optionsがdse.yaml 内でnetty_client_request_timeoutに対してのみ設定されていることを確認してください。
shard_transport_options: netty_client_request_timeout: 60000
DSE 5.1以降のシャード・トランスポート・オプションは、netty_client_request_timeoutのみをサポートしています。他のshard_transport_optionsは削除してください。 - Apache Solr SolrJを使用している場合、必要な最小バージョンは6.0.0です。
- 検索スキーマ内の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
のように指定できました。
- IsDisjointToはSpatialRecursivePrefixTreeFieldTypeのクエリーに対してはサポートされなくなりました。IsDisjointToはIntersects以外のクエリーに置き換えてください。例を次に示します。
- DSE 6.0.0およびDSE 6.0.1へのアップグレードのみの場合:Stored=trueコピー・フィールドはサポートされておらず、スキーマの検証は失敗に終わります。stored=true copyFieldディレクティブはDSE 4.7からサポートされていないため、Stored=trueコピー・フィールドは使用していないはずです。使用している場合:
- schema.xmlファイル内のすべてのcopyFieldディレクティブのstored属性値をtrueからfalseに変更してから、dsetool reload_coreを使用して変更されたスキーマを再度読み込みます。
- アプリケーションの設計と実装でこの変更が認識されるようにする必要があります。
注: DSE 6.0.2以降では、stored=trueは無視されます。 - 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-6508とSOLR-7942の結果、サポートされなくなりました。
- updateLogの以下の部分を変更します。
<updateLog class="solr.FSUpdateLog" force="false">
以下のように変更します。<updateLog force="false">
- requestHandlers(XmlUpdateRequestHandler、BinaryUpdateRequestHandler、CSVRequestHandler、JsonUpdateRequestHandler、DataImportHandler)を削除します。Solrでは、これらのrequestHandlersは廃止され削除されました。
- DSE searchノードをDSE 5.1以降にアップグレードするには、サポートされていないSolr型をサポートされている型に置換する必要があります。注: BCDStrFieldに対しても特別な取り扱いが必要です。これについては10で説明されています。ソート制限は、バージョンが混在しているクラスターに適用されます。削除された一部のSolr型は、分散クエリー中に値をマーシャルソートする方法が原因で(推奨される新しい型によって値がアンマーシャルソートされる方法との兼ね合いで)、一部のノードがサポートされていない型を使用し、他のノードが推奨される新しい型を使用する場合には、ローリング・アップグレード中にソートできません。次の型の移行では問題が生じる場合があります。
以下の2つのオプションを使用できます。削除されたSolrフィールド型 サポートされているSolrフィールド型 ByteField TrieIntField DateField TrieDateField BCDIntField TrieIntField BCDLongField TrieLongField - クエリー対象のデータ・センター内のノードがすべてDSE 5.1以降にアップグレードされるまで、削除されたSolrフィールド型をソートしないようにします。 ヒント: 2つの検索データ・センターを使用している場合は、1つのデータ・センターに対するクエリーを分離してからスキーマを変更し、もう一方のデータ・センターのインデックスを再作成します。次に、スキーマを変更し、最初のデータ・センターをアップグレードする間に、新たにインデックスを再作成したデータ・センターに対するクエリーを分離します。
- BCDIntFieldまたはBCDLongFieldを使用している場合は、スキーマを更新し、サポートされているSolr型であるTrieIntFieldおよびTrieLongFieldとソート互換性がある型にBCDIntFieldとBCDLongFieldを置き換えます。
スキーマを分散的に変更し、インデックスは再作成しません。すべてのノードでスキーマが更新されたら、9に進みます。削除されたSolrフィールド型 ソート互換性がある、サポートされている中間Solrフィールド型 BCDIntField SortableIntField BCDLongField SortableLongField
- クエリー対象のデータ・センター内のノードがすべてDSE 5.1以降にアップグレードされるまで、削除されたSolrフィールド型をソートしないようにします。
- 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を使用します。 - スキーマを更新し、サポートされていないSolrフィールド型をサポートされているSolrフィールド型に置換します。
- BCDStrFieldを使用している場合:DSE 5.0以前では、DSEはCassandraテキスト・カラムをBCDStrFieldにマッピングしていました。廃止予定のBCDStrFieldはDSE 5.1.0で削除されました。推奨される戦略は、データ型をTrieIntFieldにアップグレードすることです。ただし、DSEではテキストをTrieIntFieldに直接マッピングできません。BCDStrFieldを使用している場合は、以下のいずれかのオプションを完了してからアップグレードする必要があります。
- BCDStrFieldが使用されなくなった場合は、BCDStrFieldフィールドをSolrスキーマから削除します。インデックスの再作成は不要です。
- フィールドのインデックスをTrieIntFieldとして作成する必要があり、インデックスの完全な再作成が可能な場合は、基になるデータベース・カラムを変更してint型を使用します。
- データベース・カラムをテキストのまま保持しながらインデックス付きのフィールドで単純な一致クエリーを実行する場合は、スキーマ内のBCDStrFieldをStrFieldに切り替えます。インデックスの作成は必須ではありませんが、このフィールドは数値範囲クエリーまたはソートに適さなくなります。StrFieldは数値順序ではなく辞書式順序を使用するためです。
- この方法は推奨されません:データベース・カラムをテキストのまま保持しながら、以前のBCDStrFieldに対して数値範囲クエリーやソートを実行する必要があるが、完全にインデックスを再作成するのではなくアプリケーションを変更したい場合:
- indexed=falseを指定して、Solrスキーマ内のフィールドをStrFieldに変更します。
- 元のBCDStrFieldから提供された値を持つTrieIntField型を指定した新しいコピー・フィールドを追加します。
これらのスキーマの変更を行った後は、reindex=true、distributed=false、およびdeleteAll=trueを指定して、ノードごとにローリングreload_coreを実行します。注: データ・センターが2つあり、これらを1つずつアップグレードする場合は、distributed=trueおよびdeleteAll=trueを指定してコアを再度読み込みます。 - アップグレードの前にスキーマを調整してください。DSE 5.1.4以降では、フィールドにインデックスが付いていなくても、スキーマ内のすべてのフィールド定義が検証され、DSE Searchと互換性があり、docValuesが適用されるか、コピー・フィールド・ソースに使用される必要があります。自動リソース生成のデフォルトの動作には、すべてのカラムが含まれます。パフォーマンスを改善するには、フィールドがデータベースから読み込まれないように対策を講じます。スキーマ内の使用されていないフィールドを削除するかコメント・アウトして、スキーマ内の必要なフィールドのみを含めます。
検索インデックス付きDSE Graphノードをアップグレードするための高度な準備
以下の手順は検索インデックスを含むグラフ・ノードに適用されます。「アップグレードの準備」の手順を開始する前に、DSE 5.0をまだ実行している間に、高度な準備手順をすべて完了します。
検索インデックスを含むDSE Graphノードをアップグレードするには、solrconfigファイルを以下のように編集する必要があります。構成の変更にはコアの再読み込みが必要です。アップグレード前に、必要な変更を実装し、テストするための十分な時間を確保してください。
- requestHandlers(XmlUpdateRequestHandler、BinaryUpdateRequestHandler、CSVRequestHandler、JsonUpdateRequestHandler、およびDataImportHandler)を削除します。Solrでは、これらのrequestHandlersは廃止され削除されました。
例を次に示します。
<requestHandler name="/dataimport" class="solr.DataImportHandler"/>
または
<requestHandler name="/update" class="solr.XmlUpdateRequestHandler">/>
- <unlockOnStartup>はLUCENE-6508とSOLR-7942の結果、サポートされなくなりました。
- コアを再度読み込んで、この構成の変更を適用します。
dsetool reload_core keyspace_name.table_name reindex=false
DSE Analyticsノードをアップグレードするための高度な準備
DSE 5.0からDSE 6.0へのアップグレードには、Spark 2.2へのメジャー・アップグレードに加えて、DSEおよびSpark間の緊密な統合が含まれています。Spark 2.2の詳細については、Sparkのドキュメントを参照してください。Spark 2.2はScala 2.11を使用しています。
- Spark 2.2はScala 2.11を使用しています。すべてのDSE 5.0 Scala SparkアプリケーションをScala 2.11に対して再コンパイルし、Scala 2.11のサードパーティ・ライブラリのみを使用する必要があります。
コンパイル・ターゲットを変更するには、ビルド・ファイル内の
dse-spark-dependencies
を変更するだけでは十分ではありません。ビルド・ファイルの設定方法については、プロジェクト例を参照してください。 - Sparkアプリケーションは、
dse://
URLを使用する必要があります。これは、「Spark URLの指定」で説明しているように、spark://spark_master_IP:Spark_RPC_port_number
URLの代わりです。SparkマスターのIPアドレスまたはホスト名を、
dse://
URLの使用時に指定する必要はなくなりました。Sparkノードに接続すると、要求がマスター・ノードにリダイレクトされます。 - 接続の目的で
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)
DSE 5.1以降に接続するために、
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形式を使用してください。 - DSE 5.1以降では、Sparkジョブを特定のデータベースのロールに制限できます。「Sparkアプリケーションのパーミッションの管理」を参照してください。
- 「個別のユーザーとしてのSparkプロセスの実行」で説明されているように、DSE 5.1以降では、Sparkエグゼキューター・プロセス所有者を設定できます。
- Sparkアプリケーションを送信するユーザーを同じデータベース・ロールにする必要はなくなりました。マスター接続送信を変更して、データベース接続とは異なるユーザーまたはクラスターを使用する方法については、「Spark URLの指定」を参照してください。
以下の手順はDSEFSを使用するノードのみに適用されます。アップグレードの準備の手順を開始する前に、以下の高度な準備手順を完了してください。
データベースで使用されるDSEFSスキーマはDSE 5.1で向上していますが、以前のスキーマも引き続きサポートされており、アップグレード中に変更されることはありません。既存のDSEFSデータで新しいDSEFSスキーマを使用するには、DSEFSデータをバックアップしてからアップグレードしてください。
dse hadoop fs -cp
コマンドを使用して現在のDSEFSデータをローカル・ストレージにバックアップします。
dse hadoop fs -cp /* /local_backup_location
アップグレードの準備
- 現行バージョンの最新のパッチ・リリースにアップグレードします。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが簡略化される場合があります。
- アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。
必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。
- このリリースの変更点と機能について十分理解してください。
- DataStax Enterprise 6.0のリリース・ノート。
- 任意のバージョンのアップグレードに関する一般的なアドバイス。NEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
- DataStax Enterpriseの変更点については、CHANGES.txtに記載されています。
- DataStaxドライバーの変更点。
- ITriggerおよびカスタム・インターフェイスを置き換えます。
コア・ストレージ・エンジンのリファクタリングを必要とするために、いくつかの内部およびベータ拡張ポイントが変更されています。DSE 6.0にアップグレードする際は、以下のインターフェイスを含むすべてのカスタム実装を、サポート対象の実装に置き換える必要があります。DSE 6.0では、以下のインターフェイスのリライトが必要です。(ご不明な点がある場合は、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」を参照してください。
- 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"モードで実行され、コンパクト・フラグが既に削除されたかのようにコンパクト・テーブルが見えますが、これは現在のセッションの場合のみです。 - 監査ロギングがCassandraAuditWriterを使用するよう構成されている場合は、DSE 5.0ノードでスーパーユーザーとしてこれらのコマンドを実行してから、クラスター全体がスキーマ合意を持っていることを確認します。
ALTER TABLE dse_audit.audit_log ADD authenticated text; ALTER TABLE dse_audit.audit_log ADD consistency text;
- すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
nodetool upgradesstables
この手順は、 Cassandraのメジャー・バージョン の変更を含むDataStax Enterpriseのアップグレードに必要です。警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。SSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。
- Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
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以上)
重要: Oracle JRE/JDK 8はサポートされていますが、DataStaxでは、OpenJDK 8でさらに広範なテストを実施しています。 - 推奨。OpenJDK 8(1.8.0_151以上)
- nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。
- 最適なパフォーマンスを得るためにlibaioパッケージをインストールしてください。 RHELプラットフォーム:
sudo yum install libaio
Debian:sudo apt-get install libaio1
- DSE Analyticsノード:
- 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"モードで実行され、コンパクト・フラグが既に削除されたかのようにコンパクト・テーブルが見えますが、これは現在のセッションの場合のみです。 - 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へのデータのコピー」ドキュメントを参照してください。
- Thrift互換テーブル(コンパクト・ストレージ)のサポートが廃止されました。アップグレードする前に、DSE 5.x.xの実行中に手順に従って、コンパクト・ストレージを持つすべてのテーブルをCQLテーブル形式に移行してください。
- DSE Searchノード:
- DataStax Enterprise 6.0のDSE SearchはApache Solr™ 6.0を使用します。「DSE SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備」のすべての手順を完了します。
- HTTPの書き込みのすべての使用が、更新および挿入のためのCQLコマンドを使用するように変更されていることを確認します。
- 検索インデックス構成を編集し、必要に応じて以下の変更を行います。検索インデックスのクエリーの動作を変更するための有効なオプションについては、「検索インデックス構成」を参照してください。
- サポートされていないdataDirオプションを削除します。検索インデックスの場所の設定は、引き続き行うことができます。
- mergePolicy、maxMergeDocs、およびmergeFactorを削除します。例を次に示します。
代わりにmergePolicyFactoryを使用し、さらにmergeSchedulerを追加します。<mergeFactor>25</mergeFactor> <maxMergeDocs>... <mergePolicy>...
<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を使用する演算子を変更します。
- DSE Graphノード:
- gremlinを使用して追加した検索インデックスがグラフ・ノードに含まれている場合は、「検索インデックス付きDSE Graphノードをアップグレードするための高度な準備」の手順を完了します。
- エッジ・ラベル名およびプロパティ・キー名が、サポートされている文字のみを使用していることを確認します。エッジ・ラベル名およびプロパティ・キー名に使用できるのは、[a-zA-Z0-9]、アンダースコア、ハイフン、およびピリオドのみです。以前のバージョンでは、エッジ・ラベル名およびプロパティ・キー名で、使用できるUnicodeに制限はほとんどありません。
- schema.describe()は、不適切な名前がスキーマに含まれている場合でも、スキーマ全体を表示します。
- インプレースのアップグレードでは、無効なエッジ・ラベル名およびプロパティ・キー名が含まれている既存のスキーマを許可します。
- 不適切な名前が含まれるスキーマ要素は、更新または追加ができません。
- 使用する 構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。
構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。
- 5.0.0から5.0.8ならびにDSE 5.1.0および5.1.1からDSE 5.1.2以降のリリースへのアップグレード
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
注: アップグレード時にはバージョンが混在しますが、既存のテーブルのカラムを追加したり削除したりしないでください。すべてのノードでアップグレードが完了した後に、このフラグを使用せずにノードを再起動します。
アップグレード手順
- DSE Analyticsノード:すべてのSparkワーカー・プロセスを強制終了します。
- 古いインストールのコミット・ログをフラッシュするには、次のようにします。
nodetool -h hostname drain
この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。 - ノードを停止します。「DataStax Enterpriseノードの停止」を参照してください。
- サービスとして実行しているDataStax Enterpriseを停止する方法:
sudo service dse stop
- スタンドアローン・プロセスとして実行しているDataStax Enterpriseを停止する方法:
bin/dse cassandra-stop
- サービスとして実行しているDataStax Enterpriseを停止する方法:
- 適切な方法を使用して、サポートされるプラットフォームに新しい製品バージョンをインストールします。注: システム上にある同じインストール・タイプを使用して新しい製品バージョンをインストールします。そうでない場合、問題が発生する可能性があります。
- 新しい製品バージョンを構成するには:
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- 廃止予定、削除済み、または変更済みの設定を探します。
- 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.yaml を編集して、以下のオプションを削除します。
- DSE Analyticsノード注: DSE 5.1.0以降では、DSEFSはデフォルトで有効になっていますが、dse.yamlではdsefs.enabled設定はコメント・アウトされています。DSEFSを有効にするには、dsefs_options.enabled設定のコメントを解除します。(DSP-13310)
- DSE Searchノード
- アップグレードによって、新しい server.xml がTomcat 8用にインストールされます。既存のserver.xmlにカスタム・コネクターが含まれている場合は、これらのコネクターを新しいserver.xmlに移行してから、アップグレードされたノードを起動してください。
- 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
- キースペース・レプリケーション係数が環境に適していることを確認してください。
- analyticsキースペースのキースペース・レプリケーション係数を確認してください。
- system_authおよびdse_securityキースペースのキースペース・レプリケーション係数を確認してください。
- 廃止予定、削除済み、または変更済みの設定を探します。
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- DSE Analyticsノード:DSE 5.0クラスターに、Analytics Hadoopモードで実行されているデータ・センターが存在し、DseSimpleSnitchが使用されていた場合は、以下のいずれかを実行する必要があります。
- Analytics Hadoopモードで実行されているデータ・センター内のノードに対し、これらのノードをSparkモードで起動します。
- 特殊な起動時のパラメーターである
-Dcassandra.ignore_dc=true
を各ノードに対して追加してから、cassandraモードで起動します。このフラグはアップグレードした後に一度だけ必要です。 それ以降の再起動ではこのフラグは使用されません。各ノードを初めて再起動した後は、フラグを構成ファイル内に残しておくことも、削除することもできます。
- ノードを起動します。
- パッケージ・インストール:「DataStax Enterpriseをサービスとして起動」を参照してください。
- tarボール・インストール:「DataStax Enterpriseをスタンドアローン・プロセスとして起動」を参照してください。
- アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
nodetool status
- 警告、エラー、および例外がないか、ログを確認します。
多くの場合、警告、エラー、および例外は、アップグレードしたノードの起動時にログに表示されます。これらのログ・エントリーの一部は、固有のアップグレード関連の手順を実行するときに役立ちます。予想しなかった警告、エラー、または例外が表示された場合は、DataStaxサポートまでお問い合わせください。
- 推奨される 順序に従って、クラスター内の各ノードでアップグレードを繰り返します。
- アップグレードに 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 6.7にアップグレードした後の復元
- 既にDSE 6.0にアップグレードしたノードがあれば、それらを、DSE 5.0または5.1シリーズの最新バージョンにダウングレードします。
- DSE 5.0.xの場合は、5.0.14以降にダウングレード
- DSE 5.1.xの場合は、5.1.12以降にダウングレード
- DSE 6.0で起動しようとした各ノードで、
-Dcassandra.commitlog.ignorereplayerrors=true
オプションを指定してDSEを起動します。 - クラスター内の1つのノード(任意のノード)で、コンパクト・ストレージを使用しているテーブルからコンパクト・ストレージを削除します。
- DSEを再起動し、DSE 6.0へのアップグレードを続行します。
アップグレード後
すべてのノードをアップグレードしてDSE 6.0で実行したら、以下の手順を完了します。
- OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。
- すべてのノードがDSE 6.0上にあり、必要なスキーマ変更が行われたら、新しい監査ロギング機能(CassandraAuditWriter)により新しい列の使用が可能になります。
- レガシー・テーブルとしてsystem_auth.users、system_auth.credentials、およびsystem_auth.permissionsが存在する場合は削除します。
「アップグレードに関する一般的なアドバイス」で説明しているように、認証および権限管理サブシステムはロールベースのアクセス制御(RBAC)をサポートするようになりました。
- セキュリティ構成を確認します。セキュリティを使用するには、DSE Unified Authenticationを有効にして構成します。
cassandra.yamlでは、デフォルトのオーセンティケーターはDseAuthenticatorで、デフォルトのオーソライザーはDseAuthorizerです。他のオーセンティケーターやオーソライザーはサポートされなくなりました。dse.yaml内ではセキュリティはデフォルトで無効になっています。
- TimeWindowCompactionStrategy(TWCS)は新しいdse_perfテーブルのみで設定されます。前のリリースで作成されたdse_perfテーブルを手動で変更して、TWCSを使用します。例を次に示します。
ALTER TABLE dse_perf.read_latency_histograms WITH COMPACTION={'class':'TimeWindowCompactionStrategy'};
- DSE Searchのみ:
- アペンダーSolrValidationErrorAppenderおよびロガー SolrValidationErrorLoggerは使用されなくなり、 logback.xmlから安全に削除できます。
- 以前のバージョンと異なり、DataStaxでは、back_pressure_threshold_per_core(dse.yaml)に、新しいデフォルト値1024を使用することをお勧めします。「インデックス作成のパフォーマンスの構成と調整」を参照してください。
SpatialRecursivePrefixTreeFieldType
(RPT)を検索スキーマで使用する場合は、単位のフィールド型を適切な(度、キロメートル、またはマイル)distanceUnitsに置換してから、空間クエリーが期待どおりに動作することを確認します。- アペンダーSolrValidationErrorAppenderおよびロガー SolrValidationErrorLoggerは使用されなくなり、 logback.xmlから安全に削除できます。
- 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"/>
- 大きな暗号化インデックスがある場合にノードでの起動が遅くなる問題は解決されています。ただし、パフォーマンスの向上を実現するためにはアクションが必要です。お使いのクラスターの各ノードで、すべての暗号化検索インデックスを完全に再作成する必要があります。アップグレードが完了したら、ローリング方式でdeleteAll=trueを使用してインデックスを再作成するための時間を十分に取ってください。例を次に示します。
dsetool reload_core keyspace_name.table_name distributed=false reindex=true deleteAll=true
- DSEFSのみ:新しいスキーマがDSEFSに対して用意されています。警告: キースペースを削除すると、バックアップがない限り復元できません。一時データ以外のデータがある場合は、dsefsキースペースを削除しないでください。アクションは不要です。DSEFSは引き続きDSE 5.0スキーマを使用して機能します。DSEFSにデータがないか、一時データに対してのみDSEFSを使用している場合は、以下の手順に従って新しいスキーマを使用します。
- すべてのノードでDSEFSを停止します。dse.yamlのdsefs_optionsセクションで、enabled: falseを設定します。
- DSEノードを再起動します。
- dsefsキースペースを削除します。
DROP KEYSPACE dsefs
- 各ノードでdsefsデータ・ディレクトリーを消去します。 たとえば、dse.yamlのdsefs_optionsセクションに次のように構成されているdata_directoriesがあるとします。
dsefs_options: ... data_directories: - dir: /var/lib/dsefs/data
このコマンドは以下のディレクトリーを削除します。rm -r /var/lib/dsefs/data/*
- DSE 6.0でDSEFSを起動して、新しいスキーマを使用します。
- アップグレード前に既存のDSEFSデータをバックアップした場合は、ローカル・ストレージからデータをDSEFSにコピーして戻します。
- DSE Analyticsのみ:
- Spark Jobserverは、DSEカスタム・バージョン0.8.0.44を使用します。アプリケーションでは、DataStaxリポジトリから互換性のあるSpark Jobserver APIを使用する必要があります。
- Spark SQLテーブルを使用している場合は、新しいHiveメタストア形式にこのテーブルを移行します。
dse client-tool spark metastore migrate --from 5.0.0 --to 6.0.0
- キースペース・レプリケーション係数が環境に適していることを確認してください。
- analyticsキースペースのキースペース・レプリケーション係数を確認してください。
- system_authおよびdse_securityキースペースのキースペース・レプリケーション係数を確認してください。
アップグレード中とアップグレード後の警告メッセージ
アップグレード中およびアップグレード後に表示される一部のログ・メッセージは無視できます。
- DSE Advanced Replicationを含むノードをアップグレードする際に、ノードのバージョンが混在している場合、ローリング・アップグレード中にWriteTimeoutExceptionが発生することがあります。ノードのバージョンが混在している間は、書き込みの整合性の制限がいくつか適用されます。WriteTimeoutの問題は、すべてのノードがアップグレードされると解決されます。
- 以前のバージョンのDSEの一部のgremlin_serverプロパティは不要になりました。アップグレード後、プロパティが dse.yaml ファイルに存在する場合、ログに以下のような警告が表示されます。
これらの警告を無視するか、dse.yamlを変更して必要なgremlinサーバーのプロパティのみが存在するようにすることができます。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.
- 次のようなエラー・メッセージが表示された場合:
6のアップグレード手順に従います。Sparkモードで起動するか、特殊な起動時のパラメーターである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.
-Dcassandra.ignore_dc=true
を各ノードに追加する必要があります。