DataStax Enterprise 5.1から6.0へのアップグレード
DSE 5.1から6.0へのアップグレード手順
cassandra.yaml
cassandra.yamlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/cassandra/cassandra.yaml |
tarボール・インストール | installation_location/resources/cassandra/conf/cassandra.yaml |
OpsCenterバージョン | DSEバージョン |
---|---|
6.7 | 6.7、6.0、5.1 |
6.5 | 6.0、5.1、5.0 |
6.1 | 5.1、5.0 |
6.0 | 5.0 |
logback.xml
logback.xmlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/cassandra/logback.xml |
tarボール・インストール | installation_location/resources/cassandra/conf/logback.xml |
dse.yaml
dse.yamlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/dse.yaml |
tarボール・インストール | installation_location/resources/dse/conf/dse.yaml |
アップグレードの順序
ノードは以下の順序でアップグレードします。- 複数データ・センター・クラスターでは、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 |
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を使用します。
DataStax Enterpriseのアップグレード・プロセスは、ダウンタイムの最小化(ゼロ・ダウンタイムが理想)を実現します。プロセス中、他のノードがオンラインで稼働し続けている状態でノードを1つずつアップグレードして再起動します。若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
DataStax Enterprise(DSE)5.1からDSE 6.0にアップグレードするには、以下の手順に従います。DSE 5.0を使用している場合は、「DataStax Enterprise 5.0から6.0へのアップグレード」を参照してください。
必ず現行バージョンの最新のパッチ・リリースにアップグレードしてから、新しいバージョンにアップグレードしてください。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが向上するか、スムーズになる場合があります。
DSEの最新の5.1xバージョンは5.1.12です。
一般的な推奨事項
DataStaxでは、バージョン・アップグレードの前に、ログ、カスタム構成などのデータをバックアップすることを推奨しています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。
アップグレード・プロセス中の一般的な制限事項
制限事項は、クラスターの一部が部分的にアップグレードされている状態で適用されます。
これらの例外により、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
- 一般的なアップグレード制限事項
-
- 新しい機能を有効にしないでください。
- nodetool repairを実行しないでください。OpsCenter Repair Serviceが構成されている場合は、Repair Serviceをオフにします。
- OpsCenterの互換性を確認してください。DSE 6.0クラスターを管理するには、OpsCenter 6.5が必要です。互換性テーブルを参照してください。
- アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
- ローリング再起動中に、DDL、TRUNCATEのような種類のCQLクエリーを実行しないでください。
- パフォーマンス・オブジェクトが使用するデフォルトのスレッド数が1から4に増えました。アップグレード中、互換性のあるパフォーマンス・オブジェクトはアップグレード・プロセス中も機能し続けます。スキーマの変更を必要とする互換性のないパフォーマンス・オブジェクトは、レガシー・モードで動作するか、アップグレードが完了してから動作を開始します。アップグレード中に、パフォーマンス・オブジェクトの構成を変更しないでください。パフォーマンス・オブジェクトがアップグレード前に無効になっていた場合は、アップグレード中に有効にしないでください。
- NodeSyncは、すべてのノードがアップグレードされるまで起動を待機します。
- 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
注: アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。 - DSE拡張レプリケーション・ノードの制限事項
- アップグレードは、DSE拡張レプリケーションV2でのみサポートされています。
- DSE Analytic(Spark)ノードの制限事項
-
- すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
- SparkワーカーおよびSparkマスターが起動する前にクラスター内のすべてのノードを新しいバージョンにアップグレードしておく必要があります。
- DSEFSノードの制限事項
- アップグレード中、DSEFSはアップグレードされたノードでは起動しません。すべてのノードが6.0.0にアップグレードされた後、DSEFSキースペースが調整されてからDSEFSが起動します。
- DSE Graphノードの制限事項
- グラフノードには、実行するワークロードと同じ制限事項があります。アップグレード中はグラフ・スキーマを変更しないでください。アップグレード中にOLAPクエリーを実行しないなどの、ワークロードに固有の制限事項は、analyticsおよびsearchノードに適用されます。
- DSE Searchアップグレードの制限事項
-
- スキーマを更新しないでください。
- アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
- DSE 6.0では、新しいLuceneコーデックが導入されました。この新しいコーデックで書かれたセグメントは、以前のバージョンのDSEでは読み取れません。以前のバージョンにダウングレードするには、問題となる可能性のある検索インデックスのデータ・ディレクトリー全体を消去する必要があります。
重要: DSE SearchまたはSearchAnalyticsワークロードをアップグレードする前に、「アップグレードの準備」の特定のタスクに従う必要があります。 - 任意の種類のセキュリティを使用するノードの制限事項
-
- すべてのノードでアップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。
- Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
- ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
- ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。参照先: DataStaxドライバーの変更点。
アップグレードの準備
- 「DataStax Enterpriseのアップグレードの計画」を注意して確認してください。
DataStax Enterpriseのアップグレード・プロセスは、ダウンタイムの最小化(ゼロ・ダウンタイムが理想)を実現します。プロセス中、他のノードがオンラインで稼働し続けている状態でノードを1つずつアップグレードして再起動します。若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
- 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」を参照してください。
- アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。
必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。
- このリリースの変更点と機能について十分理解してください。
- DataStax Enterprise 6.0のリリース・ノート。
- 任意のバージョンのアップグレードに関する一般的なアドバイス。NEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
- DataStax Enterpriseの変更点については、CHANGES.txtに記載されています。
- DataStaxドライバーの変更点。
- 現在の製品バージョンを確認します。
dse -v
これらの手順は、DSE 5.1からDSE 6.0へのアップグレードにのみ有効です。 - 使用する構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。
構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。
- 現行バージョンの最新のパッチ・リリースにアップグレードします。DSEの最新の5.1xバージョンは5.1.12です。
必ず現行バージョンの最新のパッチ・リリースにアップグレードしてから、新しいバージョンにアップグレードしてください。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが向上するか、スムーズになる場合があります。
- すべての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へのデータのコピー」ドキュメントを参照してください。 SPARK_LOCAL_DIRS
およびSPARK_EXECUTOR_DIRS
環境変数の使用が「環境変数の設定」の説明に従っていることを確認してください。- アプリケーションで、DataStax リポジトリで互換性のあるSpark Jobserver APIを使用する場合は、SparkHiveJobとSparkSqlJobからSparkSessionJobに拡張するジョブを移行します。demosディレクトリーのDemoSparkSessionJobの例を参照してください。 注: Spark Jobserverは、DSEカスタム・バージョン8.0.4.45です。demosディレクトリーの場所は、インストールのタイプによって異なります。
- パッケージ・インストール:/usr/share/dse/demos
- tarボール・インストール:installation_location/demos
- Thrift互換テーブル(コンパクト・ストレージ)のサポートが廃止されました。アップグレードする前に、DSE 5.x.xの実行中に手順に従って、コンパクト・ストレージを持つすべてのテーブルをCQLテーブル形式に移行してください。
- DSE Searchノード:すべての変更点については、DSE 6.0リリース・ノートを確認してください。
- 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ノード:
- エッジ・ラベル名およびプロパティ・キー名が、サポートされている文字のみを使用していることを確認します。エッジ・ラベル名およびプロパティ・キー名に使用できるのは、[a-zA-Z0-9]、アンダースコア、ハイフン、およびピリオドのみです。以前のバージョンでは、エッジ・ラベル名およびプロパティ・キー名で、使用できるUnicodeに制限はほとんどありません。
- schema.describe()は、不適切な名前がスキーマに含まれている場合でも、スキーマ全体を表示します。
- インプレースのアップグレードでは、無効なエッジ・ラベル名およびプロパティ・キー名が含まれている既存のスキーマを許可します。
- 不適切な名前が含まれるスキーマ要素は、更新または追加ができません。
- エッジ・ラベル名およびプロパティ・キー名が、サポートされている文字のみを使用していることを確認します。エッジ・ラベル名およびプロパティ・キー名に使用できるのは、[a-zA-Z0-9]、アンダースコア、ハイフン、およびピリオドのみです。以前のバージョンでは、エッジ・ラベル名およびプロパティ・キー名で、使用できるUnicodeに制限はほとんどありません。
アップグレード手順
- 古いインストールのコミット・ログをフラッシュするには、次のようにします。
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 を編集して、以下のオプションを削除します。
- 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
- キースペース・レプリケーション係数が環境に適していることを確認してください。
- analyticsキースペースのキースペース・レプリケーション係数を確認してください。
- system_authおよびdse_securityキースペースのキースペース・レプリケーション係数を確認してください。
- このcassandra.yaml ファイルを編集し、認証情報キャッシュ設定が存在する場合は、それらをコメントアウトするか、削除します。
キャッシュは、これらの設定がなくても最適化されます。credentials_validity_in_ms credentials_update_interval_in_ms
- 該当する変更を新しいバージョンにマージします。
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- ノードを起動します。
- パッケージ・インストール:「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上にあり、必要なスキーマ変更が行われたら、CassandraAuthorizerを使用した新しい許可によって、新しい列の使用が可能になります。
- DSE Searchのみ:
- アペンダーSolrValidationErrorAppenderおよびロガー SolrValidationErrorLoggerは使用されなくなり、 logback.xmlから安全に削除できます。
- 以前のバージョンと異なり、DataStaxでは、back_pressure_threshold_per_core(dse.yaml)に、新しいデフォルト値1024を使用することをお勧めします。「インデックス作成のパフォーマンスの構成と調整」を参照してください。
- 大きな暗号化インデックスがある場合にノードでの起動が遅くなる問題は解決されています。ただし、パフォーマンスの向上を実現するためにはアクションが必要です。お使いのクラスターの各ノードで、すべての暗号化検索インデックスを完全に再作成する必要があります。アップグレードが完了したら、ローリング方式でdeleteAll=trueを使用してインデックスを再作成するための時間を十分に取ってください。例を次に示します。
dsetool reload_core keyspace_name.table_name distributed=false reindex=true deleteAll=true
- DSE Analyticsのみ:
dse_analytics
キースペースのレプリケーション係数を確認してください。新しいキースペースにDSE Analyticsのすべての内部システム・データが格納されます。DataStaxでは、レプリケーション・ストラテジを、各DSE Analyticsデータ・センターで少なくとも3のレプリケーション係数を持つNetworkTopologyStrategy
(NTS)に設定することを推奨しています。データ・センターにさらに多くのノードがある場合は、より大きなレプリケーション係数を検討する必要があります。- Spark Jobserverは、DSEカスタム・バージョン0.8.0.44を使用します。アプリケーションでは、DataStaxリポジトリから互換性のあるSpark Jobserver APIを使用する必要があります。
アップグレード中とアップグレード後の警告メッセージ
エラー・メッセージには、問題の特定に役立つ情報が記載されます。アップグレード中およびアップグレード後に表示される一部のログ・メッセージは無視できます。- 以前のバージョンの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.