DataStax Enterprise 4.0または4.5へのアップグレード

DataStax Enterprise 4.0または4.5にアップグレードするには、以下の手順に従います。

アップグレードの順序

ノードは以下の順序でアップグレードします。

複数データ・センター・クラスターでは、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

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

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ドライバーの変更点

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のバージョン変更

DataStax Enterprise 4.0または4.5へのアップグレードには、Cassandraのメジャー・バージョンの変更が含まれます。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の互換性」を参照してください。
アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
ローリング再起動中に、DDL、TRUNCATEのような種類のCQLクエリーを実行しないでください。
バージョンが混在しているクラスターではChange Data Capture（CDC）を有効にしないでください。すべてのノードをDSE 5.1以降にアップグレードしてからCDCを有効にしてください。
必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。

注: アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。

NodeSyncは、すべてのノードがアップグレードされるまで起動を待機します。
バージョンが混在しているクラスターではChange Data Capture（CDC）を有効にしないでください。すべてのノードをアップグレードしてからCDCを有効にしてください。

OpsCenterの互換性を確認してください。DSE 6.7クラスターを管理するには、OpsCenter 6.7が必要です。「DSE OpsCenterとDataStax Enterpriseの互換性」を参照してください。

DSE Graphノードの制限事項

グラフノードには、実行するワークロードと同じ制限事項があります。アップグレード中はグラフ・スキーマを変更しないでください。アップグレード中にOLAPクエリーを実行しないなどの、ワークロードに固有の制限事項は、analyticsおよびsearchノードに適用されます。

DSE Analytic（HadoopおよびSpark）ノードの制限事項

すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。

DSE Analytic（Spark）ノードの制限事項

すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。

DSE Analytic（Spark）ノードの制限事項

すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
SparkワーカーおよびSparkマスターが起動する前にクラスター内のすべてのノードを新しいバージョンにアップグレードしておく必要があります。

DSE Analytic（Spark）ノードの制限事項

すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。

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

スキーマを更新しないでください。
アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
DSE 6.0以降のバージョンは新しいLuceneコーデックを使用しています。この新しいコーデックで書かれたセグメントは、以前のバージョンのDSEでは読み取れません。以前のバージョンにダウングレードするには、問題となる可能性のある検索インデックスのデータ・ディレクトリー全体を消去する必要があります。
- DataStax Enterprise 6.7のDSE SearchはApache Solr 6.0を使用します。この大幅な変更により、アップグレードの前後で、事前の計画と特定の措置が求められます。

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

スキーマを更新しないでください。
アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
DSE 6.0以降のバージョンは新しいLuceneコーデックを使用しています。この新しいコーデックで書かれたセグメントは、以前のバージョンのDSEでは読み取れません。以前のバージョンにダウングレードするには、問題となる可能性のある検索インデックスのデータ・ディレクトリー全体を消去する必要があります。
DataStax Enterprise 5.1以降のDSE SearchはApache Solr 6.0を使用します。この大幅な変更により、アップグレードの前後で、事前の計画と特定の措置が求められます。

重要: DSE SearchまたはSearchAnalyticsワークロードをアップグレードする前に、「DSE SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備」セクションの特定のタスクに従う必要があります。

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

スキーマを更新しないでください。
アップグレード中にDSE Searchノードにインデックスを付け直さないでください。

DSE Search（Solr）ノードの制限事項

スキーマを更新しないでください。
アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
ローリング再起動中に、BATCH、TRUNCATEのような種類のクエリーを実行しないでください。
バージョンが混在しており、DataStax Enterprise 4.7または4.8ではページネーションがサポートされていますが、旧バージョンではサポートされていないという状況でのクラスター上のアップグレード・プロセス中には、アップグレードされたノードからクエリーを実行すると、フェッチサイズの結果しか返されません。

任意の種類のセキュリティを使用するノードの制限事項

すべてのノードでアップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。
Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。

任意の種類のセキュリティを使用するノードの制限事項

アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。

ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響

ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。参照先：。

クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバーのバージョン互換性の喪失を回避するには、以下の回避策のいずれかを使用してください。

プロトコル・バージョン：一部のドライバーでは異なるプロトコル・バージョンを使用できるため、起動時にプロトコル・バージョンを強制します。たとえば、ドライバー・アップグレード中はJavaドライバーを現在のプロトコル・バージョンのままにしておきます。クラスター内のすべてのノードでアップグレードが完了してから、はじめてJavaドライバーを新しいプロトコル・バージョンに切り替えてください。
初期のコンタクト・ポイント：初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。たとえば、初期のコンタクト・ポイントにはJavaドライバーv2のみが含まれます。

プロトコル・バージョンのネゴシエーションの詳細については、ご使用のJavaドライバー・バージョン（たとえばJavaドライバー）の「混在クラスターのあるプロトコル・バージョン」を参照してください。

3.2.5以降から4.0または4.5へのアップグレードの準備

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

DataStaxインストーラーを使用しない場合、DataStax Enterprise 3.2.5以降からDataStax Enterprise 4.0または4.5へのアップグレードに備えるには、以下の手順に従います。

アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。
必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。
現在の製品バージョンを確認します。4.0または4.5にアップグレードする前に、必要に応じて、以下のいずれかの中間バージョンにアップグレードします。
- DataStax Enterprise 3.2.5以降
- DataStax Communityまたはオープン・ソースのApache Cassandra™ 1.2.16
3.2.xからのアップグレードの場合のみ：このcassandra.yaml ファイルを編集して、以下のオプションを除去またはコメント・アウトします。
```
# auth_replication_options: 
# replication_factor: 1
```
searchノードのある4.0.0から4.5へのアップグレードの場合のみ：「searchノードのあるDataStax Enterprise 4.0.0からのアップグレード」を参照してください。
すべての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」を参照してください。
DataStax Enterprise 4.0.0からアップグレードする場合でDSE Searchノードが含まれている場合は、「DataStax Enterprise 4.0.0からのアップグレードのための特別な手順」を参照してください。
Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
```
java -version
```
Oracle Java SE Runtime Environment 7または8、あるいはOpenJDK 7の最新バージョンが推奨されます。開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。
注: Oracle Java 7を使用する場合は、最低でも1.7.0_25を使用する必要があります。Oracle Java 8を使用する場合は、最低でも1.8.0_40を使用する必要があります。
このリリースの変更点と機能について十分理解してください。
- DataStax Enterprise 4.0および4.5のリリース・ノート。
- 任意のバージョンのアップグレードに関する一般的なアドバイス、およびApache Cassandra™ 2.0の新機能については、NEWS.txtに記載されています。各バージョンのNEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
- Apache Cassandra™での変更点については、CHANGES.txtに記載されています。
使用する構成ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。
構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。

3.2.5以降から4.0または4.5へのアップグレード

3.2.5以降からDataStax Enterprise 4.0または4.5にアップグレードするには、以下の手順に従います。

現在の製品バージョンを確認します。4.0または4.5にアップグレードする前に、必要に応じて、以下のいずれかの中間バージョンにアップグレードします。
- DataStax Enterprise 3.2.5以降
- DataStax Communityまたはオープン・ソースのCassandra™ 1.2.16
3.2.xからのアップグレードの場合のみ：このcassandra.yaml ファイルを編集して、以下のオプションを除去またはコメント・アウトします。
```
# auth_replication_options: 
# replication_factor: 1
```
searchノードのある4.0.0から4.5へのアップグレードの場合のみ：「searchノードのあるDataStax Enterprise 4.0.0からのアップグレード」を参照してください。
すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
```
nodetool upgradesstables
```
この手順は、 Cassandraのメジャー・バージョンの変更を含むDataStax Enterpriseのアップグレードに必要です。
警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。
SSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。
DataStax Enterprise 4.0.0からアップグレードする場合でDSE Searchノードが含まれている場合は、「searchノードのあるDataStax Enterprise 4.0.0からのアップグレード」を参照してください。
Java Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。
```
java -version
```
Oracle Java SE Runtime Environment 7または8、あるいはOpenJDK 7の最新バージョンが推奨されます。開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。
注: Oracle Java 7を使用する場合は、最低でも1.7.0_25を使用する必要があります。Oracle Java 8を使用する場合は、最低でも1.8.0_40を使用する必要があります。
このリリースの変更点と機能について十分理解してください。
- DataStax Enterprise 4.0および4.5のリリース・ノート。
- 任意のバージョンのアップグレードに関する一般的なアドバイス、およびApache Cassandra™ 2.0の新機能については、NEWS.txtに記載されています。各バージョンのNEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
- Apache Cassandra™での変更点については、CHANGES.txtに記載されています。
使用する構成ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。
構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。
アップグレードの順序は重要です。ノードは以下の順序でアップグレードします。
- 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
- データ・センター内のシード・ノードを最初にアップグレードします。
  DSE Hadoopを使用するDSE Analyticsノードでは、Job Trackerノードを最初にアップグレードします。次にHadoopノード、Sparkノードの順にアップグレードします。
- ノードは以下の順序でアップグレードします。
  1. DSE Analyticsデータ・センター
  2. トランザクション/DSE Graphデータ・センター
  3. DSE Searchデータ・センター
若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。ノードは1つずつアップグレードして再起動してください。クラスター内の他のノードは、すべてのノードがアップグレードされるまで、最も古いバージョンで動作します。
古いインストールのコミット・ログをフラッシュするには、次のようにします。
```
nodetool -h hostname drain
```
この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。
重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。
ノードを停止します（4.0）。
適切な方法を使用して新しい製品バージョンをインストールします。
- RHEL：4.0、4.5
- Debian：4.0、4.5
- tarボール：4.0、4.5
新しいバージョンを構成するには、バックアップされた構成ファイルを使用して変更を新しいバージョンの構成ファイルにマージします。
ノードを起動します。
- Installer-Servicesおよびパッケージ・インストール：「DataStax Enterpriseをサービスとして起動」を参照してください。
- Installer-No Servicesおよび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つのラック）のみで実行する場合に限ります。upgradesstablesを実行するノードが多すぎると、パフォーマンスが低下します。