DataStax Enterprise 4.7または4.8へのアップグレード
DataStax Enterprise 4.0、4.5、または4.6からDataStax Enterprise 4.7または4.8にアップグレードする手順。
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のメジャー・バージョンのアップグレード
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データ・センター
cassandra.yaml
cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール |
/etc/cassandra/cassandra.yaml |
tarボール・インストール |
install_location/conf/cassandra.yaml |
DataStax Enterprise 4.0、4.5、または4.6からDataStax Enterprise 4.7または4.8にアップグレードするには、以下の手順に従います。
Cassandraのバージョン変更
4.0、4.5、および4.6からDataStax Enterprise 4.7または4.8へのアップグレードには、Cassandraのメジャー・バージョン の変更が含まれます。SSTableをアップグレードするための推奨事項に必ず従ってください。
- Cassandraバージョン2.0から2.1への変更が含まれており、commitlog_total_space_in_mb値のデフォルト値(cassandra.yaml 内)を1024 MBから8192 MBに変更します。環境に合わせてcommitlog_total_space_in_mb設定を調整し、アップグレード後にディスク領域が不足しないようにします。
- ロギング保持ポリシーの変更に伴い、ロギングがlog4jからlogbackに変更されました。logback.xmlでオプションを設定してロガーを構成します。「ロギングの構成」を参照してください。
一般的な推奨事項
DataStaxでは、バージョン・アップグレードの前に、ログ、カスタム構成などのデータをバックアップすることを推奨しています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。
アップグレードの制限事項
制限事項は、クラスターの一部が部分的にアップグレードされている状態で適用されます。
これらの例外により、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
- 一般的なアップグレード制限事項
-
- 新しい機能を有効にしないでください。
- nodetool repairを実行しないでください。
- アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
- ローリング再起動中に、
DDL
、TRUNCATE
のような種類のCQLクエリーを実行しないでください。 - アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
- 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
- DSE Analytic(Spark)ノードの制限事項
-
- すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
- ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。
- DSE Search(Solr)ノードの制限事項
- 任意の種類のセキュリティを使用するノードの制限事項
-
- アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。
4.0、4.5、または4.6から4.7または4.8へのアップグレードの準備
- アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。
必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。
- このリリースの変更点と機能について十分理解してください。
- 現在の製品バージョンを確認します。4.7または4.8にアップグレードする前に、必要に応じて、以下のいずれかの中間バージョンにアップグレードします。
- DataStax Enterprise 4.0以降
- DataStax Communityまたはオープン・ソースのApache Cassandra™ 2.0.x
- すべての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」を参照してください。 - 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を使用する必要があります。 - nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。
- DSE Searchノード:
ユニーク・キー要素はすべてSolrスキーマでインデックスを付ける必要があります。ユニーク・キー要素を確認するには、schema.xmlですべてのユニーク・キー・フィールドがindexed=trueになっていることを確認します。
必要に応じて、schema.xmlに変更を加え、Solrコアを再読み込みします。
- 使用する 構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。
構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。
4.0、4.5、または4.6から4.7または4.8へのアップグレード手順
DataStax Enterpriseのアップグレード・プロセスは、ダウンタイムの最小化(ゼロ・ダウンタイムが理想)を実現します。プロセス中、他のノードがオンラインで稼働し続けている状態でノードを1つずつアップグレードして再起動します。若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
- アップグレードの順序は重要です。ノードは以下の順序でアップグレードします。
- 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
- データ・センター内のシード・ノードを最初にアップグレードします。
DSE Hadoopを使用するDSE Analyticsノードでは、Job Trackerノードを最初にアップグレードします。次にHadoopノード、Sparkノードの順にアップグレードします。
- ノードは以下の順序でアップグレードします。
- DSE Analyticsデータ・センター
- トランザクション/DSE Graphデータ・センター
- DSE Searchデータ・センター
- DSE Analyticsノード:すべてのSparkワーカー・プロセスを強制終了します。
- DSE Searchノード:以下の考慮事項を確認して、適切なアクションを実行します。
- schema.xmlに
docValuesFormat="Disk"
を使用するfieldTypes
が含まれる場合、docValuesFormat
属性を削除するためにファイルを変更する必要があります。その後、インデックスを再度読み込み、最適化してデフォルトのコーデックに再度書き込みます。これはSolr 4.10以上で必要な作業です。 - 4.6のクエリー動作を維持するには:
dse.yamlファイルを編集し、
cql_solr_query_paging: off
を設定することで、ドライバーのページネーションを無効にします。DataStax Enterprise 4.7または4.8では、ネイティブ・ドライバー・ページングとSolrのカーソルベースのページングが統合されています(4.7、4.8)。アップグレードを確認した後、ページングをオンにすることができます。 - 4.0.0からのアップグレードの場合:特別な手順について「DataStax Enterprise 4.0.0からのアップグレードのための特別な手順」を参照してください。
- schema.xmlに
- 古いインストールのコミット・ログをフラッシュするには、次のようにします。
nodetool -h hostname drain
この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。 - ノードを停止します(4.7、4.8)。
- 適切なインストール・タイプを使用して、サポートされるプラットフォームに新しい製品バージョンをインストールします。注: システム上にある同じインストール・タイプを使用して新しい製品バージョンをインストールします。アップグレードではインストール・タイプに関係なくインストールを行います。異なるインストール・タイプを使用する場合、アップグレードで問題が発生する可能性があります。
- 新しい製品バージョンを構成するには:
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- 廃止予定、削除済み、または変更済みの設定を探します。
- 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
- 該当する変更を新しいバージョンにマージします。
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- ノードを起動します。
- アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
nodetool status
- 警告、エラー、および例外がないか、ログを確認します。
多くの場合、警告、エラー、および例外は、アップグレードしたノードの起動時にログに表示されます。これらのログ・エントリーの一部は、固有のアップグレード関連の手順を実行するときに役立ちます。予想しなかった警告、エラー、または例外が表示された場合は、DataStaxサポートまでお問い合わせください。
DSE Analyticsノードのアップグレード中は、タスク・トラッカーに関する例外は、まだ4.7または4.8にアップグレードされていないノードのログに記録されます。クラスター全体がアップグレードされたらジョブは成功となります。
DataStax Enterprise 4.7および4.8ではCassandra 2.1を使用するため、output.logには次の警告が含まれます。- Deprecated cassandra.yaml options are removed
- multithreaded_compaction
- memtable_flush_queue_size
- compaction_preheat_key_cache
- in_memory_compaction_limit_in_mb
- preheat_kernel_page_cache
- cassandra-env.shの以下の部分を変更します。
JVM_OPTS="$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar"
以下のように変更します。
JVM_OPTS="$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.3.0.jar"
- Deprecated cassandra.yaml options are removed
- DataStax Enterprise 4.8では、オーディット・ログ・テーブルはDateTieredCompactionStrategy(DTCS)を使用します。前のリリースで作成されたテーブルを変更してDTCSを使用することを推奨します。
ALTER TABLE dse_audit.audit_log WITH COMPACTION={'class':'DateTieredCompactionStrategy'};
- 推奨される 順序に従って、クラスター内の各ノードでアップグレードを繰り返します。
- 既存のテーブルでDSEインメモリー・オプションを使用する場合:
- SSTable圧縮をオフにします。
ALTER TABLE <tablename> WITH compression = {'sstable_compression' : ''} ;
- 圧縮なしで既存のSSTableを再度書き込みます。
nodetool upgradesstables -a <keyspacename> <tablename>
同時にアップグレードするSSTableの数を設定するには、
--jobs
オプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。
- SSTable圧縮をオフにします。
- 残りのノードのSSTableをアップグレードします。
nodetool upgradesstables
警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。同時にアップグレードするSSTableの数を設定するには、
--jobs
オプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。