DataStax Enterprise 5.0.xパッチ・リリースのアップグレード
パッチ(ポイント)リリース間のDataStax Enterprise 5.0のアップグレード手順。
DataStax Enterprise 5.0.3から5.0.11にアップグレードするような、パッチ(ポイント)リリース間でのDataStax Enterprise(DSE)のアップグレードについては、この情報を確認してください。
DataStaxでは、バージョン・アップグレードの前に、ログ、カスタム構成などのデータをバックアップすることを推奨しています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。
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 |
追加のドライバーのドキュメント | |
すべてのドライバー | バージョンの互換性 |
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 Enterprise 5.0リリース・ノートを読んでください。
2038-01-19T03:14:06+00:00
より大きい期限切れの日付である場合、そのデータはすぐに期限切れとなり、次のコンパクションでパージされます。DataStaxでは、気付かないうちにデータがなくならないように、DSE 5.0.15以降にアップグレードし、必要な措置を講じることを強く推奨します。(DSP-15412)。アップグレード・プロセス中の一般的な制限事項
制限事項は、クラスターの一部が部分的にアップグレードされている状態で適用されます。クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
- アップグレード中のすべてのノードの制限事項
-
- 新しい機能を有効にしないでください。
- nodetool repairを実行しないでください。
- ノードをブートストラップしたり、使用廃止にしたりしないでください。
- 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
注: アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
- DSE Analytics(HadoopおよびSpark)アップグレードの制限事項
-
- すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
- ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。
- DSE Search(Solr)アップグレードの制限事項
-
- スキーマを更新しないでください。
- アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
- ローリング再起動中に、
DDL
、TRUNCATE
のような種類のクエリーを実行しないでください。
- セキュリティ・アップグレードの制限事項
-
- アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。
- Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
- DSE Graph
-
- 通常、DSE Graphは他のワークロードとともに実行されるため、それらのワークロードについても同じアップグレードの制限事項に従ってください。
- アップグレード中はグラフやその他のスキーマを作成したりアップデートしたりしないでください。
- アップグレード中のGremlinやグラフ関連のエラーは無視してもかまいません。
DSE 5.0.0~5.0.8から5.0.9以降の5.0.xリリースにアップグレードするための高度な準備
このセクションは、DSE 5.0.0~5.0.8から5.0.9以降の5.0.xリリースへのアップグレードのみに適用します。
DSE 5.0.9および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 5.0の最新バージョンは5.0.14です。
- アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。
必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。
- DataStax EnterpriseおよびApache Cassandra™の変更点や機能について、よく理解しておいてください。
- アップグレード・バージョンのDataStax Enterpriseリリース・ノートを参照し、必要なアクションをすべて完了してください。
DSEリリース・ノートには、必要な計画、コンポーネント、変更点、拡張機能、既知の問題、および解決済みの問題が記載されています。5.1、5.0、および4.8。
- 任意のバージョンのアップグレードに関する一般的なアドバイス、およびApache Cassandraの新機能については、NEWS.txtに記載されています。NEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
- Apache Cassandra™での変更点については、CHANGES.txtに記載されています。
- DataStax Enterpriseの実稼働環境で認定済みのApache Cassandraの変更点については、DSEリリース・ノートに記載されています。
- DataStaxドライバーの変更点。
- アップグレード・バージョンのDataStax Enterpriseリリース・ノートを参照し、必要なアクションをすべて完了してください。
- 現在の製品バージョンを確認します。
dse -v
- DSE Searchノード:
- アップグレードの前にスキーマを調整してください。DSE 5.0.10以降では、フィールドにインデックスが付いていなくても、スキーマ内のすべてのフィールド定義が検証され、DSE Searchと互換性があり、docValuesが適用されるか、コピー・フィールド・ソースに使用される必要があります。
- 自動リソース生成のデフォルトの動作には、すべてのカラムが含まれます。パフォーマンスを改善するには、フィールドがデータベースからインデックス・パスに読み込まれないように対策を講じます。スキーマ内の未使用のフィールドを削除するかコメント・アウトします。
-
ユニーク・キー要素はすべてSolrスキーマでインデックスを付ける必要があります。ユニーク・キー要素を確認するには、schema.xmlですべてのユニーク・キー・フィールドがindexed=trueになっていることを確認します。
- スキーマを変更した場合は、全インデックスを再作成してください。
- 使用する 構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。
構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。
アップグレード手順
nodetool repair
を実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。- アップグレードの順序は重要です。ノードは以下の順序でアップグレードします。
- 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
- データ・センター内のシード・ノードを最初にアップグレードします。
DSE Hadoopを使用するDSE Analyticsノードでは、Job Trackerノードを最初にアップグレードします。次にHadoopノード、Sparkノードの順にアップグレードします。
- ノードは以下の順序でアップグレードします。
- DSE Analyticsデータ・センター
- トランザクション/DSE Graphデータ・センター
- DSE Searchデータ・センター
- 次のように
nodetool drain
を実行し、古いインストールのコミット・ログをフラッシュします。nodetool drain -h ホスト名
この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。
- ノードを停止します。
- 適切な方法を使用して新しい製品バージョンをインストールします。
- 新しい製品バージョンを構成するには:
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- 廃止予定、削除済み、または変更済みの設定を探します。
- 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
- 変更した可能性のある構成ファイルが他にないか確認します。Installer-ServicesおよびパッケージのインストールまたはInstaller-No Servicesおよびtarボールのインストール用のデフォルトのファイル場所を確認します。
- 該当する変更を新しいバージョンにマージします。
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- ノードを起動します。
- アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
nodetool status
- 警告、エラー、および例外がないか、ログを確認します。
多くの場合、警告、エラー、および例外は、アップグレードしたノードの起動時にログに表示されます。これらのログ・エントリーの一部は、固有のアップグレード関連の手順を実行するときに役立ちます。予想しなかった警告、エラー、または例外が表示された場合は、DataStaxサポートまでお問い合わせください。
- 推奨されるアップグレード順序に従って、クラスター内の各ノードでのアップグレードおよび再起動を繰り返します。
各ノードでのアップグレードおよび再起動は、ローリング再起動と呼ばれます。
- 各ノードに新しいバージョンがインストールされたら、各ノードのSSTableをアップグレードすることをお勧めします。
SSTableのアップグレードは、最適なパフォーマンス実現のために推奨されますが、パッチ・リリースでは必須ではありません。
nodetool upgradesstables
SSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。
同時にアップグレードするSSTableの数を設定するには、
--jobs
オプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。 - この手順は、DSE 5.0.0~5.0.9から5.0.10以降の5.0.xパッチ・リリースのみに適用します。インクリメンタル・リペアの実行を続けるには、
nodetool repair -inc
を使用します。重要: インクリメンタル・リペアから移行してインクリメンタル以外のフル(-full
)リペアまたはパーティション(-pr
)リペアを有効にするには、アップグレード後に最初のリペアを実行する前に、nodetool mark_unrepairedを使用してすべてのノードですべてのSSTableを未リペアとして設定する必要があります。 - OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。