アップグレードの前にこれらの手順を読み、理解しておいてください。計画およびアップグレード手順を細かく確認しておくと、スムーズなアップグレードが保証され、不備や不満が生じるのを避けることができます。SSTableをアップグレードするための推奨事項に必ず従ってください。一般的な推奨事項DataStaxでは、バージョン・アップグレードの前に、ログ、カスタム構成などのデータをバックアップすることを推奨しています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。Service(バックアップ・サービス)が提供されます。Enterpriseクラスターの企業全体のバックアップ操作と復元操作を管理します。6.5以降が推奨されます。制限事項は、クラスターの一部が部分的にアップグレードされている状態で適用されます。Enterpriseの以前のバージョンであるかのように機能し続けます。新しい機能を有効にしないでください。repairを実行しないでください。Serviceをオフにします。OpsCenterの互換性を確認してください。Enterpriseの互換性」を参照してください。アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。ローリング再起動中に、DDL、TRUNCATEのような種類のCQLクエリーを実行しないでください。Capture(CDC)を有効にしないでください。5.1以降にアップグレードしてからCDCを有効にしてください。必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。NodeSyncは、すべてのノードがアップグレードされるまで起動を待機します。Capture(CDC)を有効にしないでください。すべてのノードをアップグレードしてからCDCを有効にしてください。OpsCenterの互換性を確認してください。Enterpriseの互換性」を参照してください。Graphノードの制限事項グラフノードには、実行するワークロードと同じ制限事項があります。アップグレード中はグラフ・スキーマを変更しないでください。アップグレード中にOLAPクエリーを実行しないなどの、ワークロードに固有の制限事項は、analyticsおよびsearchノードに適用されます。Analytic(HadoopおよびSpark)ノードの制限事項すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。Analytic(Spark)ノードの制限事項すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。Analytic(Spark)ノードの制限事項すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。SparkワーカーおよびSparkマスターが起動する前にクラスター内のすべてのノードを新しいバージョンにアップグレードしておく必要があります。Analytic(Spark)ノードの制限事項すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。Searchアップグレードの制限事項スキーマを更新しないでください。Searchノードにインデックスを付け直さないでください。6.0以降のバージョンは新しいLuceneコーデックを使用しています。この新しいコーデックで書かれたセグメントは、以前のバージョンのDSEでは読み取れません。以前のバージョンにダウングレードするには、問題となる可能性のある検索インデックスのデータ・ディレクトリー全体を消去する必要があります。この大幅な変更により、アップグレードの前後で、事前の計画と特定の措置が求められます。Searchアップグレードの制限事項スキーマを更新しないでください。Searchノードにインデックスを付け直さないでください。6.0以降のバージョンは新しいLuceneコーデックを使用しています。この新しいコーデックで書かれたセグメントは、以前のバージョンのDSEでは読み取れません。以前のバージョンにダウングレードするには、問題となる可能性のある検索インデックスのデータ・ディレクトリー全体を消去する必要があります。この大幅な変更により、アップグレードの前後で、事前の計画と特定の措置が求められます。SearchおよびSearchAnalyticsノードをアップグレードするための高度な準備」セクションの特定のタスクに従う必要があります。Searchアップグレードの制限事項スキーマを更新しないでください。Searchノードにインデックスを付け直さないでください。Search(Solr)ノードの制限事項スキーマを更新しないでください。Searchノードにインデックスを付け直さないでください。ローリング再起動中に、BATCH、TRUNCATEのような種類のクエリーを実行しないでください。4.7または4.8ではページネーションがサポートされていますが、旧バージョンではサポートされていないという状況でのクラスター上のアップグレード・プロセス中には、アップグレードされたノードからクエリーを実行すると、フェッチサイズの結果しか返されません。任意の種類のセキュリティを使用するノードの制限事項すべてのノードでアップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。任意の種類のセキュリティを使用するノードの制限事項アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。DataStaxドライバーの変更点。クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバーのバージョン互換性の喪失を回避するには、以下の回避策のいずれかを使用してください。プロトコル・バージョン:一部のドライバーでは異なるプロトコル・バージョンを使用できるため、起動時にプロトコル・バージョンを強制します。ドライバー・アップグレード中はJavaドライバーを現在のプロトコル・バージョンのままにしておきます。クラスター内のすべてのノードでアップグレードが完了してから、はじめてJavaドライバーを新しいプロトコル・バージョンに切り替えてください。初期のコンタクト・ポイント:初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。初期のコンタクト・ポイントにはJavaドライバーv2のみが含まれます。プロトコル・バージョンのネゴシエーションの詳細については、ご使用のJavaドライバー・バージョン(たとえばJavaドライバー)の「混在クラスターのあるプロトコル・バージョン」を参照してください。Enterpriseをアップグレードし、多数のアップグレード・タスクを自動的に実行します。4.0または4.5へのアップグレードに備えるには、以下の手順に従います。アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。現在の製品バージョンを確認します。4.0または4.5にアップグレードする前に、必要に応じて、以下のいずれかの中間バージョンにアップグレードします。ファイルを編集して、以下のオプションを除去またはコメント・アウトします。4.0.0からのアップグレード」を参照してください。すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。Enterpriseのアップグレードに必要です。必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。upgradesstablesSSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。「SSTableの互換性とアップグレード・バージョン」を参照してください。同時にアップグレードするSSTableの数を設定するには、--jobsオプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。FAQ」を参照してください。必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。FAQ」を参照してください。4.0.0からのアップグレードのための特別な手順」を参照してください。Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。7の最新バージョンが推奨されます。開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。7を使用する場合は、最低でも1.7.0_25を使用する必要があります。8を使用する場合は、最低でも1.8.0_40を使用する必要があります。このリリースの変更点と機能について十分理解してください。4.0および4.5のリリース・ノート。2.0の新機能については、NEWS.txtに記載されています。各バージョンのNEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。CassandraTMでの変更点については、CHANGES.txtに記載されています。ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。4.0または4.5にアップグレードするには、以下の手順に従います。現在の製品バージョンを確認します。4.0または4.5にアップグレードする前に、必要に応じて、以下のいずれかの中間バージョンにアップグレードします。ファイルを編集して、以下のオプションを除去またはコメント・アウトします。4.0.0からのアップグレード」を参照してください。すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。Enterpriseのアップグレードに必要です。必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。SSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。4.0.0からのアップグレード」を参照してください。Runtimeバージョンを確認し、推奨バージョンにアップグレードしてください。7の最新バージョンが推奨されます。開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。7を使用する場合は、最低でも1.7.0_25を使用する必要があります。8を使用する場合は、最低でも1.8.0_40を使用する必要があります。このリリースの変更点と機能について十分理解してください。4.0および4.5のリリース・ノート。2.0の新機能については、NEWS.txtに記載されています。各バージョンのNEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。CassandraTMでの変更点については、CHANGES.txtに記載されています。ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。アップグレードの順序は重要です。ノードは以下の順序でアップグレードします。複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。データ・センター内のシード・ノードを最初にアップグレードします。Trackerノードを最初にアップグレードします。次にHadoopノード、Sparkノードの順にアップグレードします。ノードは以下の順序でアップグレードします。Enterpriseの以前のバージョンであるかのように機能し続けます。ノードは1つずつアップグレードして再起動してください。クラスター内の他のノードは、すべてのノードがアップグレードされるまで、最も古いバージョンで動作します。古いインストールのコミット・ログをフラッシュするには、次のようにします。Searchノードでデータに再度インデックス付けする手間を省くことができます。SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。ノードを停止します(4.0)。適切な方法を使用して新しい製品バージョンをインストールします。RHEL:4.0、4.5Debian:4.0、4.5tarボール:4.0、4.5新しいバージョンを構成するには、バックアップされた構成ファイルを使用して変更を新しいバージョンの構成ファイルにマージします。Enterpriseをサービスとして起動」を参照してください。Enterpriseをスタンドアローン・プロセスとして起動」を参照してください。アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。status警告、エラー、および例外がないか、ログを確認します。多くの場合、警告、エラー、および例外は、アップグレードしたノードの起動時にログに表示されます。これらのログ・エントリーの一部は、固有のアップグレード関連の手順を実行するときに役立ちます。予想しなかった警告、エラー、または例外が表示された場合は、DataStaxサポートまでお問い合わせください。順序に従って、クラスター内の各ノードでアップグレードを繰り返します。Cassandraのメジャー・バージョンが含まれている場合は、SSTableのアップグレードが必要です。DataStaxでは、一度に1つのノード(ラックを使用している場合は一度に1つのラック)のSSTableをアップグレードすることを推奨します。必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。upgradesstablesSSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。「SSTableの互換性とアップグレード・バージョン」を参照してください。同時にアップグレードするSSTableの数を設定するには、--jobsオプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。DataStaxでは、一度に1つのノード(ラックを使用している場合は一度に1つのラック)で、upgradesstablesコマンドを実行することを推奨します。すべてのノードがアップグレードされる前にupgradesstablesコマンドを実行できます。このコマンドを一度に1つのノード(ラックを使用する場合は一度に1つのラック)のみで実行する場合に限ります。upgradesstablesを実行するノードが多すぎると、パフォーマンスが低下します。4.0.0からのアップグレードには、特別な手順が必要です。Inc.およびその子会社の米国および各国における登録商標です。その他各国における登録商標または商標です。