DataStax Enterprise 5.0へのアップグレード
DataStax Enterprise 4.7または4.8から5.0へのアップグレード手順。
アップグレードの順序
ノードは以下の順序でアップグレードします。- 複数データ・センター・クラスターでは、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を使用します。
hive-site.xml
Sparkを使用する場合のhive-site.xmlファイルのデフォルトの場所:パッケージ・インストール | /etc/dse/spark/hive-site.xml |
tarボール・インストール | installation_location/resources/spark/conf/hive-site.xml |
DataStax Enterprise 4.7または4.8から5.0にアップグレードするには、以下の手順に従います。以前のバージョンを使用している場合は、最新バージョンにアップグレードしてから続行してください。
必ず現行バージョンの最新のパッチ・リリースにアップグレードしてから、新しいバージョンにアップグレードしてください。最新のパッチ・リリースに含まれている修正によって、アップグレード・プロセスが向上するか、スムーズになる場合があります。
- DSE 4.8の最新バージョンは 4.8.16
- DSE 4.7の最新バージョンは4.7.9です。
2038-01-19T03:14:06+00:00
より大きい期限切れの日付である場合、そのデータはすぐに期限切れとなり、次のコンパクションでパージされます。DataStaxでは、気付かないうちにデータがなくならないように、DSE 5.0.15以降にアップグレードし、必要な措置を講じることを強く推奨します(DSP-15412)。Apache Cassandra™のバージョン変更
- Apache Cassandraのメジャー・リリースを含むアップグレードには、SSTableのアップグレードが必要です。
- 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 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 Analytic(HadoopおよびSpark)ノードの制限事項
-
- すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
- ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。
- DSE Search(Solr)アップグレードの制限事項
-
- スキーマを更新しないでください。
- アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
- ローリング再起動中に、
DDL
、TRUNCATE
のような種類のクエリーを実行しないでください。 - アップグレード中にノードのバージョンが混合している間、DataStax Enterpriseでは後方互換性を提供するための2つの異なるサーバーを実行します。1つはshard_transport_optionsに基づいており、もう1つはinternode_messaging_optionsに基づいています(これらのオプションはdse.yamlに含まれています)。すべてのノードが5.0にアップグレードされると、internode_messaging_optionsが使用されます。internode_messaging_optionsは、DataStax Enterpriseの複数のコンポーネントによって使用されます。5.0以降では、すべてのノード間メッセージング要求でこのサービスが使用されます。
- 任意の種類のセキュリティを使用するノードの制限事項
-
- すべてのノードでアップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。
- Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
- ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
- ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。参照先: DataStaxドライバーの変更点。
アップグレードの準備
- アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。
必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。
- このリリースの変更点と機能について十分理解してください。
- ご使用のプラットフォームがサポートされていることを確認してください。
- OpenJDK 8またはOracle Java SE Runtime Environment 8(JDK)(最低1.8.0_40)。これより前、またはこれ以降のバージョンはサポートされていません。
- DataStax Enterprise 5.0のリリース・ノート。
- 任意のバージョンのアップグレードに関する一般的なアドバイス、およびApache Cassandra™ 3.0の新機能については、NEWS.txtに記載されています。NEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
- Apache Cassandra™での変更点については、CHANGES.txtに記載されています。
- Apache Cassandraに対するDataStax Enterprise 5.0の実稼働環境で認定済みの変更点。
- DataStaxドライバーの変更点。
- 現在の製品バージョンを確認します。必要に応じて、中間バージョンにアップグレードします。
現在のバージョン アップグレード・バージョン DataStax Enterprise 4.7または4.8 DataStax Enterprise 5.0 DataStax Enterprise 4.0、4.5、または4.6 DataStax Enterprise 4.8 DataStax Communityまたはオープン・ソースのApache Cassandra™ 2.1.x DataStax Enterprise 4.8 DataStax Community 3.0.x 中間バージョンは不要です。 Apache Cassandra™ 3.xのDataStaxディストリビューション アップグレードは利用できません。 - すべての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
- 推奨。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以上)
開発および実稼働システムではJDKを推奨しています。JDKには、jstack、jmap、jps、jstatなどのJREにはないトラブルシューティング用のツールがあります。
重要: Oracle JRE/JDK 8はサポートされていますが、DataStaxでは、DSE 5.0.15で起動するOpenJDK 8でさらに広範なテストを実施しています。 - 推奨。OpenJDK 8(1.8.0_151以上)
- nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。
- DSE Searchノード:
- Luceneフィールド・キャッシュ(solr_field_cache_enabled)ファイルは廃止予定です。このフィールドはdse.yamlファイルに含まれています。代わりに、ソート、ファセット、またはグループ分けされるフィールドに対して、schema.xmlファイル内のフィールドに
docValues="true"
を設定します。次に、コアを再度読み込んでインデックスを再作成します。デフォルト値はfalseです。falseをオーバーライドするには、Solr要求内にuseFieldCache=trueを設定します。バージョンが混在しているアップグレード中は、フィールド・キャッシュ(
solr_field_cache_enabled: true
)を再度有効にして、インデックスを再作成せずに、クエリーを実行できるようにします。 - ユニーク・キー要素はすべてSolrスキーマでインデックスを付ける必要があります。
ユニーク・キー要素を確認するには、schema.xmlですべてのユニーク・キー・フィールドがindexed=trueになっていることを確認します。必要に応じて、schema.xmlに変更を加え、インデックスを付け直します。
- HTTPベースのSolrシャード・トランスポート・オプションは廃止予定です。代わりにノード間メッセージング・オプションを使用してください。5.0では、すべてのノード間メッセージング要求でこの内部メッセージング・サービスが使用されます。HTTPは5.1では削除されます。
- アップグレードの前にスキーマを調整してください。DSE 5.0.10以降では、スキーマ内のすべてのフィールド定義が検証されます。フィールドにインデックスがないか、docValuesを適用するか、これらがコピー・フィールド・ソースに対して使用される場合であっても、DSE Searchがサポートされている必要があります。自動リソース生成のデフォルトの動作には、すべてのカラムが含まれます。パフォーマンスを改善するには、フィールドがデータベースから読み込まれないように対策を講じます。スキーマ内の使用されていないフィールドを削除するかコメント・アウトして、スキーマ内の必要なフィールドのみを含めます。 スキーマを変更したら、Solrコアを再読み込みします。
- Luceneフィールド・キャッシュ(solr_field_cache_enabled)ファイルは廃止予定です。このフィールドはdse.yamlファイルに含まれています。代わりに、ソート、ファセット、またはグループ分けされるフィールドに対して、schema.xmlファイル内のフィールドに
- DSE Searchパーティション・キー名DSE SearchインデックスによってサポートされているCOMPACT STORAGEテーブルのパーティション・キー名は、schema.xml内のuniqueKeyに一致します。たとえば、コンパクト・ストレージで次のテーブルを作成するとします。
Solr schema.xmlは次のとおりです。CREATE TABLE keyspace_name.table_name (key text PRIMARY KEY, foo text, solr_query text) WITH COMPACT STORAGE
次に、テーブル内のキー名をスキーマに合わせて変更します。... <uniqueKey>id</uniqueKey> ...
ALTER TABLE ks.table RENAME key TO id;
- DSE Analyticsノード
DSE 4.8からDSE 5.0へのローリング・アップグレードをデータ・センターで実行する場合は、hive-site.xmlのSparkで使用されるメタストア・テーブルの名前を手動で更新してください。
注: この手順は、データ・センター全体がアップグレードされる前に、中断せずにローリング・アップグレードする場合にのみ実行します。DSE 5.0は、 hive-site.xmlを手動で更新しない場合に、データ・センター全体がアップグレードされた後、Spark Masterを選択します。tarボール・インストールの場合:
sudo perl -i -pe 's|cfs:///user/spark/warehouse|cfs:///user/hive/warehouse|g' /etc/dse/spark/hive-site.xml
sudo perl -i -pe 's|sparkmetastore|MetaStore|g' /etc/dse/spark/hive-site.xml
パッケージ・インストールの場合:
sudo perl -i -pe 's|cfs:///user/spark/warehouse|cfs:///user/hive/warehouse|g' /usr/local/lib/dse/resources/spark/conf/hive-site.xml
sudo perl -i -pe 's|sparkmetastore|MetaStore|g' /usr/local/lib/dse/resources/spark/conf/hive-site.xml
DSE 5.0より前では、SparkはHiveメタストア・テーブル
HiveMetaStore.MetaStore
を使用していました。 DSE 5.0以降、Hiveメタストア・テーブルとSparkメタストア・テーブルは分離され、SparkはHiveMetaStore.sparkmetastore
テーブルを使用します。DSE 5.0が起動し、メタストア・テーブルが見つからない場合、最初にメタストア・テーブルを作成する必要があるため、ノードはSparkを起動する前にクラスター全体がアップグレードされるのを待ちます。 手動で設定を更新すると、Sparkノードはメタストア・テーブルを作成し、混在データ・センターでMasterを選択できるようになります。ローリング・アップグレード中は不便な点がいくつかあります。Sparkコンタクト・ポイントがDSE 5.0ノードに設定されている場合、データへのアクセスに使用できるのはDSE 5.0レプリカだけです。ただし、コンタクト・ポイントがDSE 4.8に設定されている場合は、クラスター内のすべてのレプリカのデータにアクセスできます。
- 使用する 構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。
構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。
アップグレード手順
DataStax Enterprise 4.7または4.8からDataStax Enterprise 5.0にアップグレードするには、各ノードで以下の手順に従います。一部の警告メッセージがアップグレード中とアップグレード後に表示されます。
DataStax Enterpriseのアップグレード・プロセスは、ダウンタイムの最小化(ゼロ・ダウンタイムが理想)を実現します。プロセス中、他のノードがオンラインで稼働し続けている状態でノードを1つずつアップグレードして再起動します。若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。
- アップグレードの順序は重要です。ノードは以下の順序でアップグレードします。
- 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
- データ・センター内のシード・ノードを最初にアップグレードします。
DSE Hadoopを使用するDSE Analyticsノードでは、Job Trackerノードを最初にアップグレードします。次にHadoopノード、Sparkノードの順にアップグレードします。
- ノードは以下の順序でアップグレードします。
- DSE Analyticsデータ・センター
- トランザクション/DSE Graphデータ・センター
- DSE Searchデータ・センター
- DSE Analyticsノード:すべてのSparkワーカー・プロセスを強制終了します。
- 古いインストールのコミット・ログをフラッシュするには、次のようにします。
nodetool -h hostname drain
この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。重要: SSTable形式を変更し、前のバージョンのコミット・ログのレンダリングが新しいバージョンと互換性がないCassandraのメジャー・バージョン間でアップグレードを行う場合、この手順は必須です。 - ノードを停止します。
- 適切な方法を使用して、サポートされるプラットフォームにDSE 5.0をインストールします。
- バイナリtarボール
- APIを使用したDebianベースのシステム
- Yumを使用したRHELベースのシステム重要: デモがインストールされているRHELベースのシステムでアップグレードする場合は、パッケージ・インストールを1行で指定し、dse-fullおよびdse-demosのバージョンを指定する必要があります。例を次に示します。
sudo yum install dse-full-5.0.14-1 dse-demos-5.0.14-1
注: システム上にある同じインストール方法を使用して新しい製品バージョンをインストールします。アップグレードではインストール方法に関係なくインストールを行うため、問題が発生することがあります。 - クラスターがセキュアなKerberos環境でHadoopを実行する場合は、task-controllerファイルの所有権をrootに変更し、アクセス・パーミッションを4750に変更します。例を次に示します。
sudo chown root /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller $ sudo chmod 4750 /usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controller
パッケージ・インストールのみ:
task-controller
ファイルのデフォルトの場所を/usr/share/dse/resources/hadoop/native/Linux-amd64-64/bin/task-controllerに設定する必要があります。 - 新しい製品バージョンを構成するには:
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- 廃止予定、削除済み、または変更済みの設定を探します。
- 新しいリリースのApache CassandraおよびDataStax Enterpriseの変更点や機能について、よく理解しておいてください。
- キースペース・レプリケーション係数が環境に適していることを確認してください。
- 分析キースペースのキースペース・レプリケーション係数を設定します。
- system_authおよびdse_securityキースペースのキースペース・レプリケーション係数を設定します。
- 該当する変更を新しいバージョンにマージします。
- バックアップ 構成 ファイルを新しい構成ファイルと比較します。
- ノードを起動します。
- Installer-Servicesおよびパッケージ・インストール:「DataStax Enterpriseをサービスとして起動」を参照してください。
- Installer-No Servicesおよびtarボール・インストール:「DataStax Enterpriseをスタンドアローン・プロセスとして起動」を参照してください。
- アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
nodetool status
- 警告、エラー、および例外がないか、ログを確認します。 DataStax Enterprise 5.0はCassandra 3.0を使用するため、output.logには以下に関する警告が含まれる場合があります。
- sstable_compression
- chunk_length_kb
- memory_allocator
- memtable_allocation_type
- offheap_objects
- netty_server_port - 5.0へのアップグレード中にのみ使用。すべてのノードが5.0を実行するようになると、このノードによってコーディネートされる要求はこのポートで他のノードに連絡しなくなります。代わりに、要求にはノード間メッセージング・オプションが使用されます。internode_messaging_optionsは、DataStax Enterpriseの複数のコンポーネントによって使用されます。5.0以降では、すべてのノード間メッセージング要求でこのサービスが使用されます。
多くの場合、警告、エラー、および例外は、アップグレードしたノードの起動時にログに表示されます。これらのログ・エントリーの一部は、固有のアップグレード関連の手順を実行するときに役立ちます。予想しなかった警告、エラー、または例外が表示された場合は、DataStaxサポートまでお問い合わせください。
DSE Analyticsノードのアップグレード中は、タスク・トラッカーに関する例外が、まだ5.0にアップグレードされていないノードのログに記録されます。クラスター全体がアップグレードされたらジョブは成功となります。
- 推奨される 順序に従って、クラスター内の各ノードでアップグレードを繰り返します。
- すべてのノードがアップグレードされたら、レガシー・テーブル(system_auth.users、system_auth.credentials、system_auth.permissions)を削除する必要があります。この手順は、レガシー・テーブルが存在する場合、すべてのワークロードに必要です。
CassandraのNEWS.txtに説明されているように、認証および権限管理サブシステムはロールベースのアクセス制御(RBAC)をサポートするように再設計されています。これにより、system_authキースペースのスキーマが変更されます。
- DSE 5.0.12以降のDSE Searchのみ:アップグレード後、お使いのクラスターの各ノードで、すべての暗号化検索インデックスを完全に再作成する必要があります。大きな暗号化インデックスがある場合にノードでの起動が遅くなる問題は解決されています。ただし、パフォーマンスの向上を実現するためにはアクションが必要です。アップグレードが完了したら、ローリング方式でdeleteAll=trueを使用してインデックスを再作成するための時間を十分に取ってください。例を次に示します。
dsetool reload_core keyspace_name.table_name distributed=false reindex=true deleteAll=true
- 新しいバージョンがすべてのノードにインストールされたら、次のSSTableをアップグレードします。
nodetool upgradesstables
警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。同時にアップグレードするSSTableの数を設定するには、
--jobs
オプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。 - 複数のデータ・センターのデプロイでは、system_distributedキースペースのレプリケーション係数をNetworkTopologyStrategyに変更します。
- OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。
アップグレード中とアップグレード後の警告メッセージ
アップグレード中およびアップグレード後に表示される一部のログ・メッセージは無視できます。
WARN [main] 2016-06-23 12:01:59,693 CommitLogReplayer.java:154 - Skipped 31 mutations from unknown (probably removed) CF with id b0f22357-4458-3cdb-9631-c43e59ce3676
WARN [main] 2016-06-23 12:01:59,693 CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 3aa75225-4f82-350b-8d5c-430fa221fa0a
WARN [main] 2016-06-23 12:01:59,696 CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 45f5b360-24bc-3f83-a363-1034ea4fa697
WARN [main] 2016-06-23 12:01:59,696 CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 0359bc71-7123-3ee1-9a4a-b9dfb11fc125
WARN [main] 2016-06-23 12:01:59,697 CommitLogReplayer.java:154 - Skipped 1 mutations from unknown (probably removed) CF with id 296e9c04-9bec-3085-827d-c17d3df2122a
これらのログ・メッセージは無視しても差し支えありません。